Medicine, Science & Technology

Virtualizing Services and Resources with ProBus: The WS-Policy-Aware Service and Resource Bus

Published
of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Description
2009 IEEE International Conference on Web s Virtualizing s and Resources with ProBus: The WS-Policy-Aware and Resource Bus Ralph Mietzner, Tammo van Lessen, Alexander Wiese, Matthias Wieland, Dimka Karastoyanova,
Transcript
2009 IEEE International Conference on Web s Virtualizing s and Resources with ProBus: The WS-Policy-Aware and Resource Bus Ralph Mietzner, Tammo van Lessen, Alexander Wiese, Matthias Wieland, Dimka Karastoyanova, and Frank Leymann Institute of Architecture of Application Systems, University of Stuttgart Universitätsstraße 38, Stuttgart, Germany Abstract A fundamental principle of service oriented architectures is the decoupling of service ers and service providers to enable late binding of services at deployment time or even dynamic binding of services at runtime. This is important in enterprise settings, where different services that implement business functions in critical business processes are dynamically chosen based on availability or price. The same problem also applies to dynamic Grid environments where resources need to be dynamically chosen based on availability and other non-functional properties. The WS-Policy framework describes how policies for both providers and ers are specified to allow the selection of services based on these policies. Existing approaches, using WS-Policy, have drawbacks by placing the burden of the service selection partially on the client. In this paper we present an extended enterprise service bus that allows service clients to submit policies to which service providers need to comply with together in one message with the service invocation. We show how these policies are evaluated in the bus and how policies are defined for not only stateless services, but also stateful resources. 1. Introduction Today, enterprises are faced with numerous challenges relating to the flexibility of both operational procedures as well as the supporting IT infrastructure and applications. A frequent solution to cope with the for flexibility on an IT-level is the adoption of service oriented architectures (SOA). oriented The work published in this article was partially funded by the SUPER project under the EU 6th Framework Programme Information Society Technologies Objective (contract no. FP , http: //www.ip-super.org/). architectures allow dynamic binding of services in business processes or service orchestrations. This is possible since service ers are decoupled from concrete service providers. Decoupling service ers from concrete services allows exchanging services without modifying the service ers applications. In enterprise settings an enterprise service bus (ESB) provides a level of indirection between service providers and service ers and thus virtualizes concrete service implementations. This is done by matching the functional properties of the interface of the service provider and functional requirements of the service er. All matching services are put on a candidate list. Additionally to that it can be possible that service clients want to select a service from the candidate list based on nonfunctional properties at runtime. For that a services on the candidate list that fulfills the non-functional requirements has to be determined. The contribution of this paper is to introduce ProBus, a standards-based ESB capable of policy-based service and resource selection in the service bus. Our approach is based on the well-established WS-Policy standard [19] and is particularly suited to dynamic environments where services and resources dynamically appear and disappear and resource properties change frequently. The presented approach reduces implementation complexity for clients, as it delegates the service selection completely to the service bus. Our approach extends the WS-Policy-based selection of services to stateful resources, thus unifying both: service and resource virtualization. The remainder of this paper is structured as follows: In Section 2 we lay the necessary foundations by showing how dynamic service selection based on WS-Policy is done today and by describing how it is done in ProBus. In Section 3 we introduce a scenario to motivate dynamic resource selection in the bus. In Section 4 we then de /09 $ IEEE DOI /ICWS scribe how ProBus handles WS-Policy based resource selection. We describe the architecture and implementation of ProBus which is implemented as an extension to the open source Apache Mix ESB (Section 5) and describe how it relates to related concepts used in enterprise and Grid environments (Section 6). Section 7 finishes the paper with a conclusion and outlook. 2. Selection Using WS-Policy WS-Policy [19] is a framework and model to describe policies that are represented by requirements, capabilities and general characteristics in a Web service (WS) world. The WS-Policy specification defines the model and syntax to define such policies. A policy is a collection of alternatives that are composed out of a set of assertions. WS-PolicyAttachment [18] defines how to attach policies to arbitrary entities in a WS based system. In particular, WS-PolicyAttachment specifies how policies can be attached to elements in the WSDL [20], description of a service. Annotating services with policies allows describing non-functional properties for a service formalized in the policy. clients can select services based on functional properties (described in WSDL) and non-functional properties (described in WS- for example from a UDDI registry. To do so, a service client describes the ed non-functional properties (such as security requirements, transaction support or price) in a er policy. WS-Policy defines an intersection algorithm to compare er and provider policies. The intersection algorithm first normalizes the policies and then computes their intersection. The result of the intersection is the so-called effective policy. An effective policy is a new policy that contains all alternatives of the er and provider policies that are compatible. Two alternatives of two policies are said to be compatible if the one alternative contains the same assertions as the other alternative. If at least one alternative of a policy is compatible to any alternative in the other policy, these policies are said to be compatible. This means that in order for two policies to be compatible the effective policy that results from their intersection must contain at least one non-empty alternative. The effective policy can be seen as a contract between er and provider, such as that the invocation needs to be encrypted in a certain way. WS-Policy as a general framework only compares assertions based on QNames. Whether the attributes of the assertion or any possible child elements are the same in the er and the provider policy is explicitly left open. WS-Policy considers this to be a domain-specific problem that is to be solved by the so-called domain-specific processing [19, Section 4.5]. Iff policy fulfills requirements: User generates a stub for service invocation using WSDL+ binding. generate stub Client download (WSDL+binding, invoke (SOAP) publish Web Server: WSDL+ binding, Policy Legend = User of the service = Message exchange = Systems = Functional Components = Technical device used by the user to invoke the service Figure 1. Class 1: Manual service selection Client find (WSDL, find select Directory candidate list (WSDL + binding) invoke (SOAP) publish (WSDL+ binding, Figure 2. Class 2: Policy based dynamic service selection 2.1. Different Classes of WS-Policy based Selection In the following the different classes of dynamic service binding are described. For resources these classes are similar only that the dynamic binding is done for every usage of the resource instead of normally once for a service. Class 1: Manual service selection The straight forward way of service selection is to search manually for a service description (WSDL) that provides the functionality and to check if the service properties ( match the needs. This is shown in Fig. 1. Many users prefer that static manual service binding because it has following advantages: (i) it is easy to use, (ii) the user knows exactly which concrete service is used and (iii) no functional components on the client are needed. Class 2: Policy based dynamic service selection However autonomous dynamic service binding is needed for flexibility and scalability reasons. In currently used approaches dynamic binding and policy evaluation is done by the client applications as shown in Figure 2: The service selection process is comprised of three steps. In the first step the er sends the policy (either at design time or runtime) to the registry which then returns a list of effective policies from which the ser- 618 Client invoke (SOAP, ProBus find(wsdl, find select Directory candidate list (WSDL+ binding) invoke (SOAP) publish (WSDL+ binding, Figure 3. Class 3: ProBus based dynamic service selection vice er can choose one policy (and therefore the associated endpoint). The er then sends the actual to the endpoint that he has chosen from the list. This approach is implemented in standard service middleware, such as Apache Axis 2 [2]. It is used in enterprise contexts [4], [14] [20], as well as Grid scenarios. Using WS-Policy to define mainly security capabilities and requirements in Grids has been proposed in [7] [15] and in [13] for scientific Workflows. This has following disadvantages: Additional functional components are needed on the client side (i.e., to perform the find and select operations). Since the approach comprises the overhead of ing a list from the server, transmitting the list to the client and then selecting one of the candidates, it is typically only done once at deployment time, and then always the same service is used. Class 3: The policy aware service and resource bus The contribution of this paper is to introduce an approach for dynamic service binding that is as easy to use as manual binding (class 1) but is as powerful as the autonomous dynamic service binding (class 2). This is accomplished by the extension of an existing service bus (Apache Mix). The extended service bus ProBus is capable of providing a one-step WS-policy based service selection as shown in Figure 3. One-step means that only one message is sufficient for selecting and using a service. In case ProBus does not find a suitable service, a corresponding error is returned. ProBus has the advantage that it is very easy to use - the client always calls the same interface on the ProBus and delegates the selection completely to the bus by specifying the policy together with the invocation in one message. Therefore no additional functional components (to perform the find and select operations) are needed on the client. Listing 1 shows how a policy can be included in the header of a SOAP message 1. The element requiredpolicy contains the policy the service 1 The namespace prefixes for all examples are the following: soap refers to the SOAP namespace, wsp refers to the WS-Policy namespace, rb refers to prn refers to soap:envelope... soap:header rb:requiredpolicy wsp:policy wsp:exactlyone wsp:all prn:printer prn:maxcostperpage= $0.3 / /wsp:all /wsp:exactlyone /wsp:policy /rb:requiredpolicy /soap:header soap:body !-- Payload of the message -- /soap:body /soap:envelope Listing 1. SOAP message with policy included in the header client expects the service to follow (or expects ProBus to select a service that is compatible with it). In this class we explicitly need to tackle the domainspecific post-processing issues in the bus. Therefore we define a general way how to define these domainspecific post-processing rules. As WS-Policy is rendered as XML, we choose XPath to describe these rules. Therefor the mechanism allows to deploy rules that for example state that the maxcostperpage attribute of the er policy must be smaller than the value of the maxcostperpage attribute of the provider policy. 3. Scenario for Dynamic Resource Selection A resource represents a stateful service. In common understanding a service is invoked, such an invocation always produces the same results for the same input values. By that a service is stateless which is an important quality because it allows services to be implemented scalable by virtualizing them. In contrast in this paper we define the interaction with a resource as usage. The difference between use and invoke is that usage changes the state of a resource. That means a resource is stateful which has the implication that each time the resource is used the reaction could be different even for the same input values. So how a resource reacts and what it is capable of is dependent on its actual state. This state is described in a resource property document. That document changes frequently, which demand a very dynamic binding of resources. For every usage of a resource the binding has to be reviewed. In contrast a service has to be bound only once and can be invoked afterwards as 619 ResourcePropertyDocument: name =HP Color Laser Jet duplex = yes color = yes state = paper jam waiting queue = 5 cartridge = 50% black 76% yellow 02% magenta 43% cyan maxprintsize = A4 speed = 12 pages per s cost = 0.04 per page no print functionality ResourcePropertyDocument: name =Fax duplex = no color = no state = ok waiting queue = 0 cartridge = 13% black maxprintsize = A4 speed = 4 pages per s cost = 0.03 per page Client? ProBus (policy aware service and resoure bus) ResourcePropertyDocument: name =plotter duplex = yes color = yes state = ok waiting queue = 1 cartridge = 73% black 26% yellow 20% magenta 42% cyan maxprintsize = A0 speed = 0.2 pages per s cost = 4 per page? Policy: waiting queue 10 cartridge 05% black maxprintsize = A4 cost 0.05 per page state=ok Figure 4. Printer scenario for dynamic resource selection long as it is available. For a better understanding of that following simplified scenario is given. In a company several printers are available. A printer can be seen as a resource with a WS-Resource interface providing a resource property document as shown in Figure 4. Normally a user has to select the printer manually. For that the user checks the state and properties of each printer and selects the best fitting one to use. This has to be done for every print job again, because the state of the printer could have changed in between, e.g. from (state=ok) to (state=paper-jam). Resource selection is even dependant of the kind of document the user wants to print, e.g. if it is a black and white document or a colored document. That shows how important dynamic binding of resources is. Because of that we implemented ProBus that provides dynamic resource and service selection based on policies in a one-step interaction. Figure 4 shows how the printer scenario is supported by ProBus: The client wants to print a black and white document. To do that he describes his requirements for the printing as a policy. Then he sends the document together with the policy to ProBus. The bus then executes the find and select functionality and routes the document to a resource that provides the printing functionality and fulfills the requirements. As return value the client gets the identifier of the used resource. 4. Using ProBus for WS-Policy based Resource Selection The Web service Resource Framework (WSRF) [8] is the standard to render stateful resources as Web services. It consists of several specifications that specify different aspects of stateful resources (socalled WS-Resources). The WS-ResourceProperties specification [9] standardizes how the state is rendered for WS-Resources. Therefore it introduces a so-called resource properties document. It contains a set of resource properties in terms of XML elements. These resource properties can be accessed and manipulated via a set of standard operations such as: GetResourceProperty to retrieve a resource property; SetResourceProperties to manipulate a resource property; GetMultiple- ResourceProperties to retrieve several resource properties at once; or GetResourcePropertyDocument to retrieve the whole resource property document at once. Similar to a WS-Policy that describes nonfunctional properties of a Web service, a resource properties document describes functional and/or non-functional properties of a WS-Resource. The mechanisms described above help to select a particular service from a group of functionally equivalent services. The same mechanism can be employed to select a particular resource from a pool of resources from the same type. We therefore detail the example from Section 3 into the following: A set of resources that provide printing services can be accessed via a management Web service. These resources expose resource property documents, which contain a resource property that describes their state, the cost per page and the size of their printing queue. A client wants to print a document on these printing resources (but it does not care on which one). Since the printing should happen quickly and must be cheap only cheap printing resources with a small printing queue should be selected. The client could now query all printing resources for their price and queue size by invoking their GetResourceProperty operations. This implies that the client knows all printing resources and also is able to perform the selection logic which complicates the client development and tightly couples the client to the resources. Therefore we propose a different approach that employs make-it-happen semantics for such s. Using this approach, the client simply sends a printing that contains a header with a WS-Policy that specifies the maximum cost and queue size. The middleware (ProBus) then selects the appropriate resource based on the published resource properties document and forwards the to the resource. Therefore the client does not need to know which resources exist and is completely decoupled from them. This approach however entails several problems, which have been identified and are tackled in the next sections: 1. How does the client know which particular resource stored his data so that he can retrieve it later? In 620 more general terms: How are conversations between client and stateful resource handled if the client does not know the concrete Endpoint Reference (EPR) of the resource? (see 4.1) 2. How can a client define policies on resource properties? (see 4.2) 3. How does the bus select concrete resources based on these policies? (see 4.3) 4. How does the bus handle the dynamic appearance and disappearance of resources? (see 4.4) 5. How does the bus handle exceptions, i.e., when no suitable resources can be discovered? (see 4.5) 4.1. Handling Conversations When simply sending a policy with the the client does not know which concrete resource dealt with his. This imposes a problem in case several messages need to be exchanged in a complex conversation with this particular resource. Two possible solutions shown in Figure 5 come to mind when trying to solve this problem. EPR based solution: The bus replies to the with a message that contains the EPR of the resource. In case of a synchronous -response message exchange the bus can also attach this information to the response message of the resource. ID based solution: The client inserts a correlation token uniquely identifying a conversation in the message, e.g. using WS-Addressing [16] reference parameters. The bus then keeps track of which resource is responsible for which conversation by storing a (conversation id, EPR) map. Subsequent s with a conversation id are then forwarded to the associated resource. first Client usage subsequent usage first Client usage subsequent usage policy, EPR policy, id, id, ProBus ProBus Id EPR Resource Resources Resources Resource Resources Resources Figure 5. Two possible solutions to handle conversations with dynamically selected resources rb:resourcepropertycondition rb:type= xs:qname rb:xpath rb:propertyqname= xs:qname xs:string /rb:xpath + rb:resourcepropertycondition Listing 2. Pseudo-Schema for the resource property condition assertion type prn:printer prn:waitingqueue 10 /prn:waitingqueue
Search
Similar documents
View more...
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks