Relationship of Semantic Web Services

Today I was reading a paper on Semantic Web Services titled "Semantic Web Services Composition Using AI planning of Description Logic" by Lirong Qiu, Fen Lin, Changlin Wan and Zhongzhi Shi. This paper explained in detail as how a Semantic Web Service works and also their composition using First Order Logic language. Below is some of the useful thing I found in that paper.

Relationship of Semantic Web Services:
There exists relationships between different Web Services when considered Service Composition. The Assumption is being made that Si and Sj is the sub-service of Services S. Both Si and Sj provide different kind of services. In light of that the relationship between Si and Sj can be identified as:

1. Independent Relationship: Si + Sj = Sj + Si which means each sub-service is independent of other and the order of execution of these two sub-services do not affect composition services.
2. Identical Relationship: Si = Sj, which means the two services seems to be doing the same thing but they have few differences in terms of their attributes.
3. Conditionally Identical Service: Si =~ Sj, this means Si can provide the same function as Sj in Some situations.
4. Substitute Relationship: Si (less than sign) Sj, which means Si and Sj can be substituted for each other or they can swap their roles anytime without affecting the overall functionality.
   
5. Conditionally Substitute Relationship: Si <= Sj, Which means Si and Sj can be substituted upon fulfilling some conditions.
6. Overlapping Relationship: Si (X) Sj, which means there is some commonality between the two services. While composing this overlapping or common part must be excluded.
7. Pre-Requisite Relationship: Si -> Sj, which means that one service has to finish before the other starts or in other words, the execution of Sj depends on successful completion of Si.

I am still working on how to make the Semantic Web Services automatic discoverable, while it is not easy but I guess it is not impossible too. With the advent of OWL-S it should be easy. I am yet to dig deep into it though.

Until Next Time.... :)

How To Be a Programmer

These days I started to use a new tool which integrates well with my Mozilla Firefox brower. It is called Stumble Upon. This tool helps me looking for sites based on the interest (I need to define them first after I sign up with Stumble Upon). While browsing through programming Category yesterday I came across a very good site which says How to be a Programmer. Well it might sound like one of those cheap trick sites, but it is not. Its a lengthy article to read and takes about an hr to read and understand.

There are two major skills identified for the programmer (or developer)

1. Personal Skill
   
2. Team Skill

Each of them are then further divided into sub sections. While the first skill deals with what the person must have in terms of skills required like Technical, Aptitude etc. The second skill focuses more on what it takes to be part of the successful team ie correct estimation, managing self time etc.

In a nutshell its a good read for all those who aspire to build their career in Software Industry and want to grow. It is recommended to read for those who are in Software Industry as well. So that they can identify their gaps and make sincere effort to fill them.

Until Next Time..:)

Service Hierarchy

It was during my regular read from home to work when I came across this idea of Service Hierarchy in an Enterprise Application (for that matter any application). I was reading the book "Extending Web Services Technologies - The Use of Multi-Agent Appproaches" published by Springer.

While in general sense the Services (Web-Services) are classified as Simple and Composite, but in reality there are many sub-classifications possible. On top level there are only two types but the nature of complexity varies in Composite services.


In the diagram above I tried to represent how the services (functionalities) build on the top of simple ones in an Enterprise Information System. The simple services like Create, Save, Update and Delete are at the bottom of the hierarchy. The layer 2 services use the basic ones to meet their functional requirement. Layer 3 builds on the top of layer 2 and so on.

While simple services are piece of software which performs a smaller task. A composite service is the one which is build by assembling and accessing multiple services (possibly from multiple service providers).

This draws our attention to next issue which is Service Composition and Service Oriented Computing (SOC). In the next post will discuss in detail about the Service Oriented Computing.

Until Next Time....:)