Service creation and composition

Chapter 1: Introduction. 2

1.1 Service creation and Delivery Process. 3

Chapter 2: S4ALL. 5

2.1 Service Creation Process in S4ALL. 5

2.2 Contribution of this projection. 5

2.3 Limitation. 6

2.4 Conclusion. 7

Chapter 3: SPICE. 7

3.1 Introduction. 7

3.2 SPICE architecture. 8

3.3 Discussion. 10

3.4 Challenge. 11

3.5 Conclusion. 11

Chapter 4: NEC Approach. 12

4.1 NEC service creation environment 12

4.2 Design Principal 12

4.3 Advantage. 14

4.4 Open Issues. 14

Chapter 5: Conclusion on Service Platform.. 15

Chapter 6: Service Composition. 16

6.1 Introduction. 16

6.2 SCIM... 16

6.3 Policy enforcer in OSE. 17

6.4 Mapping the SCIM into Policy enforcer 17

6.5 Comparison of two Concepts: 17

Chapter 7: Web service composition. 19

7.2 General architecture of web service compositions. 19

7.3 Work-Flow based web service composition. 20

7.4 AI-Planning based web service composition. 20

7.5 Program synthesis based web service compositions. 21

Chapter 8: Conclusion. 22

Reference. 23

Chapter 1: Introduction

Today people are excited with new services available in the internet and mobile communication worldwide. The fixed communication system had limited service in their network. The revenues from voice communication have reduced dramatically while revenues from information and content service have increased sharply. It is prompting the Telco to move from traditional communication provider to diverse service provider.

Service platform was not favorable to create and deploy new services rapidly in the past. With the advent of IP multimedia subsystem (IMS), it is possible to abstract the network in terms of IP. IMS provide features such as call control, session control and mobility management. In IMS, all the services are organized horizontally. Hence there is no need to have separate network for each service. Also, IMS provides service control features for all the services, which are placed on top of IMS. IMS merges all the access networks into one IP network.

Creating a new service or different service rapidly is an urgent need of the dynamic business world today. It is possible within a short period of time if the developer uses some existing services such as messaging, presence services, location services and broadcasting services. These services are called IMS services, which are standardized by Open mobile Alliance (OMA).OMA defined these services as reusable building block and how basic service can be combined to create the new services.

Abstracting services and network together through API makes service creation easy and efficient. This facility is adequately provided by service platform. Service platform supports service creation and deployment consistently. And it is possible to tailoring the services to actual user needs. Personalization, ambient awareness, and adaptability are major drivers for future “I- centric future mobile services”. Service platform is conceptually prepared to accommodate future requirements.

In this special study report, I summarize and analyze two major service platforms of S4ALL, and SPICE to find the information about service creation and deployment and service compositions. In addition to this I am adding information about NEC approach. The document is organized as follows. In chapter two I present information about the S4ALL platform. Subsequently, I review about SPICE in chapter 3. I present NEC approach in the chapter 4. NEC is not similar to S4ALL and SPICE platform, but it has information about service creation environment. I presents the conclusion of the service platform in Chapter 5.To create the composite services, System has feature called service orchestration. It is discussed in two different specification namely service capability interaction manager (SCIM) in IMS and policy enforcer in OMA service environment (OSE).Strength and weakness of these two approaches are discussed in Chapter 6. In Chapter 7, I present current research work in automatic web service composition. Finally, I present my conclusions on service compositions in Chpater8.

1.1 Service creation and Delivery Process

In the telecom service development process, three main stakeholders are participating, namely application developer, operator and end user.

Fig 1.1: Stakeholder, Service life cycle and Functions for service creation and delivery. (Source: NEC)

Service creation is strongly supported by service creation environment where existing service can be found as API and can be reused. These features are embedded in application development environment.

In IMS service architecture, horizontal service approach is emphasized in contrast to vertical approach that exists in PSTN network. To support business and service logic it is separated from network capability, as shown in the figure 1.2.

Fig 1.2: Conceptual idea for Service creation in IMS (Attached later as images)

With this backdrop, Service developer needs to focus on business logic only where network capability is provided via API.

In the telecom world, up to now, service creator is changed from expert to business developer. Based on the business process, business developer can create new service which can be exploited by end user immediately. They can use BPEL (Business process execution language) to accomplish this mission.

But it is found in Internet society that end user can create own services, customize and personalize the services. Therefore, it is anticipated that telecom world should provide the flexibility to end user to create their own services and customize them. This is a key requirement for service creation environment and service deployment environment.

Chapter 2: S4ALL

S4ALL is an Information Technology for European Advancement project. The vision of services in S4ALL is defined by “a world of user centric services that are easy to create, share and use”. Basically, they brought idea from Internet world where service can be created very easily.S4ALL expects that mobile service should have the same success story as Internet has.

To meet the vision of S4ALL: easy to create, S4All has proposed to use semantic taxonomies, service discovery. It will help to find the services semantically. All the service should be reusable, compos able and interoperable. Notion of Semantic orchestration of components and automatic aggregation is identified for service creation. It is easy to compose the complex services. During the service creation, service use abstract description of the existing services. But during the runtime, it will find and bind actual instance of existing service interfaces.

Easy to share: It is generalized method client-server architecture. Using ontology, Created services are semantically published. Platform should help to discover these services.

Easy to Use: Usability is the critical issue. User doesn’t worry about the location and configuration. Service should semantically discoverable too. No configuration.

2.1 Service Creation Process in S4ALL

Main objective of this project is to create the service easily by anyone. Service creation workbench has GUI for service creation. The user of the service editor can create the service just to draw some visual elements. The Output of the editor is called as “Rules”. It is always associated with service building block, which is created from IDE extension. Rules are executed on business rules execution, and service building block is executed on service building block execution engine in SEE. Service building block is abstract-high level service descriptions and will be binding in runtime.

2.2 Contribution of this projection

1) Graphical service creation tool: Service creation become simple based on graphic tools. Icons are just representing the existing service capabilities. It is a big turning point in telecom network. Now anyone (End user(professional), business developer, and software engineer, expert) can create the customized services according to their needs.

2) SOA architecture is used to implement the middleware of the S4ALL.This middleware consists of the semantic discovery and publishing of services, and supports fast and automatic deployments.

3) S4ALL is implemented using open source software from Object web such as OSCAR, JONAS, JORAM, PETALS, etc.

4) Semantic service discovery developed. It basically use tag based descriptions associated with semantic meaning.

5) Each individual service is called as service building block (serviceBB). It is implemented on WI-platform. WI-platform is a service execution environment and is developed by University of Kassel.

WI-platform is responsible for service repository, and discovery, software life cycle management, and security control. WI-platform is developed in java and can be deployed in any devices (size is 139KB).

6) Service can be deployed on PC, or mobile terminal using WI-platform.

7) Semantic based searching is possible. When creating new services, tags are created based on existing semantics. It will allow semantic based searching. Service Repository and Service discovery are available in S4ALL. In Service repository, service building block is stored with WDSL description. Service discovery serves the request with the help of WDSL description parser of the Service repository

8) Service creation tool is going to merge with SPICE projects too.

9) Technology agnostic service creation is developed. So when service creation takes place, creator doesn’t o need to think of technology behind.

10) Service taxonomies are developed and contributed to WWRF WG2, OMA, and W3C.This could be used to develop ontology for NGN services.

11) On Device extension is developed. So, it is possible to invoke the services between the mobile devices.

2.3 Limitation

1) For ordinary users this system is not suitable. Because when there are many services, user has to figure out each services individually and identify the data flow also. Since it is manual, sometimes user will not utilize the best services to compose the services. If there is any way to enhance the system to support the automated service composition, then it will reduce the burden on creator side. So user can specify the goal partially or fully. It is not happened in S4ALL project.

2) Project’s details are not disclosed fully. So far it is not published as paper. Some of the work can’t verify fully. Still it seems black box for some features such as communication between service enablers, and service deployment.

3) Service description still uses WDSL. Semantic web service description such as OWL-S (DAML-S) could be used to increase the automation and searching efficiently. Since S4All uses ontology and service repository, adopting semantic web services is good. So it will increase the possibility to retrieve the exact web services.

4) There is suspicion that how S4ALL can be used to composite the third party services.

5) Some intelligent service can be created. It is not efficiently handled i.e., platform doesn’t tackle this matters. Provider has to handle.

