Process Aware Information Systems

During my summer vacation, I started reading the Book "Process Aware Information Systems". The book caught my eye as I was passing a shelf in the library. After reading the preface I decided to have a better look.



The first section gives an overview of PAIS(Process Aware Information Systems) which includes a nice classification of PAIS and the rationale behind it, adding a little bit of history along with techniques and tools too.
Then the book discusses concepts of Workflow Management and modelling, person to person interactions, business to business integration etc.
The section two of the book is more like a reference. That includes UML modelling, petri nets, and event driven process chains. But hard to read continuously though.
The last section discusses more practical methodologies and standards such as XPDL and BPEL. For those who are interested in web services business processes like my self, this is again a good reference. But before reading this section its better to have look at those specifications first and may be started with "Introduction to XYZ..." kind of an article.

ICSOC 2008

The sixth International Conference on Service Oriented Computing (ICSOC) is to be held from 1st to 5th of December in Sydney, Australia. In parallel to the main conference there is is a PhD symposium (December 1st) that will discuss the approaches, steps, best practices for PhD student that are exploring the Services Oriented Architecture.
After the main conference there is a summer school too. A good opportunity for students living downunder to learn and discuss the latest concepts and technologies in Services Oriented Computing. That will be held in Friday (5th) and Saturday (6th). The complete program is available in the main conference web site here.

BPEL from CDL

WS-CDL and WS-BPEL both provide a way to describe how web services should collaborate. But the difference is that WS-CDL gives a global perspective the message exchange whilst the WS-BPEL provides a single participant's perspective.
As some are arguing I do not see a competition between these two specifications. Rather they must co-exist to describe services interactions properly.
Though, WS_CDL is designed to be used in conjunction with the WS-BPEL, one limitation of the WS-CDL specification is that a clear mapping with BPEL is missing. I agree that the intention of WS-CDL is not to be depend on WS=BPEL but there are advantages of having such a clear mapping.

1. Choreographies can be defined in WS-CDL first by business partners and then generate BPEL process stubs for each party
   
2. A party who’s having an internal business processes may need to publish the interface to its processes to attract business partners by generating the choreography. This could be done using a BPEL to CDL mapping.
   

From the engineering perspective such a mapping could be automated. Also such a defined approach would minimize the inconsistent mappings by different parties coming in to collaboration.
This paper presents how BPEL process definitions are derived from the global WS-CDL model. Authors have done this by defining a set of transformation rules.
For example

1. Each party participated in CDL choreography a separate BPEL stub is generated
   
2. One cdl:relationshipType maps to one bpel:partnerLinkType and the bpel:role with its bpel:portType is generated from the referenced cdl:roleType declaration
   
3. Generate separate property files for each cdl:roleType including only those bpel:properties that are relevant for a party.
   
4. BPEL basic activities are directly mapped to CDL basic activities
   
5. Work units in CDL are related to scopes in BPEL
   

The complete mapping is available in the section 5.
The paper addresses a much required issue by not altering the existing standards or without introducing new standard, which is a plus point. The approach seems straightforward and not requiring intermediated mapping like in the approach here[4] where the mapping is into Communicating Sequential Processes. Also authors have implemented a prototype of the mapping as a proof of concepts.
Saying that, one limitation of the paper is that there is no reference on how to verify the generated BPEL stubs over the original CDL. Generated stubs may be correct for the given example or could be verified manually for simple scenarios. But it is required to have a formal mechanism to verify more complex scenarios. That is not in future work section too. And the verification need to be integrated to the BPEL stub generation or it should be done after generating BPEL stubs but before the populating them with application logic.
Also it is not clear how the mapping from BPEL processes to CDL is done. Which also an interesting issue (as far as ROAD is concerned ). May be we might be able to complete that part. We can map several processes to a common choreography by projecting them over a ROAD Self Managed Composite. In other words by overlapping several processes we might be able to define the choreography. Syntactical transformations might use the same discussed in the paper. Sure need to think and discuss more about that.

Web Services Ecosystems

The traditional definition of an ecosystem is something related to living things as the following found in the Merriam-Webster online dictionary,
"The complex of a community of organisms and its environment functioning as an ecological unit". Extending this to the world of web services with the concept of "a software as a service", as the backbone, today we are talking about Web Services Echo Systems.
The article by Alistair Barros and Marlon Dumas describes us, how different entities in the web services world plays different roles and how they are depending on each other forming an ecosystem. Also it shows how different entities are benefited by being part of this web services ecosystem. For example third party developers are developing services or service components and software companies acting as service brokers and integrators depending on them. Another example is how some companies address the space of interoperability and QoS issues on the basis of software as a service.
Also the paper shows unlike application servers, how business environment in an ecosystem evolve constraints. This is depending on the requirements of the demand side and the supply side
Demand side constrains on how services are
1. Discovered
2. Ranked
3. Authenticated
4. Mediated
5. Charged

While Supply side constrains on how services are
1. Published
2. Re-purposed through composition
3. Brokered
4. Re-provisioned through leasing and licensing

As we see that there are multiple entities are benefited under web services ecosystem, there are few obstacles on the way. The paper identifies three major fronts that the web services infrastructure will have to evolve

1.Flexible web services discovery:
Need to go beyond the conventional key word based searches. If the domain of the ecosystem is wider then key word based searches become unsuccessful. Instead it is advisable to use a combination of free-text and ontology-based searches.
2.Conversational multiparty interactions:
Service interactions are getting complex. Different transaction paths in a business process.
3.Service mediation and adaptation:
Services have different behaviours. Need to find cost-effective ways for service interface adaptation.

Open source, WS-Standards and Beyond

16/09/2008 @ Swinburne University of Technology

Open source, WS-Standards and Beyond - Upload a Document to Scribd

Read this document on Scribd: Open source, WS-Standards and Beyond

Folks, if u need the animated version of this or if u have any questions, drop an email (Right now I do not have any space to upload the original PPT). Alternatively meet me at Room 404 EN Building.

Federated registries and crawlers

Deepal has revealed some of the things we discussed over the chat during the last weekend regarding web services discovery mechanisms.
I started to look into WSO2 registry to help with another PhD student but didn’t have much time to dig into the architecture level as I was busy during last week with my studies.
Yeah… the problem with having multiple registries in a heterogeneous environment is that it makes really difficult to find web services information, which is essential part in SOA. As web services grows from hundreds to thousands, the consumers or the clients need to have an efficient way to locate them. And publishers also need to attract clients without going through other marketing channels and gimmicks.
One such approach is discussed in this paper, which uses a crawler engine to find web services. In this approach the Crawler Engine (WSCE) actively crawls excising UBRs and search engines to collect web services information. Thus a system can maintain most up-to-date information about available web services. Web services information can be found using existing web services registries and web services portals. And also via search engines, which is becoming popular.

[Source : Eyhab, A.-M. and H.M. Qusay, Investigating web services on the world wide web, in Proceeding of the 17th international conference on World Wide Web. 2008, ACM: Beijing, China]

But using search engines too have limitations as they do not recognize web services with basic service properties such as binding information, ports, operations etc. And search engines can cache/store WSDL documents but there is no business-centric model or adhering to web services standards.

Another approach discussed in this paper is to form a federation of registries. The current search facilities offered by the latest version of UDDI do not offer any special features for finding Web service registries depending on the business domains. And it is difficult to have a design and execution autonomy for affiliated registries. The approach discusses in the paper allows peer to peer network of private, semi-private and public UDDI registries, which allow transparent access to registries in a federated environment. Following are the essential features of the approach

-Participating registries are autonomous registries that can be private or public
-Participating registries can be part of multiple federations
-Participating registries can be heterogeneous. Can have different data models and APIs
-Participating registries can arbitrary join and leave the federation. This is something that we cannot achieve with the UDDI replication support in V3
-Participating registries will have the design and execution autonomy
-The federation of registries can be formed as a market place for common interests
-The XTRO or the extended registries ontology provides a way o do complex queries across federations

So, in overall there is a requirement of adhering to a common standards as well as developing mechanisms to retrieve web services information from the repositories built upon multiple standards. IMO the latter is much better as it does not limit to a particular standard. (Lessons from the history)

WSO2 WSF/C 1.3.0

WSO2 Web Services Framework for C version 1.3.0 has been released.
The new release came with many improvements including memory leak fixes and bug fixes. Also it has changed the default parser to Guththila, which is optimized for SOAP processing.
Get more details from the project home page about the latest release.
WSO2 WSF/C is the base framework for many web services frameworks including WSO2 WSF/PHP.

