For more information click here. Also Samisa's podcast is available here
Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts
Wednesday, December 16, 2009
WSO2 Business Activity Monitor
WSO2 Business Activity Monitor, allows monitoring Service Mediation/Invocation data. The data is captured real time, and could be used for decision making activities. BAM is extensible and can be used to custom monitoring needs as well.

For more information click here. Also Samisa's podcast is available here
For more information click here. Also Samisa's podcast is available here
Wednesday, November 26, 2008
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.
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.
Thursday, November 20, 2008
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.
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
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.
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.
- Choreographies can be defined in WS-CDL first by business partners and then generate BPEL process stubs for each party
- 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
- Each party participated in CDL choreography a separate BPEL stub is generated
- One cdl:relationshipType maps to one bpel:partnerLinkType and the bpel:role with its bpel:portType is generated from the referenced cdl:roleType declaration
- Generate separate property files for each cdl:roleType including only those bpel:properties that are relevant for a party.
- BPEL basic activities are directly mapped to CDL basic activities
- 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.
Labels:
Adaptive,
BPEL,
CDL,
ROAD,
SOA,
Web processes,
Web services
Sunday, November 09, 2008
Adaptive web processes in a pervasive services oriented environment
Services Oriented Architecture provides different applications to interact in a distributed environment to perform a particular task. The concept of services orientation in software design aimed to achieve the loose coupling of applications from its underlying operating environment. Being a progression of component based software development, Services oriented computing provide interfaces to users (human or software) to utilize a particular resource in a distributed environment.
On the other hand the image of traditional computer is fading away. Mobile /embedded devices claim for a good portion of computing efforts today, with the advancement of electronic technologies. Our car, phone, watch or what ever a device that we can’t picture today, has started to or will become a computing device. This resulted in many researches on Pervasive Computing or Ubiquitous Computing.
The operating conditions in such a pervasive services oriented computing environment are always subjected to change. For example while you are travelling, you mobile phone in your pocket and the car you drive might be doing some message exchanges/queries with applications hosted in nearby restaurants, shops and motels. The operating conditions like the mobile coverage, network bandwidth, types of technologies and even the availability of services can be subjected to frequent changes. The life time of applications is determined by these varying factors of the environment. The survival is always critical. And this calls for self-adaptive software systems.
Studies about adaptable and adaptive software systems have emerged as a major research topic in the past few years. Survival in highly fluctuating environments is a critical requirement for future software systems. Concepts of self-healing, self-configuration, self-optimization and all other self-* buzzwords are popping up in pervasive services oriented software systems. Many frameworks, solutions, techniques are being introduced in the reason past.
It is interesting to study about how business processes adapts to these highly fluctuating environments. Current approaches like BPEL and WS-CDL does not address the adaptation. Although it is possible to identify sort of programmable adaptation, in above approaches, where pre-defined processes are carrying out according to limited "expected" changes, it is not the sort of adaptation that we would be looking for. It is required to define, change choreographies among different business partners at run time in order to ensure smooth continues business processes. Runtime negotiation and establishment/termination of contracts among participating entities are essential part of the adaptation.
My research would be concentrated finding techniques and designs for process adaptation in such a pervasive, services oriented computing environment. Yeah... A diverted lil bit from security:-). Though this is not a really hot topic, I belive that there are more yet to be investigated. Therefore in coming months I'd be concentrating on this.
On the other hand the image of traditional computer is fading away. Mobile /embedded devices claim for a good portion of computing efforts today, with the advancement of electronic technologies. Our car, phone, watch or what ever a device that we can’t picture today, has started to or will become a computing device. This resulted in many researches on Pervasive Computing or Ubiquitous Computing.
The operating conditions in such a pervasive services oriented computing environment are always subjected to change. For example while you are travelling, you mobile phone in your pocket and the car you drive might be doing some message exchanges/queries with applications hosted in nearby restaurants, shops and motels. The operating conditions like the mobile coverage, network bandwidth, types of technologies and even the availability of services can be subjected to frequent changes. The life time of applications is determined by these varying factors of the environment. The survival is always critical. And this calls for self-adaptive software systems.
Studies about adaptable and adaptive software systems have emerged as a major research topic in the past few years. Survival in highly fluctuating environments is a critical requirement for future software systems. Concepts of self-healing, self-configuration, self-optimization and all other self-* buzzwords are popping up in pervasive services oriented software systems. Many frameworks, solutions, techniques are being introduced in the reason past.
It is interesting to study about how business processes adapts to these highly fluctuating environments. Current approaches like BPEL and WS-CDL does not address the adaptation. Although it is possible to identify sort of programmable adaptation, in above approaches, where pre-defined processes are carrying out according to limited "expected" changes, it is not the sort of adaptation that we would be looking for. It is required to define, change choreographies among different business partners at run time in order to ensure smooth continues business processes. Runtime negotiation and establishment/termination of contracts among participating entities are essential part of the adaptation.
My research would be concentrated finding techniques and designs for process adaptation in such a pervasive, services oriented computing environment. Yeah... A diverted lil bit from security:-). Though this is not a really hot topic, I belive that there are more yet to be investigated. Therefore in coming months I'd be concentrating on this.
Labels:
Adaptive,
Mobile,
Pervasive,
SOA,
Software architecture,
Web processes
Wednesday, September 17, 2008
Open source, WS-Standards and Beyond
16/09/2008 @ Swinburne University of Technology
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.
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.
Labels:
opensource,
SOA,
Swinburne,
Talk,
Web services
Monday, September 01, 2008
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)
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)
Labels:
Federation,
Registry,
SOA,
Software architecture,
UDDI,
Web services,
WSO2
Tuesday, April 08, 2008
Friday, April 04, 2008
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).
Labels:
Demo,
PHP,
samples,
SOA,
SOAP,
Web services,
WSO2 WSF/PHP
Thursday, April 03, 2008
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.
Labels:
SOA,
Spring,
Web services,
WSF/Spring,
WSO2
Tuesday, February 26, 2008
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
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.
Done? Perfect. Let's start the server
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
Open s browser and enter the following address as the url
If all goes well, this should show the deployed services. Usually these are samples comes with WSF/C.
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.
Labels:
Apache,
httpd,
SOA,
SOAP,
web server,
Web services,
WSF/C
Subscribe to:
Posts (Atom)