6) S4ALL has to have many features such as security, support for content delivery, DRM for multimedia content.

2.4 Conclusion

It is possible to create the services based graphical icon by anyone if creator knows the process model of composite services. Creator has to take care everything other than discovery, publishing, and service orchestration. It could be best model when a number of available services are limited and process model is predefined or known. It is possible to create the personalized, intelligent services using S4ALL. For example, using context provider, when mobile user arrived in home, video can be displayed in home entertainment system.

Chapter 3: SPICE

3.1 Introduction

SPICE (Service Platform for Innovative Communication Environment) is IST-FP 6 project. This project is lead by France Telecom.

The goal of this project is to research, prototype and evaluate an extendable overlay

architecture and framework for rapid creation and deployment of intelligent and personalized mobile communication and content & information Services.

The following are the project objectives to reach this goal.

1) Provide an easy and simple way to create and roll out innovative services to reduce development time, costs and risks

2) Provide a unified and seamless way to deliver services over heterogeneous execution platforms, network and terminals

3) Enrich the service landscape, through an overlay structure supporting the users and offering a personalized user experience anytime, anyplace;

4) Create a trusted and open platform that will simplify the use of services, devices through personalization and customization

5) Enrich current service platform functionality with content management features and intelligent service controlled context-information processing

6) Open-up to new business models & value chains.

7) Enable Pan-European service provisioning, and seamless roaming of applications and services across commercial and national borders.

8) Promote the uptake of innovative IT software technologies in telecommunications grade service platform environment

3.2 SPICE architecture

To develop the architecture, they adopted following principals.

1) Architecture should support Platform centric approach. So Telco operator can become the service platform operator. This idea is supported by S4ALL.

2) It should take care of multi terminal, multi access distributed communication sphere. This feature is properly addressed by SPICE and doesn’t consider in S4ALL.Current technology world is witness for multi terminal and multi access. This is taken into account when SPICE is designed. It has a big impact on service platform.

3) Service compos ability and loosely coupled approach: It will provide more flexibility to service developer, operator, and third party service provider and speedup the service creation. This idea is commonly used in many places and applied in S4ALL and SPICE also.

4) Semantic enhanced platform. There is trend that machine can read the document and understand. By adding this feature, it will enrich the service platform and end user.

These principal are best practice in IT and Telco world. First two are from Telco world and rests two are from IT world.

Fig: 3.1 overview of the SPCIE architecture (Source: SPICE_WP2_2_Semantic Publication Architecture for Service Enabler Components)

,

As shown in the figure 3.1, SPICE has four layers.

1) Capability & Enabler: This layer is quite relevant to IMS services or IN legacy services. SPICE resource adapter is used to connect to these networks.

2) Component service layer

3) Knowledge layer: SPICE intelligent service depends on this layer to make a decision. Learner and knowledge tool fall in this layer.

4) Value added service layer:

Based on this architecture, following are achieved.

1) SPICE architectural framework

2) Middleware service enabler:

3) Intelligent service enabler: It is a unique feature in SPICE. SPICE has user profile, context information, and user behavior for enriching the services. It is associated with reasoning system also.

Two enablers,”personal information enabler and knowledge information enabler”, are providing knowledge and contextual information about the end user and situation. Another service enabler, “attentive service enabler” makes use of this information to provide the right services. Because of attentive service enabler, when user change the situation, system provide the alternative services for choice or adopt suitable services based on the situation.

Purpose of having intelligent service enabler is enabling to rapid service development without implementing the intelligent information separately. This intelligent information can be easily added into services. The SPICE system takes care of intelligent service enabler. So it reduces the burden on service developer.

4) Service creation and life cycle management: The scope of the work here is that customer can create the own services or service provider can create the services quickly by listening the customer requirement.

All the phase of service creation life cycle is supported by SPICE. Conceptually following idea are developed to enhance service creation and execution.

a) Service creation tool: It makes easy the service creation. Mostly it uses idea of S4ALL In addition, they try to do service description language based semantic languages (OWL-S, WSDL-S).

b) Service description language for composition. It is empowered with semantic information associated with the services. Requirements for service description language are that easy to create from service creation tool, easy to execute, and allowing the composition.

c) Multi platform service execution environment: Execution environment can be JAIN SLEE or J2EE. Interoperability between JAIN SEE and J2EE is extended. It supports to create the more complex services.

d) Service delivery: SPICE supports intelligent service delivery based on user’s preferences and context information.

e) Automatic service compositions: This part is not identified in S4ALL. SPICE has automatic service composition engine. Automatic Service composition is made based on ontology and semantic description languages, and semantic orchestration. The idea is developed and but how automatic service composition is achieved is not disclosed in any document so far.

5) Service access control and trust management: This feature is not address by S4ALL. SPICE supports AAA (Accounting, Authentication, Authorization) between service provider, third parties, and users. It implements three key elements: Identity management, authentication engine, and policy management.

Service exposure layer is defined as interface between third party provider platform and service platform. It implements the access restriction and Service level agreement (SLA).

6) Information and content delivery: In S4ALL, there is no special arrangement for information and content delivery. But it is addressed as follows.

a) In content provider side, Content is formatted in various ways for delivery over various network and end devices. Initially content provider set the requirement for the content. Context related information is gathered and is used to adopt the services based on the context.

b) Metadata of the content is shared with service provider to make retrieval effective.

c) SPICE provides DRM support in addition to delivery and retrieving of the content.

3.3 Discussion

As shown in figure, SPICE platform can be integrating with IMS and Non IMS platform via Resource adapter. But in S4ALL is only supporting IMS platform.

Since it adopts the way S4ALL use to create the services, there will be no difference in the cost, development time, and risk. SPICE has more features than S4ALL.Common feature between them is method service creation. SPICE can be considered as full fledge service platform which use IT and Telecom principals.

In conclusion, it covers many needed aspects of service platform which are listed below.

1) Service creation tool and loosely coupled services

2) Multiplatform and multi platform environment

3) Service roaming when user move different operator network.

4) Semantic information and knowledge reasoning is used in many places for example, it uses semantic information to find the services in service creation.

5) Multi access network and diversified devices.

6) Service composition engine and automatic service composition

7) Open service platform for 3^rd party service and content provider.(security and )

8) Considered properly for multimedia provider.

9) Supporting the intelligent services based on context, user profile, and user history.

3.4 Challenge

When SPICE is design it takes into account 3G and beyond network. But it is not specifically designed for virtual network operator (VNO). Since SPICE has strong exposure and mediation layer, it is possible to extend further.

It is also support service creation and execution. Notion of automatic service composition and creation is identified, but it is not clearly how it is designed and developed. There are some methods for web services compositions based on AI planning and program synthesis.

3.5 Conclusion

SPICE has excellent service creation and execution environment for 3G and beyond network. Intelligent and personalized mobile communication and content & information services can be created and executed easily in SPICE. SPICE platform has four layer namely, capability and enabler, component service layer, knowledge layer, and value added service layer. SPICE execution environment consists of components which are executed in at least two platforms and has interface for publishing, discovered, and executed. Knowledge layer is a unique feature in SPICE and is used for personalization and context aware services. SPICE can be considered a fully fledge service platform.

Chapter 4: NEC Approach

4.1 NEC service creation environment

NEC service creation environment (SCE) satisfies the requirements of the OMA, which defines the future Mobile Service Architecture. Key concerns of this environment are policy control and security. This SCE is development and runtime environment which provide following feature to software engineer:

1) concrete interface (binding) to service enabler

2) a programming model that fits the asynchronous nature of telecommunication services.

3) an implementation model allowing to compose more complex service from simpler one.

4) a fine grained authentication and access control

5) Specialized application server providing a rich and flexible development environment.

4.2 Design Principal

A) Functional View

Service Integration framework (SIF) is the solution for the service creation environment by NEC. Service Integration framework supports fundamentally the following functional features:

i) Service delivery integrating service enabler by providing access control and controlled service usage.

ii) Dynamic service orchestration for value added service creation by means of dynamically integrating single or composed services via policy handling and mediation control.

iii) Application provisioning by supporting subscription handling, profiling and advertisement.

In Service Integration framework, application are deployed and executed in application execution platform. In Service Composition, Policy resource model is used to provide the controlled access and delegation.

B) Architecture

NEC service creation environment is in line with OSE. It consists of service provisioning, service enabling frame work, and supporting development tools. These elements are placed on top of IMS enabler.

Primary tasks of the service provisioning are application subscription process, user and service management, application advertisement, and discovery. SIF can integrate service provisioning platform MUSE or any other suitable provisioning platform.

Service enabling framework (SEF) is a main component in SIF. It can be divided into three parts: Application Control, Frame Capability control, and Management function.

1) Frame Capability Control:

The binding object is the bridging object between the application and service enabler. This object is implemented in this framework. This element is crucial element compared to other element since FCC represents the network abstraction layer to the application.

To realize the binding object, Web services, SIP, and HTTP can be used as transport protocol. NEC uses SIP/SIMPLE protocol for communication between service enabler and FCC IMS client in binding object side.

2) Policy Management and Enforcement.

Based on OSE, Policy enforcer is important for controlling the access between application or third party service enabler and service enabler and resources. NEC implemented this feature in Policy evaluation and enforcement Manager (PEEM). This is used to implement the security policy also.

The PEEM consists of following elements.

1) Policy management, which helps to create and maintain policies for registered resources. Decision factors for policies are request/response type, requestor/responder access rights and roles.

2) Resource management: A resource is considered as service providing entity. To efficiently manage the access, dynamically registering the resources to the framework is important.

3) Policy decision module: Semantically find the policies for the request and response.

4) Policy enforcement: apply the policy to the request.

5) Event management: handle the events which are raised by services enabler.

The usage of PEEM can be described by two different ways: Proxy usage pattern and callable usage pattern. Policy enforcer is in between target resource and requestor in proxy usage pattern, whereas policy enforcer is queried by target resource when it receives the request from requestor in callable usage pattern. In proxy usage pattern, Request is policed and can be re-routed to additional processing such as charging, load balancing and logging. In callable usage pattern it is easy to integrate the security using policies.

Because of different usage patterns, it is easy to add additional features to service enabling framework. Based on this additional feature SEF can be extendable and flexible.

C) Implementation

The realization for the SEF is implemented in J2EE technology. IMS service enablers are implemented in IMS application server. The FCC has two components: IMS binding interface and IMS agent. JAIN protocol is used to communicate between these elements. Here binding interface uses RMI to interact with application via policy enforcer. IMS agent in FCC has control plane and data plane. Real Time protocol/ Real Time Control Protocol (RTP/RTCP) is used for data plane between FCC IMS client and IMS services, and FCC IMS client and Media Manager (Media Enabler).At the same time, control plane between IMS Client and IMS services use SIP/SIMPLE protocol.

4.3 Advantage

1) Service developer makes use of OMA service enabler efficiently to create new user friendly mobile services.

2) Service provider opens their network to 3^rd part service provider securely.

3) The object oriented development technology is used to realize the high level architecture. It is known to many software developers. Number of object-oriented developer is growing. The service creation is moved from the hand of the experts to OO software engineer.

4) It is easy adopt the future change since its implementation is based on OO technology.

4.4 Open Issues

In this SCE, business logic has to be implemented by software engineer even though service creation is easy and efficient. So there should be tool to create service by business developer. There was a suggestion to adopt BPEL or UML or MDA for service creation environment. It will allow business developer to create new service without heavily depending on software engineer/expert.

Chapter 5: Conclusion on Service Platform

Based on the information of S4ALL, NEC service creation, and SPICE, SPICE outperforms all other platform. SPICE has all the feature of S4ALL and NEC service creation and has more valuable features also. S4ALL is mainly focus in service creation based loosely coupled approach. This idea is taken into SPICE also. At the same time, key interest of NEC approach is to use policy enforcer and security for flexible service usage and interaction between service platform and third party. This idea is also adopted into SPICE. SPICE become open and controlled environment.

Chapter 6: Service Composition

6.1 Introduction

Service is an important term in today’s business sector. In the telecom world, service became popular when telecommunication network adopted NGN or IMS. At the same time, IT world heavily use the term “service” after the web services and SOA are invented.

