An Operating Guideline Approach to the SOA
Interorganizational cooperation is more and more organized by the paradigm of services. The serviceoriented architecture (SOA) provides a general framework for service interaction. It describes three roles, service provider, service requester, and service broker, together with the three operations publish, find, and bind. We provide a formal method based on Petri nets to model services and their cooperation. We characterize well-behaving pairs of requester’s and provider’s services and suggest operating guidelines as a convenient and intuitive artifact to realize publish. In our approach, the find operation reduces to a matching problem between the requester’s service and the operating guideline. Binding of a requester’s and a provider’s service is therefore guaranteed to result in a well-behaving cooperating service. At this time, the approach is limited to acyclic Petri nets. A service can be viewed as an artifact which consists of an identifier (id), an interface (e.g. specified in WSDL [4]), and internal control (e.g. a work- flow). A service can typically not be executed in isolation – services are designed for being invoked by other services, or for invoking other services themselves. The service-oriented architecture (SOA)is a promising and increasingly influential software architecture. It provides a general framework for service interaction. Thereby, it describes three roles of service owners: service provider, service requester, and service broker. A service provider publishes information about his service to a repository. The service broker manages the repository and allows a service requester to find an adequate service provider. Then, the service of the provider and the service of the requester may bind and start interaction. Cooperating services may cause non-trivial communication. Thus, for a given requester’s service R, the broker’s task is to select from the repository only those provided services P that are guaranteed to interact properly with R. At least, the services R and P must not deadlock in their interaction nor send unanticipated messages. For this purpose, compatibility of the interfaces of R and P is not sufficient. The broker must select a service P by help of the information published about P . In a currently quite popular approach, the published information is a socalled public view , i.e. an abstract version P 0 of P with a communication behavior equivalent to P . In this paper we suggest an alternative: The provider does not publish information about his service P , but information about all properly interacting services R of potential requesters, instead. A compact representation of this information is called operating guideline, OGP , for P . We claim that matching a requester’s service R with an operating guideline OGP is less complex than matching R with the public view P 0 of P . If R matches OGP , we can guarantee that R and P interact properly. In this paper, we show that services have canonical operating guidelines and it is even possible to compute them. Furthermore, the operating guideline for P typically hides a lot of details about the internal control structure of P , that the owner of P might want to keep secret.
Free download research paper
CSE PROJECTS