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, ﬁnd, 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 ﬁnd 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 identiﬁer (id), an interface (e.g. speciﬁed in WSDL ), and internal control (e.g. a work- ﬂow). 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 inﬂuential 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 ﬁnd 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 sufﬁcient. 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.
Using Service Oriented Architecture and Component Based Development to Build Web Service Applications
Design of Low Power Analog Drivers Based on Slew Rate Enhancement Circuits for CMOS Low-Dropout Regulators
FREE IEEE PAPER