With the rapid development of information technologies, academia and industry are embracing Web services due to their integration capabilities [7]. Web services are being actively used for connecting business processes in business-to-business scenarios. This connection yields insight into the possibility of composing Web services into high-level business processes usually referred to as composite services. Composition primarily addresses the situation of user requests that cannot be satisfied by any available Web service, whereas composite services that combine available Web services might be used.
A Web service is an accessible application that other applications and humans can discover and invoke, and presents the following properties [1]: independent (as much as possible) from specific platforms and computing paradigms; primarily developed for interorganizational situations; and easily composable so that developing complex adapters for the needs of composition is not required. Several standards are associated with Web services like UDDI, WSDL, and SOAP. For composition requirements, a composite service is always associated with a specification that describes among others the list of component Web services that participate in the composite service, the execution order of these component Web services with respect to data and temporal dependencies, and the corrective strategies in case of exception handling.
The Web services community uses different languages for specifying Web services composition like BPEL and WSFL. The primary objective of these specification languages is to provide a high-level description of the composition process independent from any implementation details or concerns. The specification of composite services is also concerned with the semantics of information exchanged by the component Web services. The need for a common semantics is intensified when Web services, which originate from distinct providers, participate in the same composition.
Despite the widespread use of Web services, they still lack the capabilities that could propel them to the acceptance level of traditional integration middleware like Corba and DCOM. This lack is primarily due to the trigger-response pattern imposed on the interaction of Web services with the external environment of peers, users, and so on. The compliance with the trigger-response interaction pattern means that a Web service only processes the (say, SOAP over HTTP-based) requests it receives without considering its execution status before it commits to satisfying an additional request, or even questioning if this additional request would be, in the future, rewarding for its potential selection from a community of similar Web services. In addition to this interaction pattern, Web services are still considered by some as distributed objects that react upon request [2].
However, there are several situations that call for Web services self-management to satisfy the requirements of scalability, flexibility, and autonomy. By scalability requirement, we mean the capacity of a Web service to interact with a small or large community of Web services without having its expected performance either disrupted or reduced. By flexibility requirement, we mean the capacity of a Web service to adapt its behavior by selecting the appropriate operations that accommodate the situation (for example, negotiation, monitoring) in which it operates. Lastly, by autonomy requirement, we refer to the capacity of a Web service to accept demands of participation in composite services, reject such demands in case of unappealing rewards, or even propose other alternatives for its participation by recommending other peers. To reduce the current limitations of Web services, they must first assess their current capabilities and ongoing commitments, and second, their surrounding environment prior to binding to any composition. In fact, Web services must be context-aware. Context is the information that characterizes the interactions between humans, applications, and the environment [3].
By developing context-aware Web services it would be possible, for example, to consider the aspects of the environment in which the Web services are to be executed. These aspects are multiple and can be related to users (stationary, mobile), their level of expertise (expert or novice), computing resources (fixed device, handheld device), time of day (in the afternoon, in the morning), and physical locations (meeting room, cafeteria). Here, we discuss the suitability of context for Web services. This discussion revolves around three major elements: how to deploy context-aware Web services, how to contextualize Web services composition, and how to conciliate contexts of Web services.
On deploying context-aware Web services. Context-aware computing refers to the ability of a software application to detect and respond to changes in the environment. Making Web services context-aware is not straightforward; many issues must be addressed (adapted from [8]): How is context structured? How does a Web service bind to context? How are changes detected and assessed for context update purposes? What is the overload on a Web service of taking context into account?
Responses to some of these questions have led us to organize the context of a Web service along three interconnected perspectives (Figure 1). The participation perspective is about overseeing the multiple composition scenarios in which a Web service concurrently takes part. This guarantees the Web service is properly specified and ready for execution per composition scenario. The execution perspective is about looking for the computing resources on which a Web service operates, and monitoring the capabilities of these computing resources so the Web service’s requirements are constantly satisfied. It has been argued that the availability of the computing resources affect the capabilities of a Web service [6]. Finally, the preference perspective is about ensuring that user preferences (for example, execution time at 2 P.M.) are integrated into the specification of a composite service.
By developing context-aware Web services it would be possible to consider the aspects of the environment in which the Web services are to be executed.
In Figure 1, participation, execution, and preference perspectives are all interconnected. First, deployment connects participation and execution perspectives, and highlights the Web service that is executed once it accepts participating in a composition. Second, tracking connects execution and preference perspectives, and highlights the significance of monitoring the execution of a Web service so user preferences are properly handled. Finally, customization connects preference and participation perspectives and highlights the possibility of adjusting a Web service so it can accommodate various user preferences.
The integration of context into Web services composition ensures that the requirements of and constraints on these Web services are taken into account. While current composition approaches rely on different selection criteria (for example, execution cost and reliability), context supports Web services in their decision-making process when it comes to whether accepting or rejecting participation in a composition. Moreover, context permits tracing the execution of Web services during exception handling. It would be possible to know what happened and what is happening with a Web service at any time. Predicting what will happen to a Web service would also be feasible in case the past contexts (that is, what happened to a Web service) are stored. Web services can take advantage of the information that past contexts cater, so they adapt their behavior for better actions and interactions with peers and users.
On contextualizing Web services composition. It is known that the composition of Web services using current standards is only conducted at the level of message interactions, which is hardly sufficient since composition must also be conducted at the level of message semantics. Because independent bodies develop Web services, achieving semantic composition is concerned with various conflicts that arise when the same concept has different data structures, the same concept has different meanings in different use scenarios, and different concepts have the same meaning.
A contextual semantic composition of Web services is subject to the satisfaction of two conditions. The first is that Web services must agree on the meaning of the exchanged data; the second is that semantic-data conflicts must be resolved automatically using the information that context caters. Figure 2 illustrates the stages that enable reaching a contextual semantic composition of Web services. In a conventional composition (Figure 2a), WSDL is used to describe Web services’ interfaces. During Web services interaction, any data conflict of type value is resolved at the level of the receiver Web service. For example, upon reception of a value V in USD from WS1, WS2 explicitly converts V into V’ in local currency.
In a semantic composition that excludes the context of the exchanged data (Figure 2b), Web services’ interfaces are semantically described using high-level languages like OWL-S and WSDL-S. While these languages can handle data conflicts of type structure and semantics between Web services’ interfaces, they cannot handle data conflicts of type value. A value V that WS1 outputs must be explicitly converted into V’ in the body of WS2. The conversion function is tightly attached to WS2; this prevents reusing WS2 in other composition scenarios.
To achieve semantic composition that includes the context of the exchanged data (Figure 2c), context information must be provided. This context information is any metadata that explicitly describes the meaning of the data to be exchanged between Web services. When Web services’ inputs and outputs are explicitly described using metadata, they can be automatically transformed from one context to another during Web services execution. By automatically, we mean the conversion function is not embedded into the body of any Web service. This function is loosely attached to Web services and becomes, thus, an active component that intervenes in Web services composition and execution.
A possible solution to achieving a contextual semantic composition of Web services is built upon the semantic-value concept. Introduced by Sciore et al. [9], a semantic value permits facilitating interoperability among heterogeneous data sources. While a simple value is defined as an instance of a type (for example, 3 as integer), a semantic value associates a value with a context in which its interpretation happens. For example, 3(context=(currency,euro)) is a semantic value that defines 3 as a currency in euros. In Figure 2c, Web services’ interfaces are described by adding a contextual-description layer on top of the semantic-description layer of these interfaces. The contextual description sets the context for each input and output parameter. The values that Web services exchange are not only raw data, but have a semantic value as well. Based on the contextual description of the value V that WS1 supplies and based also, on the contextual description of the value V that WS2 expects, an active component (known as context mediator in [9]) automatically converts the semantic value V into the semantic value V’. The conversion functions are now embedded in the active component and thus, can be shared among all Web services.
On conciliating contexts of Web services. In addition to the data disparity that Web services composition must address, contexts associated with Web services will be different at the content (for example, names and types of arguments) and structure (for example, numbers and orders of arguments) levels. Ignoring the context heterogeneity has major side effects on the normal progress of a composition of Web services and constitutes a serious obstacle to the satisfaction of scalability, flexibility, and autonomy requirements as discussed earlier. This ignorance could be illustrated with different examples such as adopting a wrong strategy for selecting component Web services (for example, favoring execution-cost criterion over reliability criterion rather than doing the opposite), delaying the triggering of some urgent component Web services (for example, missing user needs prioritization), or poorly assessing the execution status of a Web service (for example, Web service being interrupted while being thought under execution). The provision of a concise view over the progress of a composition strengthens representing contexts using ontologies [5]. Context ontology would be a formal and agreed representation and meaning of all the arguments that populate a context structure. Figure 3 conceptualizes the approach of dealing with the heterogeneity of the contexts of Web services.
The values that Web services exchange are not only raw data, but have a semantic value as well.
In Figure 3, context is specialized into two types [5]: C-context for context of composite service and W-context for context of Web service. C-context permits monitoring the deployment progress of a composite service specification from a temporal perspective (that is, what occurred, what is occurring, and what might be occurring with the component Web services). The monitoring reason also backs the role of W-context. Because Web services participate in different compositions, they rely on the information that W-context caters on the progress of these compositions before these Web services decide on participating in a new composition. It is noted that contexts of Web services have a fine-grained content, whereas contexts of composite services have a coarse-grained content. For illustration purposes, we suggest some arguments that could populate the C-context of a composite service:
- Previous/Current/Next Web services: Indicates which component Web services of the composite service have been executed/are now under execution/will be executed.
- Starting time: Informs when the execution of the composite service has started.
- Status per Web service: Corresponds to the status of each component Web service of the composite service that is deployed (based on status argument of W-context).
Since it is unlikely that a certain provider would deliver all types of Web services and their respective contextual information [4], contexts will be heterogeneous in terms of content, granularity, and structure. To manage this heterogeneity, contexts of Web services must be conciliated at the composite-service level (Figure 3). For example, if the W-context of a Web service that is an element of a composite service has “location of execution” argument and the W-context of a second Web service of the same composite service has “site of execution” argument, these arguments are treated as the same by the composite service. To ensure the differences between contexts’ arguments are recognized, context ontology is used. “Location of execution” and “site of execution” arguments here mean the computing resource on which the performance of a Web service happens. The specification of the context ontology calls for a dedicated language such as OWL-C, or Ontology Web Language-based Context. More details on the OWL-C language are given in [5].
It is known in the research community that a Web service can be described along the following three categories (www.daml.org/services/owl-s/): profile, process model, and grounding. By putting forward OWL-C as a specification language for context, it would be appropriate to ensure that the description of context occurs along these three categories. The profile would describe the arguments and capabilities of context (What does the context require and provide?). The process model would suggest how context collects raw data from sensors and detects changes that need to be submitted to the Web service. Finally, the grounding would define the bindings (protocol, input/output messages, among others) that make context accessible to a Web service.
Here, we argued the rationale of associating context with Web services. Context has been used in conjunction with three intertwined steps. The first involved deploying Web services that assess the environment before they accept participating in compositions. The second step involved reducing the semantic heterogeneity gap between independent Web services that have all agreed to participate in a composition. Finally, the third step addressed conciliating contexts of Web services using ontologies.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment