Web Service in Context and Dependency-aware Service Composition

Transcription

1 2007 IEEE Asia-Pacific Services Computing Conference Web Service in Context and Dependency-aware Service Composition Jiehan Zhou 1,2, Eila Niemelä 1, Juho Perälä 1, Daniel Pakkala 1 1. VTT Technical Research Centre of Finland {firstname.surname@vtt.fi} 2. Department of Electrical and Information Engineering, University of Oulu Abstract Service composition enables service users to develop Web applications by composing services via Internet. Traditional service description is function-centred, but lack of composition information, which hinders service composition with respect to service contexts. In this paper, we examine service composition information (i.e. service contexts and service dependency). The contextaware service management platform that we developed provides support for service users to compose services by managing service dependency. 1. Introduction Service composition enables service users to develop web applications by composing services via Internet. Web applications are increasingly growing across enterprises, platforms and business. This results in the growing attention on context-aware service-oriented computing (SOC), which is characterized by broad ranges of service contexts and interactions. Commonly used Web services (e.g. SOAP (Simple Object Access Protocol) [1], WSDL (Web Services Description Language) [2], UDDI (Universal Description, Discovery, and Integration ) [3]) establish a basic SOC platform for accessing, describing, discovering, deploying and invoking Web services. However the conventional SOC focuses on the functional description for a service. Correspondingly, the conventional SOC platform is restricted in capabilities of context-aware service computing, e.g. dependency-aware service composition, context-aware service discovery. This paper aims to identify the structure of service contexts and Web service dependency and explore dependency-aware service composition. In what follows, basic definitions are specified in section 2. Section 3 briefly overviews related studies. Section 4 presents service-oriented architecture evolution. Section 5 examines a motivation example. Section 6 designs the structure of service contexts and Web service dependency. Section 7 demonstrates a prototype of context-aware service management platform supporting dependency-aware service composition. Conclusion and further work are given in section Definitions Service in context. Service is an action or operation directed by a service actor (e.g. a provider or requestor). Service is a marketing service in the sense of applying the marketing process: service advertisement, service discovery, and service engagement. Service is developed, deployed and invoked within a certain technical environment (e.g. operating systems and component standards). Service communicates with the environment through its interfaces, which encapsulate clear specifications of what the service requires and provides. Service resides in IP-capable devices; it can be remotely accessed and invoked via Web-accessible terminals. A service can be used for application composition and service composition. Service contexts refer to entities interacting with a service during the service s lifecycle, such as the actor directing a service, the device hosting a service, the terminal accessing a service, the technique equipping a service, etc. Application composition is an abstract process for composing services. The composed application only becomes concrete at run time [4]. Composed application cannot provide interfaces for other services. In this sense, a composed application cannot be deployed over Internet. In contrast, a service composition has the same process as the application composition, but the composed service provides interfaces for other services and applications, which can be deployed over Internet. In section 7, a prototype demonstrates an example of composing and deploying a home security service by managing service dependency. Web service dependency refers to the relationship between the entities of services and service contexts. Web service dependency is a general property of the class service, and is sub-categorized into the properties of context dependency and service dependency. The property of context dependency refers to the relationship between services and service contexts (e.g. a service is hosted by a device). The property of service dependency refers to the relationship among services (e.g. a service uses another service). The detail on the difference between Web service dependency and service dependency is given in section 6.2. Elementary service is an independent service that does not have service dependency with other services. In contrast, composite service is composed of elementary services, which has at least a type of service dependency with other services. 3. Related studies This section presents the latest information on service oriented architectures (SOA), Web service /07 $ IEEE DOI /APSCC

2 specifications, application composition, and service management platforms. SOA architectures. A number of SOA architectures, such as OASIS SOA [5], IBM SOA [6] and S3 [7], W3C SOA [8] and Extended Service Oriented Architecture [9], address the SOC paradigm. They attempt to provide a uniform means to offer, discover, interact with and use Web services over a variety of environments. The OASIS SOA does not address the orchestration of multiple services. IBM SOA [6] supports integrating business tasks or services for building composite applications. IBM S3 [7] provides a detailed architectural definition of an SOA across nine layers that aim to reinforce business value. W3C SOA [8] specifies four broad steps for service providers and requestors to engage and use a Web service crossing enterprises. Extended Service Oriented Architecture [9] specifies a reactive and adaptive IT environment, which provides the means to represent detailed business policies and rules. Our research highlights contextaware service description and dependency-aware service composition in SOA. Web Service specifications. Commonly used Web service specification languages, such as SOAP [1], WSDL [2], and UDDI [3], define standards for service description and discovery. However, these web service specifications do not deal with the composition of existing services and reasoning about web services. Application composition. Supporting standards for application composition include Business Process Execution Language for Web Services (BPEL4WS) [10], BPML (Business Process Management Language) [11], WSCI (Web Service Choreography Interface) [12], and OWL-S [13, 14]. These standards are generalpurposed. In contrast, service contexts and Web service dependency specified in this paper results from analyzing concrete service contexts and it can be practiced by service users. Service management platforms include Jini [15, 16], Web services [6], OSGi (Open Service Gateway Initiative) [17], and Gravity [18]. Jini applications are developed by the integration of Jini services with the mechanisms for service registration, lookup, and notifications. Web services [6] target business enterprise application integration by applying mechanisms of SOAP [1], WSDL [2], UDDI [3]. OSGi concentrates on delivery, deployment, and remote administration of service management for devices. Gravity [18], an extension of OSGi, aims to enable applications to evolve and adapt dynamically to all changes by managing the dynamic availability of application building blocks. However, the above platforms focus on function-based Web application development and they are restricted in supporting dependency-aware service composition. The contextaware service management platform developed by us supports not only context-aware service description, but also dependency-aware service composition. 4. SOA evolution The conventional service-oriented architecture is proceeding with the following challenges: Extended service partners. A service runs on environment. The involved participants include operating actors, deploying techniques, hosting devices, accessing terminals, etc. Extended interactions among them. Correspondingly, the interaction becomes crosspartners communications, including service hosting device management, terminal access control management, service actor information management, etc. Extended techniques. Service deployment techniques are built not only upon traditional service specifications such as SOAP [1], UDDI [3] and WSDL [2], but also upon OSGi framework [17], UPnP (Universal Plug and Play) [19], DPWS (Device Profiles for Web Services) [20], Session Initiation Protocol (SIP) [21], etc. Extended applications. Service applications go beyond traditional service description and discovery towards applications such as service access control and service context monitoring. Service composition. Service is used not only for application composition but also for service composition. Semantics. The semantic Web services enable service users to manage and develop Web applications semi-automatically or automatically. Service dependency ontology is assumed to be a key enabler for achieving this goal. 5. Motivation example This section presents a motivation example, showing how a home security (HS) service is composed by utilizing existing elementary services and managing service dependency. The interaction of the HS service composition and activation is illustrated in Figure 1. The HS service utilizes elementary services registered in the home gateway [22] (a part function for containing home services), such as door open and motion detection to monitor home environment, the digital camera service to obtain video stream and still images, and the X10 [23] control service to control the home lighting devices. Multiple service contexts and service dependency are contained in the context-aware HS management. Service contexts include directed actors (e.g. a home owner), hosting devices (e.g. a digital camera or an X10 device), accessing terminals (e.g. a mobile phone), utilized techniques (e.g. UPnP or SIP) and elementary services (e.g. a video capture service or a light switch service). Service dependency, for example, the HS service uses video recording and light switching service; image capturing service is an alternate service of video recording; the light switching must precede video recording or image capturing. In addition, the context-aware HS should describe its QoS level to ensure the alarm s priority. 350

3 Figure 1. Diagram of the HS service composition 6. Web service in context In the motivation example, before using the HS service, the service user may want to check: what kind of service it is dealing with? What device it is hosted by? What terminals can access the service? What elementary services it is composed of? How these elementary services interact with each other? What interfaces it provides to other services and applications? What about the security quality attributes of the service? What technologies are utilized by it? and so on. Then, an important goal for the context-aware SOC is to establish a context-aware service description system, within which the above detailed information can be easily contained and retrievable for a given service. Figure 2 illustrates the diagram of service in context, including service contexts and Web service dependency. The diagram specifies minimum and maximum cardinality for the properties between service and service contexts Service contexts Service contexts are sub-categorized into: service, actor, data, interface, technique, device, terminal, QoS, and application elements. Service, a set of network endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. The general metadata about a service includes serviceid, servicename, servicetype, serviceversion and servicedescription. Actor. A transaction in the Web services marketplace involves diverse parties: the service requesters, the service providers, the service composers, network provider, device and terminal vendors, and so on. The general metadata about an actor includes actorname, actortype, actorcontact. Data refers to variables, or parameters required or returned by interfaces provided by services. Data structure maintains general information about the classifications of input/output data, data formats, data types, complied schema, and fault data. Interface. Interface refers to an abstract description on actions or operations that a service provides to other services and applications. The interface structure specifies functional characteristics of a service. General metadata about describing an interface includes interfaceid, interfacename, interfacedescription, and interfacetype, etc. Technique. Technique structure provides the technical information needed by applications to bind and interact with Web services being described. It provides a structure that describes a Web service conforming to a particular set of specifications, mainly to do with transport protocol, message formats, and binding mechanisms. Device refers to IP-capable devices, which are responsible for hosting and deploying services via Internet. A device container is used to identify the device type, hosted services, for locating and invoking services. The device properties are such as deviceid, devicename, devicetype, devicedetaileddescription, hostedservices. Terminal refers to IP-capable resource used to access Web services. The terminal structure is used to identify the terminal type, status and accessible services, etc. The terminal properties are such as terminalid, terminalname, terminaltype, terminalstatus, terminaldetaileddescription, accessibleservices. QoS refers to Quality of Service, measuring the degree of usage satisfaction of Web services. For example, some services may be reliable, and quick to respond; others may be unreliable, sluggish, or even malevolent. In [24] a QoS specification is presented for identifying the service quality types. Application refers to a composition of services for achieving a logic business goal. General metadata about describing an application includes applicationname, applicationversion, applicationdescription, applicationpartner, requiredservices, etc. 351

4 Figure 2. Web service in context 6.2. Web service dependency The Web service dependency provides the structure for describing information about the relationship between services and service contexts. It is subcategorized into service context dependency and service dependency (Figure 3). Both of them are the object properties of class service. The service context dependency defines a property taxonomy that is used for representing relationship information between a given service and its context objects, e.g. what interfaces does a given service provides; what services does a given device host; what application is using a given service, and so on. The service dependency defines a set of taxonomies used for representing interactions between services, e.g. what functional dependency does a composite service have on its elementary services, what is the temporal dependency between services, etc Service context dependency Eight sub-types of context dependency are defined in the service context dependency property (Figure 4). Each sub-property indicates a relationship between a service object and a context object. The context dependency provides a lightweight way for describing and managing service contexts and their relationships. For example, the service user can register information about actor objects and service objects by using the actor structure and service structure separately, and retrieve the relationship between registered actor objects and service objects by the actor_service_dependency element. Figure 3. Web service dependency Figure 4. Service dependency taxonomy 352

5 Service dependency The service dependency is a sub-type of Web service dependency property that indicates an interaction control relationship between two services, such as functional control, conditional control, and temporal control (Figure 4). The functionaldependency indicates the dependency between two services in functions. The following lists some sub-properties for the functional dependency property: useservice. Service A uses Service B if B must be installed and activated in order to run A. conflictwithservice. Service A conflict with Service B when A will not operate if B is installed and activated. alternativeservice. Service A is the alternative of Service B when A is not needed to be installed and activated if B is already installed and activated. The conditionaldependency provides the facilities to specify the conditions and exceptions for a service to be executed. There are two sub-properties of the conditiondependency: repetitiondependency and selectiondependency. The repetitiondependency specifies that a service can not be executed until it reaches a certain state. This is expressed with constructs such as while, repeat, for or do-until. The selectiondependency specifies that a service be executed depending on the current service state. This is expressed with constructs such as if-then-else-endif, switch, or case. The temporaldependency indicates the ordinary (a) Elementary service description // elementary service description in OWL <Service rdf:about="#lightswitchservice"> <hasservicedescription xml:lang="en">light switch service</hasservicedescription> <hasservicename xml:lang="en">lightswitchservice</hasservicename> </Service> <Service rdf:about="http#videocaptureservice"> <hasservicedescription xml:lang="en">video capturing service</hasservicedescription> <hasservicename xml:lang="en">videocaptureservice</hasservicename> </Service> //composite service description in OWL <Service rdf:about="#ihsservice"> <useservice>videocaptureservice</useservice> <useservice>lightswitchservice</useservice> <hasservicedescription xml:lang="en">composed home control service</hasservicedescription> <hasservicename xml:lang="en">ihsservice</hasservicename> </Service> (b)dependency-aware service composition (c) Service deployment and activation Figure 5. Prototype of the context-aware service development and management platform 353

6 sequential control between service performances. There are three sub-properties of the temporal dependency: forward dependency indicates that a service is performed before another service; backward dependency indicates that a service is performed after another service; and parallel dependency construct indicates that services are performed concurrently. 7. Demonstration A preliminary prototype is developed for contextaware service development and management, which implements the scenario examined in the motivation example. A set of snapshots demonstrates HS service composition and activation, including elementary service description (Figure 5a), dependency-aware HS service composition (Figure 5b), and HS service activation (Figure 5c). Lessons learnt from the prototype development are as follows: 1. The prototype uses UPnP technology for elementary services discovery and deployment of composed services. 2. The context-aware service management is deployed in the OSGi framework. We use the Oscar [25] for OSGi implementation. The other OSGi implementations are Equinox[26], Concierge[27], etc. 3. The context-aware service management platform prototype supports dependency-aware service composition. 8. Conclusion and future work Evolving service-based business integration attracts researcher s and practitioners attentions on the contextaware service-oriented computing. By leveraging factors contributing to future Web services, this paper focuses on exploring the structure of service contexts and service dependency and dependency-aware service composition. First, basic definitions are specified and related studies are overviewed. Second, service oriented architecture evolution is presented and a motivation example is given. In addition, the structure of service contexts and service dependency is designed. Finally, the prototype of context-aware service management platform is developed for supporting dependency-aware service composition. Current work takes the initial step for tackling contextaware service-oriented computing. In the future, we first plan to refine Web service dependency in depth (e.g. definition and formalization about the properties of each service context and service dependency). Secondly, we will continue the development of the context-aware service management platform by integrating modules of conditional dependency management and temporal dependency management. In the end, we will develop applications specific to home automation area. Acknowledgement This work was carried out in the ITEA-ANSO project funded by the Finnish Funding Agency for Technology and Innovation (Tekes) and VTT Technical Research Centre of Finland. References [1] SOAP, "SOAP Version 1.2 Part 1,2,3: Messaging Framework," [2] WSDL, "WSDL: Web Services Description Language (WSDL) 1.1," July, 2007 [3] UDDI, "UDDI Version 3.0.2," [4] H. Cervantes and R. S. Hall, "Automatic service dependency management in OSGi," 25 July, [5] "OASIS SOA Reference Model," In Wikipedia, 25 [6] H. Kreger, "Web Service Conceptual Architecture (WSCA 1.0)," www- 3.ibm.com/software/solutions/webservices/pdf/WSC A.pdf, [7] A. Arsanjani, L.-J. Zhang, M. Ellis, A. Allam, and K.Channabasavaiah, "S3: A Service-Oriented Reference Architecture," IT Professional, vol. 9, pp , [8] WSA/W3C, "Web Services Architecture," [9] M. P. Papazoglou, " Extending the Service Oriented Architecture,." Business Integration Journal, February [10] T. Andrews and e. al., "Business Process Execution Language for Web Services (BPEL4WS),Version 1.1.," 25 July, [11] BPML, "Business process Modeling Language (BPML)." bpmi.org, [12] A.Arkin and e. al., "Web Service Choreography Interface 1.0," [13] A. Ankolekar, M. Burstein, J. Hobbs, O. Lassila, D. Martin, D. McDermott, S. McIlraith, S. Narayanan, M. Paolucci, and T. Payne, "DAML-S: Web Service Description for the Semantic Web," presented at The International Semantic Web Conference (ISWC), Sardinia, Italy, [14] D. Martin, "OWL-S: Semantic Markup for Web Services," [15] K. Arnold, B. Osullivan, R. W. Scheifler, and e. al., The Jini(TM) Specification (The Jini(TM) Technology Series) 1st edition: Addison-Wesley Pub., [16] W. K. Edwards and T. Rodden, Jini Example By Example (Paperback) 1st edition: Prentice Hall PTR,

7 [17] "OSGi Service Platform Specifications Release 4," section=2#release4, [18] R. S. Hall and H. Cervantes, "Gravity: supporting dynamically available services in client-side applications," vol. 28(5): ACM Press New York, NY, USA, 2003, pp [19] "UPNP specification," 25 [20] S. Chan, D. Conti, C. Kaler, and et.al., "Devices Profile for Web Services," profile.pdf, [21] OMG, "Unified Modeling Language Specification," [22] "Home Gateway Technical requirements," Home Gateway Initiative, 25 July, [23] OMG, "Model Driven Architecture, A Technical Perspective," OMG, [24] J. Zhou, E. Niemela, and P. Savolainen, "An integrated QoS-aware service development and management framework," proceeding of 6th Working IEEE/IFIP Conference on Software Architecture WICSA 2007, Mumbai, India, [25] "Oscar: An OSGi framework implementation," 25 [26] OSGi, "OSGi Products and Solutions," [27] Concierge,