Web services in scripting langauges. PHP, Perl and Ruby

I have done survey to compare features of three scripting languages related to web services implementations. Those three languages are PHP, Perl and Ruby. This comparison also contrasts WSF/* family of products with other implementations. For example WSF/PHP vs nuSOAP. Please note that the features are compared to the latest released versions mentioned below.


And here is the feature comparison.


Not Implemented
Implemented
Experimental

Seven things to know about FEDi

FEDi is
- about authentication and to enable single sign on in a federated environment
- to establish the trust between entities in different security realms
- based on Apache Axis2/C and Apache Rampart/C
- to provide the infrastructure to develop identity enabled web services
- is an effort to implement WS-Trust, SAML and WS-Federation specifications in C language


FEDi is NOT
- a product/application. It's a framework that can be used to implement the final product/application.
- an alternative to Identity Solution. It's an effort to extend the capabilities to federated environment

Need to know more check this out

Writing a secure client in Ruby

WSF/Ruby provides an easy to use API to consume and deploy web services. Adding the Apache Rampart/C features, it also provides SOAP message confidentiality, integrity and authentication.
In the following four easy steps we will show how to write a secure client using WSF/Ruby.

1. Create the policy. Here we need to encrypt using the Basic256Rsa15 algorithm suite and the relavent key information should be identified using the Issuer name and the serial number of the certificate

      
       policy_content = {"encrypt"=> true,
                     "algorithm_suite" => "Basic256Rsa15",
                     "security_token_reference" => "IssuerSerial"}
       policy = WSPolicy.new({"security" => policy_content}

2. Create the security token. Note that the private keys and certificates need to be loaded

  
   security_options = {"private_key" => pvt_key,
                       "receiver_certificate" => rec_cert}
   security_token = WSSecurityToken.new(security_options)

3. Create options for policy and security token. Here the use_wsa=true means that the clinet MUST include WS Addressing header in the message.

  
   options = {"use_wsa" => true,
              "policy" => policy,
              "security_token" => security_token}

4. Request from the service. For this we need to create the client.

  
    client = WSClient.new(options, LOG_FILE)
    res_message = client.request(payload)

The complete source code is as follows.

  
require 'wsf'
require 'rexml/document'

include WSO2::WSF
include WSO2::Util

#This is your pay load
req_payload = << XML
Hello World!
XML

begin
   LOG_FILE = "security_sample.log"
   ACTION = "http://php.axis2.org/samples/echoString"
   END_POINT = "http://localhost:3000/encryption/encryption"

   message_properties = {"to" => END_POINT,
                         "action" => ACTION}

   #Load certificates and keys from the disk
   rec_cert = WSUtil::ws_get_cert_from_file("../keys/bob_cert.cert")
   pvt_key = WSUtil::ws_get_key_from_file("../keys/alice_key.pem")
 
  #The payload or the body of the SOAP message
   payload = WSMessage.new(req_payload,
                           nil,
                           message_properties)

    #Create the security policy
   policy_content = {"encrypt"=> true,
                     "algorithm_suite" => "Basic256Rsa15",
                     "security_token_reference" => "IssuerSerial"}

   policy = WSPolicy.new({"security" => policy_content})

    #Create the security token
   security_options = {"private_key" => pvt_key,
                       "receiver_certificate" => rec_cert}
 
   security_token = WSSecurityToken.new(security_options)

    #Create option for the client
   options = {"use_wsa" => true,
              "policy" => policy,
              "security_token" => security_token}
  
    #Create a client instance
   client = WSClient.new(options, LOG_FILE)

    #Request
   res_message = client.request(payload)

   if not res_message.nil? then
      puts "Received OM: "<< "\n" << res_message.payload_to_s << "\n\n"
      puts "Client invocation SUCCESSFUL !!!"
   else
      puts "Client invocation FAILED !!!"
   end

#If SOAP fault, print the details
rescue WSFault => wsfault
   puts "Client invocation FAILED !!!\n"
   puts "WSFault : "
   puts wsfault.xml
   puts "----------"
   puts wsfault.code
   puts "----------"
   puts wsfault.reason
   puts "----------"
   puts wsfault.role
   puts "----------"
   puts wsfault.detail
   puts "----------"

rescue => exception
   puts "Client invocation FAILED !!!\n"
   puts "Exception : " << exception
end

More security samples can be found here...

WSF/PHP : Creating Business-Conscious IT Solutions

In this article I have shown how to address a typical business communication scenario using WSF/PHP. It also discusses the importance of the message level security and shown how exactly those will be used in a scenario like this. The complete source code is available here.

A collection of PHP demos

Wanna try out some samples in PHP web services?
Try out this collection of demos.
You can try, download, rate samples and view the source code to get an idea what you can do with web services in PHP language. The demos here are developed with WSO2 Web Services Framework for PHP (WSF/PHP).

Spring the WSF/*

Adding yet another member to the WSF family WSO2 has announced the release of WSF/Spring 1.0.
Similar to other WSF products, this too is released under the Apache license 2.0. Now the spring users would be able to expose web services using the famous Apache Axis2/Java engine. The framework is also powered by the WS-* of implementations including WS-Security, WS-SecurityPolicy, WS-Policy, WS-Addressing, WS-ReliableMessaging and WS-Eventing. Here you will find a quick start guide.

WSO2 WSF/C with Apache HTTP server

Following section will show you how to use WSO2 Web services framework for C (WSF/C) with the Apache HTTP server in linux environment.
First download and install apache2 server. Please follow the instructions in INSTALL file.
Then download WSF/C and configure with the following option

%./configure --with-apache2=/path/to/apache2 --prefix=/your/wsfc_home/directory
%make
%make install

Once you do make install, this will create a libmod_axis2.so inside WSFC_HOME/lib. Copy this file to apache2/modules directory. Now please open the httpd.conf file inside conf directory. Add following entries to the file. These will be your configurations to the axis2/c web services engine.

LoadModule axis2_module modules/libmod_axis2.so
    Axis2RepoPath /your/path/to/wsf/c/home
    Axis2LogFile /tmp/apache_axis2.log
    Axis2LogLevel debug
    Axis2MaxLogFileSize 32
    <Location /axis2>
        SetHandler axis2_module
    </Location>

Done? Perfect. Let's start the server

%./httpd -k start

If the default port (i.e. 80) is in use try another port such as 8080. You can change the port in the conf/httpd.conf file

Listen 8080

Open s browser and enter the following address as the url

http://localhost:8080/axis2/services

If all goes well, this should show the deployed services. Usually these are samples comes with WSF/C.

WSO2 Web Services Framework for C language

As the B2B communication becomes loosely coupled and automated in a distributed environment, web services technology is blooming as the perfect solution for numerous business applications. With the ability of multiple legacy applications to be integrated to form a single system and allowing various clients, dispersed in contrasting platforms in different coordinates of the world to communicate are the major challenges faced by many software architects and developers.
As a solution for this WSO2 has introduced a series of web services middle-ware that can be used to implement your business application. Amongst them WSO2 Web services framework for C (WSF/C) can become appealing to the C, C++ community.
If you are a PHP or Ruby developer you have the option of using respective extensions of WSF/C in these languages. Please check WSF/PHP and WSF/Ruby for more details.

Apache Axis2/C FAQ

There is this FAQ prepared by Spencer Davis and some other Apache Axis2/C developers. If you have any entries that you think worth including, please feel free to drop them here.
http://wiki.apache.org/general/axis2c/FAQ
Soon it will be filtered, sorted and integrated into the Apache Axis2/C documentation.
If you do not have permissions to edit, simply drop an email to axis-c-dev@ws.apache.org list with the subject Axis2/C FAQs.

Facing security threats with WSF/PHP

Following table shows how to use/combine WSO2 WSF/PHP security features to face the common web services security threats...



Note that it is necessary to use username tokens with transport level security

TCP Monitor tool with WSO2 WSF/C

The TCPMonitor tool can be used to listen to TCP(Transmission Control Protocol) endpoints in your system. When you download and build WSO2 WSF/C, the tool is available at WSFC_HOME/bin/tools for your convenience. Go to the directory and start the tool as follows.

%tcpmon.exe
Note that I've used .exe for the Win32 systems. UNIX guys please use
%./tcpmon

OK. Now by default, the tool listens to the port 9090 and redirects messages to port 8080 at the localhost(i.e. to the same machine). Note: You may change these default settings using few command line arguments.

Usage : tcpmon.exe [-lp LISTEN_PORT] [-tp TARGET_PORT] [-th TARGET_HOST] [-f LOG_FILE]
e.g. tcpmon.exe -lp 9090 -tp 8080 -th localhost -f my_tcpmon.log

Since we are redirecting our messages to port 8080, this time we have to start the server listening to that port.
%axis2_http_server.exe -p8080

Alright now we are ready to sniff the wire content. Now what we have to do is start a client. The client samples are available at WSFC_HOME/bin/samples. I'll use the following. But try other samples as well.
%echo_blocking_addr.exe

OK now you see that your service invoke is successful and feel that the world is newer better. So please do open the tcpmon_traffic.log in WSFC_HOME/bin/tools using a text editor such as notepad, gedit or vi to see the wire content. Now you should see something like this.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
SENDING DATA..
/* sending time = 10:58:13*/
---------------------
POST /axis2/services/echo HTTP/1.1
User-Agent: Axis2/C
Content-Length: 512
Content-Type: application/soap+xml;charset=UTF-8
Host: localhost:9090

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:To>http://localhost:9090/axis2/services/echo</wsa:To>
<wsa:Action>http://ws.apache.org/axis2/c/samples/echoString</wsa:Action>
<wsa:MessageID>02973ea8-bb4f-1dc1-2693-000000000000</wsa:MessageID>
</soapenv:Header>
<soapenv:Body>
<ns1:echoString xmlns:ns1="http://ws.apache.org/axis2/services/echo">
<text>Hello World!</text>
</ns1:echoString>
</soapenv:Body>
</soapenv:Envelope>

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
RETRIEVING DATA..
/* retrieving time = 10:58:13*/
/* time throughput = 0 sec(s)*/
---------------------
HTTP/1.1 200 OK
Content-Type: application/soap+xml;charset=UTF-8
Content-Length: 672

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Action>http://ws.apache.org/axis2/c/samples/echoString</wsa:Action>
<wsa:From>
<wsa:Address>http://localhost:9090/axis2/services/echo</wsa:Address>
</wsa:From>
<wsa:MessageID>02983114-bb4f-1dc1-3856-000000000000</wsa:MessageID>
<wsa:RelatesTo wsa:RelationshipType="http://www.w3.org/2005/08/addressing/reply">02973ea8-bb4f-1dc1-2693-000000000000</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
<ns1:echoString xmlns:ns1="http://ws.apache.org/axis2/c/samples">
<text>Hello World!</text>
</ns1:echoString>
</soapenv:Body>
</soapenv:Envelope>

