Web services technology is emerging as the main pillar of serviceoriented architectures (SOA). This technology facilitates application integration by enabling programmatic access to applications through standard, XML-based languages and protocols. While much progress has been made toward providing basic interoperability among applications, there are still many needs and unexploited opportunities in this area. In particular, services in SOAs require richer description models than object or component interfaces. This is due to the loose coupling inherent in SOAs and therefore to the fact that services are developed independently of clients. Hence, service descriptions need to include all the information needed by clients to understand if they can interact with a service and how. We outline in this paper a novel approach developed as part of a PhD research work, based on web services protocols descriptions that allows for a high-level analysis based on operators.
There is still a lot to be done to simplify service development and interaction. In particular, an important aspect of Web services that affects interoperability is that services are looselyc-oupled, that is, are not developed only to interact with specific clients but are meant to serve the needs of many different clients, possibly developed by different teams or even different companies. Hence, developers of client applications need to be aware of all functional and non-functional aspects of a service to be able to understand if they can/need inter-operate with a service and how to develop clients that can interact correctly with the service. For this reason, service descriptions should be richer than ”just” descriptions of interfaces as in conventional middleware. Specifically, it is commonly accepted that a service description should include not only the interface, but also the business protocol supported by the service, i.e., the specification of possible message exchange sequences (conversations) that are supported by the service as well as other useful abstractions (temporal constraints, transactions, vendor policies and so on).
The PhD research work outlined in this paper aims at developing a novel solution to
simplify the web services life-cycle management by providing a framework for
modeling and analysing web services described as extended protocols. This work is part of a
larger effort materialized by the ServiceMozaic platform [
Protocols specifications describe the external behaviors of services, making them essential for developers willing to create clients that can interact correctly with services. We argue that protocols specifications can considerably simplify web services life-cycle management. For example, during web services development, protocols of clients and providers (possibly obtained from normative efforts such as RosettaNet1) can be analyzed to identify which conversations can be carried out between two services, therefore reducing potential runtime errors and suggesting possible modifications to improve the compatibility with the service. Protocol analysis and management can also provide valuable help to support change support and evolution. Indeed, it could enable the eased identification of the modifications required by clients at the protocol level when services protocols change. There are also promising applications like automated exceptions handling, compliance verification, and static or dynamic binding, all by taking advantage of the protocols descriptions. To realize such benefits, we aim at developing a conceptual framework, and the associated CASE tool environment, named ServiceMozaic, that enables to support design, development and management of web services. Our primary goal is to develop a model-driven framework within which whole, or at least, central parts of web services are generated and managed from models. The related research issues are the following.
– Protocol modeling. We built our framework upon an extended protocol model with formal semantics that allows richer services descriptions. Beside its ability to describe messages choreography constraints (i.e., the legal messages exchange sequences), the proposed model includes relevant abstractions such as temporal constraints, that enables users to better understand the external behavior of services. To avoid creating a model that would be either too simplistic, or too complex, we developed it upon an analysis of real-world e-commerce portals in order to identify the abstractions that can be indeed useful for practitioners. – Protocol analysis and management. We target three types of protocols analysis, namely compatibility, replace-ability and consistency analysis. Compatibility analysis consists in checking whether two services can interact correctly, based on their protocol definitions (i.e., whether a conversation can take place between the considered services). In turn, replace-ability analysis refers to the verification of whether two protocols can support the same set of conversations (e.g., a service can replace another one in general, or when interacting with specific clients). Finally, consistency analysis is related to supporting changes in protocols and their impact on requesters but has not been further investigated.
– Protocol algebra and protocol management operators. A distinctive feature of our
approach lies in the definition of operators to query, analyze, and transform
protocols. Such operators are the key to carry out most of the features described above.
– Protocols adapters and code generation. Theses two issues are part of the
ServiceMozaic platform but won’t be further detailed in this paper. Briefly, adapters [
Tools supporting web services development today are mainly concerned with
interoperability issues at the lower levels of the web services stack, like the mappings from
WSDL descriptions to Java/C# source code and vice-versa, making two SOAP-based
systems talk to each other. Similarly, the existing standards in the higher-level services
descriptions such as BPEL4WS, WSCI or WSCL proved to be more concerned with
implementation aspects than enabling the kind of formal analysis that we envision.
Indeed, the importance of formal analysis of web services protocols in terms of automated
support for services interoperability at the business protocol level has been discussed
in recent papers: [
Our approach, based on a protocol algebra and protocol operators is novel in the
field. Specifically, it should be more fine-grained than the approaches mentioned above
when doing compatibility and replace-ability analysis. We believe that to some extent,
the development of a protocol algebra for formal services descriptions analysis
implemented inside a larger CASE tool, based on the identification of abstractions needed by
practitioners [
Our model is based on the web services business protocol proposed in [
We have extended the model (called timed web service business protocol) to cater
for temporal abstractions in [
Reactive systems have been widely studied, notably to the benefit of software and
hardware verification. For analysis purposes, two formal frameworks are of interest. The
first one is the temporal logics theory [
– Partial compatibility (or simply, compatibility): A protocol P1 is partially compatible with another protocol P2 if there are some executions of P1 that can inter-operate with P2, i.e., if there is at least one possible conversation that can take place among two services supporting these protocols – Full compatibility: a protocol P1 is fully compatible with another protocol P2 if all the executions of P1 can inter-operate with P2, i.e., any conversation that can be generated by P1 is understood by P2. – Protocol equivalence w.r.t. replace-ability : two business protocols P1 and P2 are equivalently replaceable if they can be interchangeably used in any context and the change is transparent to clients. – Protocol subsumption w.r.t. replace-ability : a protocol P2 is subsumed by another protocol P1 w.r.t. replace-ability if P1 supports at least all the conversations that P2 supports. In this case, protocol P1 can be transparently used instead of P2 but the opposite is not necessarily true. – Protocol replace-ability with respect to a client protocol : A protocol P1 can replace another protocol P2 with respect to a client protocol Pc if P1 behaves as P2 when interacting with a specific client protocol Pc. – Protocol replace-ability with respect to an interaction role : Let PR be a business protocol. A protocol P1 can replace another protocol P2 with respect to a role PR if P1 behaves as P2 when P2 behaves as PR. This replace-ability class allows to identify executions of a protocol P2 that can be replaced by protocol P1 even when P1 and P2 are not comparable with respect to any of the previous replace-ability classes. – Partial protocol replace-ability : Partial replace-ability is when there is replaceability but only for some conversations and not others. For example, we have partial replace-ability with respect to a client protocol when protocol P1 can replace another protocol P2 in at least some of the conversations that can occur with another PC protocol. 5
After one year of work, we have proposed an extension of the web services business
protocols model proposed in [
Future work includes focusing on the third kind of protocols-based analysis: consistency analysis. We will also need to take into account multi-protocols choreography
analysis (the current work is focused on the analysis between a service provider and a requester). Finally, other useful abstractions such as transactional properties will provide another promising area of investigation.