Service is usually assumed to provide an intrinsic function or functionality. The composite service or application makes use of many intrinsic functions. For example, many applications need authentication function in their implementation. Instead of implementing own authentication in each application, they use one common authentication service for all the application. This approach has many advantages, therefore, it is considered as best practice. This idea is also used in OSE.

With this backdrop, service composition has been realized as important to create potential application or tailor made application. Service composition in IMS is envisioned via the service capability interaction manger (SCIM) at service control layer and policy enforcer in service layer as specified by OMA.

6.2 SCIM

Notion of SCIM is introduced in the specification of IMS. SCIM is handling the interaction between service capabilities. Integrated service is possible at the SIP level using the SCIM. It is considered as middleware building block between the service layer and control layer. The specification does not specify the functionalities of SCIM in detail. But in [10], procedural aspects and architectural aspects of SCIM are defined. Invoking multiple service capability and controlling the interactions are the main challenges for SCIM.

SCIM supports the interaction with service capability, S-CSCF, and other SCIM. It procedurally invokes the service capability using a predefined service capability interaction model which defined the order of the invocation.

At the same time, architecturally, it is considered to place SCIM together with S-CSCF instead of placing separately between CSCF and service capabilities.

Even though it supports service composition at SIP level, to realize the full potential, there are some areas that should be focused.

1) Dynamic extension of the service capability interaction rules

2) Categorizing the services and users. Interaction is not associated with services and users in the specification.

3) Extending the functionalities to other service platform than IMS.

It is considered as crucial in new environment where multiparty such as content provider, service provider, and VNO involves different services. They might not be in a position to implement SIP protocol. For some needs, some other protocols are good compared to SIP. For example, XCAP is used to pass group information in group communication. And, according to future direction of service architecture, Future services are based on context, ambient awareness, and personalization. These services may use other protocols based on HTTP in addition to SIP. But it is demonstrated by implementing XCAP in SCIM in [9].

4) SCIM can interact with web service interfaces. In case the service capability is provided by web services, it is easy to orchestrate using available technology such as BPEL4WS [9].

6.3 Policy enforcer in OSE

Open mobile architecture (OMA) developed service architecture for future mobile services. OMA service environment is built on top of IMS platform or other platform. Logical architecture of OSE consists of service enabler, service binding interfaces, policy enforcer, application, and execution environment. This service enabler is similar to service capability in 3GPP. Service enabler has interface to network resources and terminal and binding interface to application, and other service enablers.

Main task of the policy enforcer is to protect the resources from unauthorized access. And it also supports the service coordination. It has the following advantages since it uses concept of policy:

1) Support the service composition or workflow.

2) Policy is the flexible way to protect the resources, because policy is enforced for request and response.

3) User’s preference and setting can be expressed and enforced in policy.

4) Operator can apply his/her preference and setting in policy.

5) QoS, accounting and access can be implemented in Policy.

6.4 Mapping the SCIM into Policy enforcer

In [8], Functionality of the SCIM is achieved by placing it in policy enforcer. In this case, SCIM interact with service enabler via service binding interface such as web services, SIP. SIP AS server should be within the premises of the service providers. The un-trusted (third party) external application should use PEEM for accessing the network resources.

6.5 Comparison of two Concepts:

There are two concepts used to compose the integrated service in IMS service environment as explained in the previous chapter. In this chapter I present the comparison between these concepts in terms of service compositions.

1) The SCIM compose the services at SIP level. But, in policy enforcer the services are coordinated via the binding interfaces, which are mapped from SIP to higher level. SCIM receives benefits without performing any mapping.

2) Policy is a flexible way to implant the user’s preference, setting, operator setting, and access control. Multi party environment is healthy when stop shower (security,.) are in places

3) Concrete implementation of OSE is possible with carrier grade J2EE technology [15]. Considered carrier grade features are availability, throughput, latency, management, and event driven architecture.

4) OSE support open and controlled access for other services. It will give room for innovative services in the future.

Chapter 7: Web service composition

7.1 Introduction

The W3C defines a Web service as a software system designed to support interoperable Machine to Machine interaction over a network [18]. Main characteristic of web services are loosely coupled, universal accessible and standard languages. New paradigm called “Service oriented architecture” is mainly driven by web services.