The SOAP envelope in the first portion of the file shows the request and the last SOAP envelope shows the response from the server.

WSO2 WSF/C 1.2.0 is released

The Web Services Framework for C (WSF/C) is an open source library written to provide and consume web services in C programming language. The framework is released under Apache license 2.0. That means it comes with a $0 cost and liberty to redistribute.
WSF/C also integrates many Apache projects. Using the famous Apache Axis2/C as the web services engine, it has also accoutered with Apache Rampart/C, Apache Sandesha2/C and Apache Savan/C.
Armed by all these WSF/C provides web services security, reliability and eventing support with just a single download. And it is inter-operable with Microsoft .Net, WSO2 Web Services Application Server and other J2EE implementation.
Moreover, WSO2 WSF/C is the base framework for other web service frameworks like WSF/PHP and WSF/Ruby.
WSO2 Team has announced the release of 1.2.0 last week. You may download the release here

WSO2's WSF/PHP and Apache Ramaprt/C

Following diagram shows how the WSO2 WSF/PHP is arranged...



Basically the WSO2 WSF/PHP is a PHP extension. It can be seen as the upper layer of a 3-core wire.
And inside it there is another layer wrapping many other products, which we call the WSO2 WSF/C. These products are the implementations of WS-* of specifications including Apache Rampart/C, Apache Sandesha2/C, Apache Savan/C.
A PHP user will basically consume/provide web services by using the upper WSF/PHP layer. The core specifications and implementations are transparent to the PHP user to make the life easier. But sometimes it's worth to know how exactly are the inner components arranged. :)

In order to provide security, WSO2 WSF/PHP uses Apache Rampart/C. Actually via WSO2 WSF/C. Apache Rampart/C is the security module for the Apache Axis2/C engine, which the WSF/PHP depends on. You may refer my this blog entryto see how to write a PHP script to encrypt a SOAP message.