Brochures

A Distributed Aspect Model for Composite Service

Description
A Distributed Aspect Model for Composite Service
Categories
Published
of 6
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
Transcript
  A Distributed Aspect Model for Composite Service Kumaravel Ganesan Research ScholarDept. of Computer ScienceDr. M.G.R UniversityChennai, India kumaravel@ieee.org Swarup Kumar Mohalik  Senior ResearcherIndia Science LabGeneral Motors TCIBangalore,India swarup.mohalik@gmail.com Cyril Raj Professor and HeadDept. of Computer ScienceDr. M.G.R UniversityChennai, India cyrilraj@hotmail.com Abstract Multiple componentweb services can be composedtogetherto generate a complex service. Creating and deploying suchcomposite web services has lot of practical challenges. Oneof them is the issue of non-functional service behaviorswhich cross-cut child component services. They shouldbe separated out from the core-functionality of service in-stances and need to be handled based on the functionality of the composite service and the component services. The sep-aration makes modular design and deployment easy. How-ever, due to the distributed nature of the services, compositeservice instances may not be able to access the componentservice states without infrastructure support. In this paperwe propose a novel solution which supplements the webservices infrastructure by a distributed aspect infrastructure(DAI). It provides a specification language to separately de-sign the non-functional service concerns as distributed as-pects. It also provides a runtime to automatically deployand execute the aspects, while the web service infrastructureconcerns itself with the core-functionality of the compositeservice. We have implemented a prototype of DAI runtimeusing SmartFrog and AspectWerkz.  Keywords Service oriented Architecture, Web ServiceComposition, Aspect Oriented programming. DistributedAspect Model. 1. Introduction Web services encapsulate and expose a set of functionali-ties and state information, available at a web node throughstandard interfaces (14). This interface standardization andobject oriented nature allows the services to get accessedin platform- and implementation-independentways by otherapplications.This also enables interoperabilityamongappli-cations running on distributed and heterogeneous environ-ments. Therefore, the web service platform seems to havegreat potential for integrating different business applicationsin a seamless manner (6; 7; 8).Alongwith the mushrooming growth of web services,there has been a compelling need to combine atomic (or,component) web services to construct Composite Web Ser-vices (9). Cost-effectiveness resulting from reuse and valueaddition are the major drivers for composite services. Fora simple example, consider a Stock price service which re-turns the stock price in a single currency. However, users indifferent countries would like to see the stock price in theirlocal currency. A composite service which combines Stock  price service and an Exchange Rate service with the profileofa user can servetheinternationalcustomerin a betterway.Typically a web service implementation realizes manynon-functional features along with its own core function-ality. SLA adaptation, web service policy, security, trans-action and business semantics are such non-functional fea-tures (10). More often than not, a non-functional behaviouris conjoined with other services functionalities. For exam-ple, an authentication procedure may be necessary for eachendpoint interface in a service. Because these types of non-functional features cut across many places in a service im-plementation,they are often referred to as cross-cutting con-cerns .A composite web service imposes some non-functionalfeatureson the componentservices. This non-functionalfea-tures need to be adapted in one or more services which areused to build the composite service (13). For example, the’all-or-none’ transaction semantics may require the cancel-lation service (functional feature) provided by a Toy Storeservice if an offered gift coupon could not be availed froma partner Book Store service due to failure of authentica-tion (non-functional feature) of a loyalty program. Fromthis point of view, we say that the non-functional featuresof composite services cross-cut the participating componentweb services.The requirements from composite web services can beanticipated and integrated in the component web service in-terfaces, but this solution is not scalable due to the open na-ture of web services. Also the solution has high maintenancecost as non-functional features are cross-cutting and haveto be updated across all component services if any cross-cutting concern changes. Hence, it is desirable to design thecomposite web services independently and let the compo-  nent web services adapt themselves to the demands from thecomposite service dynamically.Traditionally, Aspect Oriented Programming paradigmhas beenusedto addresstheproblemofadaptationforcross-cutting concernsin variousscenarios with a plethora of toolsand methods supporting the paradigm (1; 3). In this paper,we extend the paradigm to the distributed case and providea framework to support the modular development and de-ployment of composite web services. The proposed solutionsupplements the existing web services infrastructure by adistributed aspect infrastructure (DAI). It provides a spec-ification language to separately design the non-functionalservice concerns as distributed aspects. It also provides aruntime to automatically deploy and execute the aspects,while the web service infrastructure concerns itself with thecore-functionality of the composite service. We have imple-mented a prototypeof DAI runtime using SmartFrog (4) andAspectWerkz (15).In the context of web services, AOP has been a naturalchoice to address several problems (12; 11). AWED (5) isone dynamic aspect model which supports distributed na-ture of services. But it doesn’t support a high-level descrip-tion of join points based on system states. As a result, spec-ification of cross-cutting concerns of composite services isdifficult in this model. The state based join point model sug-gested by (16) is developed for non-distributed AOP. Alsoadvice weaving pattern has not been explored and discussedin the paper. Our model is different from the existing solu-tions in several ways: first, it introduces a new state-based join point model for distributed systems; second, the modelof the cross-cutting functionality is succinctly captured viatransition systems and third, the framework allows dynamicdeployment of the distributed aspects using an open sourceframeworkofSmartFrog.While the methodologyis applica-ble to a very general case of composite web services, in thispaper we restrict ourselves to non-hierarchicalcompositionsfor the ease of exposition.Therest of the paperis organizedas follows.In Section2,we describe composite web services in the Service OrientedArchitecture for web services and introduce the problem wewant to solve. Section3 describes the AOP paradigmandtheneed for a distributed framework to address the problem. InSection 4, we propose the solution framework and followit up with a case study in Section 5. We conclude withsummary and possible future directions in Section 6. 2. Service Oriented Architecture (SOA) The objective of Service Oriented Architecture is to pro-vide mechanisms to bridge heterogeneous platforms allow-ing data to flow across various platforms. Using this archi-tecture, software entities which provide a set of function-alities can be made available over the internet as services.These SOA based web services expose description of ser-vices in a publicly accessible registry; a service client dis-covers those services by querying the registry and binds tothe selected service dynamically. This dynamic binding ca-pability results in looser coupling between applications. Italso helps applications to efficiently adapt to a changing en-vironment. 2.1 Service A software service can be defined as a software entity whichencapsulates functionality and state that can be used byother services. It can also be described as a state transitionsystem where the state represents current configuration of the service. The transitions correspond to update operationsto these configurations. State information is usually exposedby services so that other services can access and manipulatethe exposed states. 2.2 Composite Service Independent simple services can be composed to achievemorecomplexfunctionalityas a service. This compositeser-vice can be specified by using languageslike BPEL4WS andexecuted by runtime engines such as BPEL4J. Typically, acomposite service is orchestrated in a centralized  fashionthrough a master node. This master node is responsible forcoordination of control flow and data exchange between in-dividualservices.Alternatively,onecanhavea decentralized implementation comprising multiple runtime engines. Eachruntime engine executes a part of composite service spec-ification at a remote location and communicate with otherengines directly. 2.3 Separation of Cross-cutting Concerns inComposite Services In a composite service environment, there are many non-service behaviors which crosscut across multiple compo-nent service implementations. Example of these distributedcross-cutting concerns could be Interoperability, Securityand Transaction Management, etc. In order to have a mod-ular implementation of the atomic component services, andcomposite services built using these components, the cross-cutting concerns need to be separated out from the compo-nent service implementation.Further,we need to have bettermechanisms to specify the concerns.As an example of com-posite service, we consider a travel service (See Figure 1)constituted by two component services: Train ReservationService (TRS) and Hotel Booking Service (HBS).Each component service may have its own transactionalbehavior which is generally based on notions of compos-able, atomic and non-atomic tasks. The service interface hasto exposevarious operationsto supportthis transactionalbe-havior. Based on the service interface details, for example,one can conclude that it supports either short lived atomictransactionorlongrunningbusinessactivitytransaction.Thesupport for particular transaction type also includes addingmore restriction in the service implementation like predefin-ing time duration of blocking resources or allow only rele-  Travel ServiceTrain Reservation System(TRS)Reserve()Cancel()Hotel Booking Service(HBS)ReserveRoom()ReleaseRoom() Figure 1. Example Scenario.vant user to call a compensationservice. Inanotherscenario,there is a need for adaptation of services based on the QOSrequirement of the composite service. Hence these QOS re-latedbehaviorchangesshouldbeconsideredas cross-cuttingconcerns and separated out from all the component web ser-vices.In our example, HBS may support pivot type transac-tion, which means it doesn’t support any rollback mecha-nism. TRS may be a long running service and it has its owninternal state like wait listed availability, RAC (reservationagainst cancellation) availability and confirmed availability.Based on the state of the TRS service, if ticket is not avail-able then the compensationfunctionality (releaseRoom())inHBS service should be enabled for the particular user. Simi-larly, if hotel bookingis not available then the compensationfunctionality (Cancel()) in TRS service should be enabled. 3. Aspect Oriented Program (AOP) A software entity can be considered as a combined imple-mentationofmultipleconcerns.Concernsaregoalsorobjec-tives of any given piece of code or software. Some concernsof a given software module focus on the business logic, orin other words, the core concern of the module. There couldbe several other concerns for the same module that focuseson issues such as persistence, security,logging,performancemonitoring,tracing, etc. Typically,the latter-mentionedcon-cerns, which could also be referred to as cross-cutting con-cerns, are implemented across many different modules. (System Properties)ConcernsCore Concerns (Central Functional Requirements) Cross-cutting Concerns (Nonfunctional, system-levelconstraints) Figure 2. A Software Entity.AOP (1) is an extension to (and not a replacement of)the traditional programming techniques such as procedural,structural or Object-oriented programming (OOP). It allowsthe software designer to separate the non functional con-cerns from the core functional concerns and helps to imple-ment them as a separate module. This separation of concern provides better modularity in the software system. AOP in-troduces a notion of  aspect  , an entity to specify the cross-cutting concerns.OOP or any other traditionalprogrammingtechnique can be used to develop the core function concernsas a baseline system. Implemented aspects are weaved onthe core module to producethe final executable code. A typ-ical aspect unit will have two parts as Join point  and advice .A join point specifies an execution point in the program andan advice is the set of instruction which gets executed at the join point.AspectBase Code(ObjectOriented) Figure 3. Aspect Oriented Programming.Dynamic AOP (2) allows runtime-weaving mechanism,which enables one to weave aspect code snippets into theapplicationduringruntime.ConcurrentAspect (17) providesthe possibility of weaving multiple advices in a single jointpoint. 4. Proposed Aspect Model for CompositeWeb Service The existing AOP paradigm provides a simple fixed codebased join point model. But in a composite service environ-ment, we need a notionof distributed, dynamicaspect whereadvices are weaved/unweaved at join points of componentweb services. Further, the weaving/unweaving should hap-pen when specified sequences of events occur at componentservice hosts participating in the composite web service. Wepropose a Distributed Aspect Infrastructure (DAI) which,alongwith the web service infrastructure (e.g. BPEL), pro-vides a flexible solution for design and developmentof com-posite web services and the cross-cutting concerns (See Fig-ure4 fora schematic oftherelationbetweencomponentwebservices, DAI and composite web services).Composite ServiceDistributedAspectModelWeb ServicesService HostingInfrastructure Figure 4. Components of DAI.DAI is a combination of core service composition de-scription (CSD) in BPEL and cross-cutting concern descrip-tion (CCD) in a distributed aspect model (DAM). Similar  to the web service runtime engine BPEL4J, DAI defines aruntime engine for DAM supported by local aspects and adistributed deployment framework. 4.1 Distributed Aspect Model (DAM) As mentionedbriefly above, a distributed aspect that modelsa cross-cutting concern must specify the following:1. The set of events from different component service hoststhat are necessary to infer the global states (or a part of it) relevant to the concern2. Specific sequences of the global states which determinethe dynamic join points, and3. Distributed advices to be weaved based on the dynamic join pointsAccordingly, the distributed aspect model (DAM) is de-signed as a triple AspectModel =  MonitorSpec, Behaviour-Spec, AdviceSpec  . The following Figure (Figure 5) showsthe three components of DAM. Note that the MonitorSpecand BehaviourSpec together determine a distributed joinpoint and AdviceSpec defines the distributed advice. In thefollowing, we explore each of the components of DAM inmore detail.MonitorSpecBehaviourSpecAdviceSpecMonitoring AspectsInput predicateTransition SystemOutput PredicateGuarded Advice Figure 5. Distributed Aspect Model. 4.1.1 Monitor Spec MonitorSpec of a distributed aspect is specified as a set of triples of form  event name, predicate, service name  . Eachtriple is deployed at the component service host through adynamically weaved local aspect of the host. The pointcutof these local system aspects is the execution point wherethe specified predicate changes its value. The advice part of this local aspect invokes the notification mechanism of DAIruntime to notify the BehaviourSpec. 4.1.2 BehaviourSpec BehaviourSpec is specified by a State Transition System(STS) which is the core of the proposed aspect model. TheSTS has three components:  S, T, O  , where • S is a finite set of states, used to capture the globalbehavior of various web services. • T is a set of transitions i.e. triples of form  source state,event, target state  . Here, the events are the notifiedeventsfromMonitorSpecwhichcapturethe state of com-ponent web services. • O : S → Pred is a mapping from the states of STS toa finite set of boolean predicates (Pred). These outputpredicates are hooks for AdviceSpec to control systemexecution as shown in the subsequent section. 4.1.3 AdviceSpec AdviceSpec is a variant of ”Distributed Advice”[] and isspecified as a triple  guard, point-cut, advice  , where • guard is a boolean combination of predicates from Pred, • point-cutis a pair of   service name, local-point-cut  , and • advice is a set of instructions as in a local aspect. 4.2 DAI Runtime DAI runtime has two parts: a simple non-distributed AOPsystem to monitor the local events and a distributed deploy-ment framework which supports notification and remote de-ployment of Aspects. The runtime parses the specified CCDfile and weaves local aspects in relevant nodes. Join pointof the local advice are the execution points where the in-teresting events occur. The advice of the local aspect trig-gers the notification of event on the join point match. Theruntime engine then makes the transition in the Behaviour-Spec depending upon the notified event. Finally, dependingupon the output of the current state of the behaviourSpec, itweaves the guarded advice which is again a local aspect in aparticular node. 5. Case Study Let us consider the example in Figure 1 discussed in sec-tion 2.3. Recall that the component services TRS and HBSare composed and exposed as a single composite named asTravel Service, and our goal is to separate the cross-cuttingconcern of transaction from the component services in thecontext of Travel Service. In our framework, Travel Servicewill be represented as a combination of a service compo-sition description (CSD) using BPEL and a cross-cuttingconcern description (CCD) using DAM. The BPEL part ex-presses the core service comprising both (1) TRS.Reserve()and (2) HBS.ReserveRoom() in the standard format. In thefollowing, we describe the DAM part in detail.There are four events of interest in TRS as shown inFigure 6(a) and explained in the following.1. The status of reserved ticket is changed to Wait Listed(E twl)2. The status of reserved ticket is changed to RAC (E trac)  3. The status of reserved ticket is changed to Confirmed(E tc)4. The status of reserved ticket is changed to Not Available (E tna)E_tcinitE_hnaE_hcE_tracE_twlE_tna(a)init(b) Figure 6. Event model for TRS(a) and HBS(b).Note that the event E twl may be followed by E tna,implying that a wait-listed ticket may not be confirmed.Also, there are two events in HBS as shown in Figure 6(b)and explained below.1. The status of the RoomBookingis changedto Confirmed  (E hc)2. The status of the Room Booking is changed to Not Avail-able (E hna)The MonitorSpec of the distributed aspect CCD is theset of triples { TRS, P twl, E twl  ,  TRS, P trac, E trac  ,  TRS, P tc, E tc  ,  TRS, P tna, E tna  ,  HBS, P hc, E hc  ,  HBS, P hna, E hna } . The predicate P twl become truewhen the status of reservation is changed to Wait Listed.Other predicates are similar.The BehaviourSpec of CCD, which is a state transitionsystem is shown diagrammatically in the Figure 7 . It hasa default initial state (-, -). The states depict the history of transaction state as derived from the notified event. For ex-ample, the state (S-hc, -) says that the event E hc has oc-curred in HBS implying the hotel booking is confirmed butthere is no information about ticket reservation from TRS.We are particularly interested in sequence of events whereone of train reservation or hotel booking was not available.From the transition system it is clear that this sequence of events lead to either state (S-hc, S-tna) or (S-hn, S-tc). Thestate (S-hn, S-tc) says that the events E hn and E tc have oc-curred, implying hotel booking was not available but ticketreservation was made. In this case, we want to ensure thetransaction property ”all or none” by enabling the compen-sationinterfaceinTRS.Similarly,thestate(S-hc,S-tna)saysthat the events E hc and E tna have occurred, implying ho-tel bookingis confirmedbut train reservation is not made. Inthis case, we want to enable the compensation interface inHBS.Note that the output function assigns the value True tothe predicate P hbs in the state  S-hc , S-tna  and assigns thevalue True to the predicate P trs in the state  S-hn, S-tc  . Fi-nally,theAdviceSpecisspecifiedas { P hbs, pc hbs, ad hbs  ,_, _S-hc, __, S-twlS-hn, _S-hc, S-twl_, S-tnaS-hn, S-tcS-hc, S-tna Enable Compensation Interface in TRSEnable Compensation Interface in HBS Figure 7. Global State Transition System.  P trs, pc trs, ad trs } , where pc hbs is a point-cut in HBS,and pc trs is a point-cut in TRS. The advice ad hbs (resp.ad trs) enables the compensation service CancelRoom()(resp. CancelTicket()) for this particular user. This com-pletes the specification of CCD. Our implementation of theproposed aspect model is developed using SmartFrog tooland Aspectwerkz.Here Smartfroglanguageis used to defineDAM and Aspectwerkz along with smartfrog’s deploymentengine is used to implement the DAI runtime. The runtimebehavior of DAM is shown in Figure 8.Aspect ModelTRS Event MonitorHBS Event Monitor JPTriggeredfalse;JPTriggeredfalse;System Advice:- sets the triggered valuewhen the event occursPredicateHolder Advice Component Advices - pointcut expression Figure 8. Runtime Behavior of DAM. 6. Summary and Discussion In this paper, we have proposed a solution for the separa-tion of non-functional features (cross-cutting concerns) of composite web services. The solution extends the existingweb services infrastructureto a distributed aspect infrastruc-ture(DAI). We have used SmartFrog as a distributed deploy-ment and event notification mechanism. One can use anyother mechanism which supports these functionalities. The

Succes in LIfe

Apr 3, 2018

Sangue

Apr 3, 2018
Search
Tags
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