An Operating Guideline Approach to the SOA-computer science


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





Related

COMMENT computer science





FREE IEEE PAPER
IEEE PROJECTS IEEE PAPERS 2018 2017 2016 EEE ECE FREE DOWNLOAD PDF COMPUTER SCIENCE NEW IEEE PROJECTS CSE IEEE MINI PROJECTS