Original standard of web service includes SOAP, UDDI and WSDL. It is called Web services V1.0. Web service V2.0 is extended with additional specification such as WS-Security, WS-Reliable and WS-Transaction.

Semantic web services: It consists of more information compared to web services description based on WSDL. It uses ontology to describe about the web services.

There is demand for system/software which can retrieve and compose the web services when user gives his goal to the system [20]. It could be achieved using automated semantic web service compositions. The actual challenge is unknown process model and binding information. There are two methods available for web service compositions such as BPEL4WS and DAML-S. In this case process flow and binding information is known and the user just describes using these languages.

7.2 General architecture of web service compositions

Fig 7.1: Abstraction of web service composition presented by Jingahai Rao in his PhD thesis.

Abstract idea of web service composition is presented in [20]. It has five parts and doesn’t specify any language or platform.

1) Presentation of web services.

2) Translation of languages

3) Generation of composite process model

4) Evaluation of composite services

5) Execution of composite services

Web service composition is currently a hot topic in research community. There are three major directions to do web service composition. Those are based on business process (work flow) or AI planning, or logical based program synthesis.

7.3 Work-Flow based web service composition

Workflow based composition can be categorized in tow ways: static and dynamic. In static workflow based composition the user specifies the abstract process model, and binding of atomic services take place automatically. In dynamic nature both process model and binding of atomic services happen automatically. Here, the user needs to provide preference and constraints. EFlow is an example for static workflow based composition. Composition service definition language (CSDL) is a refinement of EFlow. Another approach is composite logic which consists of sequence of atomic service execution and message dependency among the services.

Polymorphic process model (PPM) is an example for static and dynamic service compositions. Static part of the PPM is similar to EFlow. Dynamic part of PPM is enabled by state machine and reasoning based on state machine.

Workflow method is preferred when process model is known

7.4 AI-Planning based web service composition

AI planning based web service composition is a second approach. Four methods of web service compositions based on AI planning are listed below.

1) Situation calculus

2) Planning domain definition language

3) Rule based planning

4) Theorem proving

AI planning based service composition is used when user has no process model but has preference and constraints.

Automated web service composition is really a challenge compared to classical web service composition where process model is known. AI planning and logical methods are discussed by research community for automated web service compositions.

Typical AI planning method is needed at the initial stages of service composition. But, normal user could explicitly specify the goal of the service composition rather than initial states of service compositions. This method is just considered as the functionalities of the services for service composition and does not take non-functional features into accountant.

7.5 Program synthesis based web service compositions

Motivation of this method is based on concepts of deductive program synthesis where process generation is highly associated with proof theory. Liner logic based theorem is proved to automate the semantic web services compositions [20]. Liner logic is used to specify the concurrent programming and has more expressive power than classical logic. The correctness and completeness can be proved in logic based method [20].

In this method, DAML-S is used to represent the web services externally. DAML –S service profile is converted into liner logic using the translator. For instance, all the web services are converted into LL axioms and user request is converted into LL Sequent., Process model of the composite services is developed using LL theorem prover. Process calculus is used to specify the process model. At this point, Liner logic inference rules are integrated with process calculus. It is for semantic reasoning of valid data flow of data types. Composite service is developed in DAML-S service model from process calculus or BPEL4WS where process flow and data binding is known.

This approach sets many advantages:

1) User does not compute all the available services manually.

2) Since liner logic is resource concise, it can capture the concurrent features of the web services (non functional attributes).

3) Semantic information is used for matching and composing the web services.

Some functionality is not considered when it is designed. Those are security control and transaction management. These two are broad areas, but it is important to add this functionality to release the operational product.

At the same time limitation is identified by author [20].

1) Propositional logic is type correctness. But it is not possible to verify the correctness of the instance of the type during the runtime. It could be addressed by adopting the first-order LL. It should be analyzed deeply to identify the trade-off.

This method is a fully automated web service composition. But there are arguments that fully automated are not needed all the times. Instead it could be an ideal solution for implementation of skeleton automatically.

Chapter 8: Conclusion

The service composition takes place in two places: SCIM in IMS and policy enforcer in OSE. Based on industrial support and flexibility, policy enforcer in OSE is considered as the best places for service compositions.

Web service is gaining momentum because it is standard based, loose coupling and has Universal accessibility. The implementing and executing web service composition in policy enforcer is mostly a preferred solution if service enabler provides the web service interface. In this case, composite web service is represented by BPEL4WS and DAML-S service model. BPEL4WS is superior to DAML-S service model. Automated web service composition will draw attention when user creates the service in his own in IMS/NGN.

Even though many concrete implementations for web service composition are not available for web service composition, it is possible to conclude theoretically that program synthesis based service composition outperforms the AI planning and workflow based service compositions. Logic based web service composition is one example for program synthesis based compositions. This example is using the non functional attributes and fully automated. Non-functional requirement (For example, bandwidth) is important feature to compose the communication services.

Reference

[1] Drogehorn, O., Bernd Mrohs, Stefan Arbanowski, “S4ALL workshop presentation” , http://www.s4all.eecs.uni-kassel.de/220/

[2] François Carrez, S4ALL , An Introduction, March 2005

[3] Cordier, C. Carrez, F.. Kranenburg, H. V Licciardi, C. Der Meer, J. V. Zoric J., Spedalieri A. and Jean-Pierre Le Rouzic (2006). Advanced Beyond 3G service delivery environment: the SPICE service platform design principles. WWRF/WG2,April 2006.

[4] Sasu Tarkoma, Christian Prehofer ,V. Zhdanova, Klaus Moessner, Ernö Kovacs

“SPICE: Evolving IMS to Next Generation Service Platforms”, Proceedings of the 2007 International Symposium on Applications and the Internet Workshops (SAINTW'07),IEEE computer society.

[5] . Schülke, E. Kovacs, H. Stuttgen, A. Akkawi, M. Kuhnen, A. Riu, Florian Winkler (2005) Creating New Communication Services Efficiently. NEC Journal of Advanced Technology, Vol. 2, No.2 , pp. 170-178, Spring 2005

[6] SPICE WP2 : D 2.2

[7] Christopher J Pavlovski , Quentin Staes-Polet, Digital Media and Entertainment Service Delivery Platform

[8]Imen Grida Ben Yahia, Emmanuel Bertain, Jean Pierre Descrevel, Noel Crespi, “Service Definition for Next Generation Networks”

[9] Yasuhiro ARAKI, Akio YAMAMOTO, Michael Sweeney, Dynamic Community Entertainment Services Composition on Next Generation Mobile Network IP Multimedia Subsystem., Page(s): 5-5, Digital Object Identifier 10.1109/SAINT-W.2007.44

[10] Anahita Gouya,Noel Crespi,Emmanuel Bertin, “SCIM (Service capability Interaction manager) Implementation Issues in IMS Service Architecture”

[11] 3GPP, “IP multimedia Subsystem (IMS)”, TS 23.228,Release 6.

[12] 3GPP, “IP session”

[13] http://www.openmobilealliance.org; OSE Architecture

[14] Marco Cargui,ITU, NGN services, http://www.itu.int/ITU-D/tech/network-infrastructure/Bahrain2007/Presentations/Day1/Presentation_Bahrain_MCarugi_2.pdf.

Last visited August 2007.

[15] Oracle, “Carrier-grade J2EE: The foundation of the Oracle SDP An Oracle White Paper”

April 2006 , http://www.oracle.com/products/middleware/service-delivery-platform/docs/sdp-carrier-grade-j2ee.pdf ,Last visited August 2007.

[16] Magedanz,http://www.fokus.fraunhofer.de/go/ims/opensoaplayground/pdf/SOA_in_Telecommunications-Magedanz-06-2007.pdf,Last visited August 2007.

[17] Biplav Srivastava, Jana Koehler, “Web Service Composition - Current Solutions and Open Problems”, http://www.zurich.ibm.com/pdf/ebizz/icaps-ws.pdf, Last visited August 2007

[18] Satya Sanket Sahoo, Web Services Composition (An AI-based Semantic Approach) lsdis.cs.uga.edu/~satya/Presentation/Web%20Services%20Composition.ppt -

[Last visited August 2007]

[18]http://en.wikipedia.org/wiki/Web_service

[19] WSMO and OWL-S

[20] Jinghai Rao, “Semantic Web Service Composition via Logic-based Program Synthesis”, Thesis report, NTNU.