Agile Service-Oriented Applications: Rule-based ... - CiteSeerX

Agile Service-Oriented Applications: Rule-based Foundation with Runtime Adaptability Ali Alqahtani, Hussein Zedan

Agile Service-Oriented Applications: Rule-based Foundation with Runtime Adaptability Ali Alqahtani, Hussein Zedan Software Technology Research Laboratory, De Montfort University, Leicester, UK alqahtani, zedan @dmu.ac.uk doi: 10.4156/jdcta.vol4.issue1.2

realistic services. Unfortunately, the level of agility brought through the above WS standards remain far from being enough, to satisfactory overcome today’s market volatility and stiff competitiveness. Severe limitations of such standards are being the subject of intensive research [14], and to which we endeavor contributing in this paper.

Abstract Service-oriented applications are increasingly requested to be adaptive and reliable, to face harsh market competitiveness and volatility. Towards achieving that, service developers must foster current ad-hoc and rigid available technology, e.g. WSDL, BPEL and WS-CDL, with early formal specification and validation and equip them with adaptability as steering forces. In paper puts first milestones towards such challenging foundations. More precisely, we first propose ECA-driven architectural interconnections to handle service composition logic. Then, we leverage this composition logic with aspect-oriented techniques towards coping with dynamic adaptability. As a core further step, we semantically govern this aspectual service composition modeling with a tailored rewriting logic theory. More precisely, we extend to Maude language to faithfully specify and validate this model.

More precisely, we are focusing on the following shortcomings of current WS standards. First, potential service-oriented applications such as E-Commerce, EHealth or E-Government are mainly governed by complex behavioral event-driven business rules [13, 2]. These are mainly following (event-conditions-actions) ECA-driven paradigm, they are rapidly evolving and define policies and conditions for doing business. However, neither WSDL nor BPEL allows for integrating such business rules, and are restricted to just basic stateless variables. Second, most of serviceoriented applications are by essence critical-mission and thus dependable, that is, any fault functioning leads to severe consequences if not catastrophic (e.g. E-health system mal-functioning may to death). Whereas such dependable require formal reasoning and validation and verification, current standards remain just descriptive and ad-hoc relying on just XML-based technology.

Keywords Service-oriented applications, ECA-driven interactions, Aspect-oriented mechanisms, Runtime adaptability, rewrite logic.

The approach we are proposing, for coping with dynamic adaptability in a rigorous setting while developing service-oriented applications, can be highlighted in the followings. The approach is stepwise and inherently based on the following early phases:

1. Introduction Service technology allows developing looselycoupled networked business processes, which cross organizations boundary. With its service-oriented architecture and enabling Web-Services, this technology is increasingly gaining maturity and worldwide acceptance. Web-Services, as encapsulated hidden components, are mainly characterized by their observed interfaces. These describe operations to be exchanged through messages with input / output parameters. Such Web-Services (interfaces) can then be published using the XML-based standard UDDI; they can be described using WSDL and more importantly, they can be composed using the BPEL or CDL standards [1]. With its loosely-coupling and distribution, service technology has particularly promised to bring more adaptability and flexibility, while cooperate cross-organizational

ECA-driven Service Composition: As motivated, we aim leveraging service composition with behavioral features. To do so, we govern any composition through event-driven business rules, written in the (Event-Conditions-Actions) ECA paradigm [13]. More precisely, the composition is achieved at the business activity-level and conceived as ECAdriven architectural (service) interactions (or connectors) [18, 11], with roles reflecting service interfaces. Aspectual ECA-driven service composition: Towards facilitating dynamic ECA-driven service composition, we then endow the proposed architectural service interactions with aspect oriented (AO) mechanisms [9]. Indeed AO concepts

16

International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010 given the informal requirements of any crossorganizational service-oriented alliances, such as the main objectives and goals, the general processes and their composing business activities as well as any intentional business rules governing such envisioned alliances.

allow factoring out cross-cutting concerns (e.g. persistence, security, etc.) as aspects, and in our case behavioral service interactions. Aspects are encapsulated units ready to be ”woven” into specific positions called joinpoints using different combinations called pointcuts. To aim is to dynamically intercept events triggering such behavioral service composition, pass them to the interaction-level, perform the inherent ECA-driven rule and then dynamically and non-intrusively weave the results on the running service components. Compliant aspectual Maude foundation and validation: This crucial phase consists in equipping this ECA-driven dynamic service composition conceptual model with a more formal operational semantics. Moreover, besides the soundness we want also inherent formal validation and verification. For that purpose, we are been investigating the suitability of rewriting logic [12] and its supporting Maude language [5]. We propose thus to enrich this language so that it can faithfully formalize this conceptual model. In particular, aspect-oriented mechanisms and explicit ECAdriven interaction level are brought to Maude.

Figure 1: The approach milestones for adaptive rule-centric SO-BPs The architectural conceptualization we are suggesting is event-driven and thus inherent to the nature of the service-oriented paradigm. It aims considering each business activity, analyze it’s governing intentional rules and required entities as service interfaces. We then propose to refine the corresponding informal rules into operational rules by adopting the common behavioral Events-ConditionsActions (ECA-) pattern [20]. These ECA-driven rules are captured as architectural service interactions, where the service interfaces represent all required business entities to express such rules for a given business activity. As depicted in the Figure, the service components themselves as black-boxes as usual.

The remaining sections are structured as follows. In the next section, the event-driven architectural service interactions model is discussed and illustrated. Then, we detail how to endow this ECA-driven architectural service composition is endowed aspect-oriented mechanisms, towards dynamic and behavioral service composition. The fourth section is devoted, on one hand, to over viewing the Maude language and its reflection. On the other hand, we leverage it to cope with service components and interfaces. In the fifth section, based on this extension, we demonstrate how the externalized ECA-driven architectural service interactions can specify and rapid-prototyped using the leveraged Maude. In the sixth section, we address dynamic adaptability of such ECA-driven service interactions. In the eight section, we survey some related work about bring rules and AO concepts to Web-Services. We conclude by some remarks and outline of further work.

The different clauses we proposing for any ECAdriven architectural service composition are as follows. First, we need the participating service interfaces (instances) providing and requiring any knowledge (e.g. events, messages, attributes and properties) from service components. Second, we need the rule(s) governing such explicit service interaction or composition. They consist of: (1) the event(s) triggering any service interaction; (2) the constraints to hold at such service interaction and finally (3) the actions to perform as effects of the service interaction. We note that besides the information from different service partners, further specific extra-properties (e.g. attributes, invariants) can be defined and involved directly at the interaction-level, which itself can be modeled as third-party rule-centric service [16].

2. On ECA-driven Architectural Service Composition As summarized in Figure 1, the motivated phases of the approach we are proposing starts with the descriptive modeling of different ECA-driven rules governing any service composition. In this conceptualization, the service interfaces are plying the roles we require from the composition. The service composition itself is expressed as ECA-driven architectural connectors. We thus assume that, we are

Example 2.1 To stay competitive, banking services are offering different incisive packages for their customers. These packages range from basic agreed-on

17

Agile Service-Oriented Applications: Rule-based Foundation with Runtime Adaptability Ali Alqahtani, Hussein Zedan We then propose to perform associated service interactions following then ECA-driven behavior at the interaction-level. Finally, the resulting emerging service actions / messages and states are to be dynamically woven on respective service components. With the aim to facilitate any subsequent operational foundation, we have thus abstracted these ideas as given in Figure 1. These five steps can be highlighted as follows.

service contracts (e.g. different formulas for withdrawal / transfer moneys) to sophisticated complex offers (i.e. staged housing loans, mortgages, etc.) depending on customers profiles (e.g. assets, trust, experiences, etc). So, even for a basic service withdrawal it is not acceptable to hide its logic inside service entities such as customer or account services. A withdrawal service must instead be regarded as a service agreement or composition between the customer and his/her account(s) services. This directly leads to more transparent and flexible tailored withdrawal service. As illustration, we propose two exogenous withdrawal service compositions. The first basic one consists simply in externalizing the withdrawal constraint (i.e. balance > amount) from the account service. In this manner, it can be adapted as the customer service wishes. We may speak then of withdrawal service composition with credits (i.e. Crd-withd.), where a specific credit is given to the customer service.

1. Events interception and properties extraction: The first step towards aspect-oriented leveraging of the proposed ECA-driven architectural service interaction model, consists in intercepting any triggering events / messages as well as required properties, from respective service interfaces, and propagates them 1 to the composition level. 2.

ECA-Interaction service Crd-Withdraw service participants Acnt: Account; Cust: Customer properties credit : Money invariants Cust.own(Acnt) = True service interaction behavior : VIP at-trigger Cust.withdraw(M) under Acnt.bal() + credit ≥ M) acting Acnt.Debit(M) end Crd-Withdraw

Features propagation towards service interactions: As we just emphasized, we have to propagate required service interfaces and their instances to the ECA-driven service interaction level.

3. Execution of the right service interaction rules: In terms of aspect-oriented mechanisms, the right service composition rules are to be performed as cross-cutting ECA-driven advices. 4. Interception of resulting interactions behavior: This step consists in intercepting the resulting advices using the service interfaces. 5. Dynamic weaving on running service components: This final step concerns the weaving and execution of the corresponding actions on the service components. This weaving should be non-intrusive on running service components.

We should note that due to their simplicity all required service interfaces from customer /account services are skipped here. For instance, for the standard withdrawal service composition (resp. credit one), the customer service should provide the withdraw event (and the credit amount), whereas the account service should offer the balance (shortened as bal) and the Debit operation.

In the subsequent sections, we detail how to effectively automate this descriptive aspect-oriented ECA-driven service composition model, using a tailored extension to the Maude language. In this sense, the fourth section details how to leverage Maude for addressing service components and inherent service interfaces, both at the type and instance levels. In the fifth section, on the basis on this Maude serviceoriented extension, we propose a mapping for the discussed conceptual ECA-driven service interactions. Finally, we forward the Maude-based mechanization of the above abstract aspect-oriented behavioral service composition for dynamic adaptability.

3. Leveraging ECA-driven service interactions with aspects Given such event-driven ECA-centric architectural service interactions, we assume at the instance level that some service partners (as service instances) are participating in such service interactions. For instance, we may have the customer service instance Cs1 under standard withdrawal composition with the account service instance Ac1. Whereas Cs2 is under CRDwithdrawal service interaction with account service Ac2. For such service interaction instances and only for them 1, we propose to intercept their triggering events as well as any required properties from different involved service components.

4. Leveraging Maude to Architectural service components

1

We intercept only events needed for existing service interactions.

18

International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010 Towards a compliant Maude-based formal foundation with rapid-prototyping abilities of the above conceptual approach, this section presents how to leverage Maude to the service paradigm. Before that, this section first overviews the main concepts of the Maude language, using a simplified accounts (objectoriented) specification. We then present how to conceive service components and service interfaces in Maude.

fmod Configuration is protecting ID **** provides OId, CId and AId . sorts Configuration Object Msg . subsorts OId < Value , Attribute < Attributes . subsorts Object Msg < Configuration . op _:_ : AId Value → Attribute . op _,_: Attribute Attributes → Attributes op 〈 _: _|_ 〉 : OId CId Attributes → Object. op _ _: Configuration Configuration → Configuration . endfm.

Recalling that, we opted for a Maude-based declarative implementation, due to the following potential benefits. First, rewriting logic (RL) is a unified framework for true-concurrent systems, promoting thus distribution in modern softwareintensive systems. Second, Maude is highly efficient allowing millions of rewritings per-second. Third, with its intrinsic reflection capabilities [5], Maude promotes separation and explicit controlling of rules execution using strategies. Last but not least, for certification purpose, Maude is endowed with an LTL-based built-in model-checker [5].

Example 4.1 A rigid holistic object-oriented based specification of the simplified banking example takes the form: omod ACCNT is protecting REAL class Acnt | bal : NNReal . msgs deposit withdraw: OId NNReal → Msg . msg transf( , , ) : NNReal OId OId → Msg . vars A B : OId , M N N’: NNReal . ********* The Account behaviour. rl[debit] withdraw(A,M) hA : Acnt|Bal : Ni ⇒ hA : Acnt|Bal : N −Mi if N ≥ M . rl[credit] deposit(A,M) hA : Acnt|Bal : Ni ⇒ hA : Acnt|Bal : N +Mi. rl[trsf] transf(M,A,B) hA : Acnt|Bal : NihB

4.1 Rewriting logic and Maude overview Rewriting Logic [12] represents a unified model of concurrency. It interprets rewrite rules as a change through a categorical foundation. It further unifies the object paradigm with concurrency. Rewriting logic goes along with a very rich and efficient object-oriented programming / specification language called Maude [5].

: Acnt|Bal : N′i⇒ hA : Acnt|Bal : N −MihB

: Accnt|Bal : N′ +Mi if N ≥ M . endom

In Maude, object states are conceived as tuples of the form 〈𝐼𝐼𝐼𝐼: C | 𝑎𝑎𝑎𝑎1 :𝑣𝑣1 , · · · , 𝑎𝑎𝑎𝑎𝑘𝑘 : 𝑣𝑣𝑘𝑘 〉 ; where Id stands for the object identity, C for its class while 𝑎𝑎𝑎𝑎𝑎𝑎1 , ..., 𝑎𝑎𝑎𝑎𝑎𝑎𝑘𝑘 denote attribute names with respective current values 𝑣𝑣𝑣𝑣𝑣𝑣1 , ..., 𝑣𝑣𝑣𝑣𝑣𝑣𝑘𝑘 . Messages can be concurrently sent / receive to such object states. Both object and message instances flow together in the so-called configuration, as multiset governed by the union operator denoted by’_ _ ’. The precise definition of this configuration in Maude itself takes the form.

The withdrawal rule, for instance, says that when an account state receives a withdrawal message, withdraw (A, M), the next state results in decreasing the balance with the corresponding amount of money, and this under the condition that the current balance suffices. Assuming we have the following configuration AcCfCp composed of three accounts (A1, A2, A3), two debits, two credits and one transfer.

The changes effect of messages on targeted object states is modelled using rewrite rules. The effect of such rules result generally in (attributes) state changes of some participating objects, creation / deletion of some objects, absorption of involved messages and emerging of some new messages.

(omod ACNT-CONF is ex ACCNT ops A1 A2 A3 → Oid . op AcCfCp → Configuration . eq AcCfCp = < A1 : Accnt|Bal : 500 >< A2 : Accnt|Bal : 100 > debit (A1, 200)credit(A2, 50)credit(A1, 300) debit (A2, 300) < A3 : Accnt|Bal : 300(transf(200, A1,A3) . endom)

19

Agile Service-Oriented Applications: Rule-based Foundation with Runtime Adaptability Ali Alqahtani, Hussein Zedan The concurrent execution of these rules on this configuration results in:

Whereas 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑖𝑖 are the observed service properties. Moreover, we endow that service component state with an axiom to split / recombine it at need. Such split / recombine axiom can be summarized as: 〈𝐼𝐼𝐼𝐼| 𝑝𝑝𝑝𝑝𝑝𝑝1 , with 𝑝𝑝𝑝𝑝𝑝𝑝𝑖𝑖 𝑝𝑝𝑝𝑝𝑝𝑝2 〉 = 〈𝐼𝐼𝐼𝐼| 𝑝𝑝𝑝𝑝𝑝𝑝1 〉 〈𝐼𝐼𝐼𝐼| 𝑝𝑝𝑝𝑝𝑝𝑝2 〉 abbreviation pairs of ’attribute: value’.

Maude> rew in ACNT-CONF: AcCfCp . ResultObject :< A1: Accnt|Bal : 400 >< A2 : Accnt|Bal : 150 > < A3: Accnt|Bal : 500 > debit(A2, 300)

Imported / exported service messages and events: We further allow service messages to be observed. We thus distinguish between local service messages (to that service component) and observed ones to participate in external service interactions. Moreover, we distinguish events as triggering messages. they are messages appearing only at the left-hand side of a given rule.

4.1.1 Reflection in Maude Rewriting logic is reflective by essence. That is, any rewrite theory can be (meta-) represented at a higher level and be reasoned on like data. RL reflection capabilities are implemented in Maude as strategies. They explicitly control the rules execution, by mainly using the (meta-) operation denoted meta-apply. A term meta-apply(t,l,n) is evaluated by converting the metaterm t to the term it represents, and then match the resulting term against all rules with label l.

Concretely, we are introducing a new Maude configuration; we call a service-configuration (i.e. CMP_GNR). We highlight here its essentials. First, two distinct sorts obs_StatSRV and loc_StatSRV are explicitly declared to separate observed service properties from hidden ones in a given service component. Similarly, we also distinguish between imported / exported observed and local messages to be exchanged between services. The split/ recombing axiom are implemented using two rules: the SplitAT and RecombAT.

Example4.2. To explicitly control the execution of the above account rules, it is wise to first perform all deposits, then transfers and finally all withdrawals. mod ACCNT-STR is inc ACNT-CONF . protecting META-LEVEL . vars debit? credit? transfer? : [Result4Tuple] . var T : Term . op Compute : Term → Term . ceq Compute(T):getTerm(debit?)getTerm(trsf?)getTe rm(credit?)

1. mod SERV GNR is 2.sorts StatSRV obs StatSRV loc StatSRV. 3.subsort obs StatSRV loc StatSRV < StatSRV · ·· 15.op < _|_ > :SRVid loc Prop→loc StatSRV . 16.op < _|_ > :SRVid obs Prop→obs StatSRV . 17.op _: ConfSRV ConfSRV → ConfSRV [ac] · ·· 21.rl [SplitAT] : < I|prs1, prs2 >⇒< I|prs1 > < I|prs2 > . 22.rl [RecombAT]: < I|prs1 > < I|prs2 >⇒< I|prs1, prs2 > .

In the appendix, we have depicted, in Figure 3, the complete specification and its execution on the above account configuration state using the Maudeworkstation environment 2.

4.2 Service components and interfaces in Maude

4.3 Service interfaces in Maude

Recalling again that Maude is not directly ready to cope with the service-oriented paradigm. To overcome this, we leveraging the Maude holistic configuration, towards a more service-based configuration with the following features:

Service interface states are of the form [IntfName|Interface-conf.]. The service interface name IntfName represents a specific service interface instantiation. The service interface state interface-conf, contains all required observed events, messages and attributes of an given exposed service. As given below, besides the Maude specification of that service interface structure, we are further anticipating how we should intercept events and properties while composing services using their interfaces. The aim is to specify, using Maude, the first step from the five-steps we previously detailed. In this sense, the interception rule intercept extracts from the service component state

Scoped service state with split / recombine: To allow extraction of observed service interfaces, we propose a service component state of the form : 〈𝐼𝐼𝐼𝐼:

C | 𝑎𝑎𝑎𝑎𝑎𝑎1 :𝑣𝑣𝑣𝑣1 , · · · , 𝑎𝑎𝑎𝑎𝑎𝑎𝑘𝑘 : 𝑣𝑣𝑣𝑣𝑘𝑘 , 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎1 :𝑣𝑣𝑣𝑣𝑣𝑣1 , · · · , 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑙𝑙 : 𝑣𝑣𝑣𝑣𝑣𝑣𝑙𝑙 〉 𝑎𝑎𝑎𝑎𝑎𝑎𝑖𝑖 stand for local features. 2

www.lcc.uma.es/ duran/MaudeWorkstation/

20

International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010 The account service interface to be involved in the withdrawal ECA-driven service interaction rule is depicted below. We thus require the debit and the balance properties from that account service component. Moreover, we have to intercept the balance property, using the rules getCfIntfbal and getCfIntfbalf.

(configuration) any part that interests the service composition. These can be events and properties of involved services. Through the rule Subsume in line 24, the supposedly intercepted events and/or properties are transformed into the special form of the service interface. The weaving rule weaveCfIntf instead enriches any service component state with the resulting actions (after the service interaction being executed).

1. mod ACNT INTF4WDR GNR is 8. op ACNT : → Intf NM . 9. op Db(_ ,_ ) : AcntId Rat → DB . 10. op bal: _: Rat → obs Prop [ctor gather (&)] . 18. rl [getCfIntfbal] : getCfIntfbal( Cfcp,AcntsL) 19. ⇒ (if belong(AC, AcntsL) 20. then < AC|bal:B > getCfIntfbal(Cfcp, AcntsL) 21. else getCfIntfbal(Cfcp, AcntsL) fi) . 22. rl [getCfIntfbalf ] : getCfIntfbalf(Cfcpf 23. getCfIntfbal(Cfcp, AcntsL)) ⇒ Cfcpf .

1. mod INTF GNR is 2. inc SRV GNR · · · 11. op [ _|_ ] : Intf NM ConfINTF → EX ConfIntf . 13. op subsume(_ ,_ ) : ConfINTF Intf NM → E ConfIntf . 14. op belong(_ ,_ ) : Iid IidL → Bool . 15. op weaveCfIntf(_ ,_ ) : EX ConfIntf ConfSRV → ConfSRV . 16. op intercept( _,_ ):ConfINTF ConfSRV → ConfSRV · · · 24. rl [Subsume]:subsum(Cfintf, INM)⇒[INM | Cfintf] . 25. rl [weaveCfIntf ]:weaveCfIntf([INM|Cfintf],Cfsrv) ⇒Cfintf Cfsrv . 26. rl [intercept]:intercept(Cfintf,Cfintf Cfsrv) ⇒Cfsrv .

Note that, in the appendix we have depicted the complete specification on both the service account component and interface using the Maude workstation environment.

5. Aspectual Rule-Centdfric Service Interactions In Maude

Example 4.3 To illustrate such Maude service components and interfaces, we take again the service account. Here the balance bal is exposed at the account interface, whereas the limit limt is hidden. Similarly, the credit and debit are observed messages to participate in service composition, whereas the changeof-limit is hidden (lines 12-15). Please note that, the debit rule now contains no conditions. The main objective of this work consists thus in externalizing any business logic at the service interaction level. So, the conditions will be later evolved and woven as aspects on the (basic) service components.

So far we leveraged Maude configuration to intrinsically support service components and interfaces. We also anticipate how intercepting and weaving required properties and messages / events from such service interfaces to allow composing services in a behavioral way. Based on that, this section presents a Maude formalization and execution of such ECAdriven service composition. First, we define a Maude-based structure to capture all elements, from any ECA-driven service interaction. These elements are composed of: (1) an ECA-driven service interaction name (e.g. WdrStd or WdrViP); (2) identifiers of the participating service interfaces (e.g. ACNT and CUST); (3) any specific information, such as properties and operations, we may require in the service composition—besides those from the service interfaces (e.g. the credit attribute). We accordingly propose the structure for any ECA-driven service interaction rule as a tuple:

1. mod ACNT SRV is · · · 10.op bal: _ : Rat → obs Prop . 11.op limt: _ : Rat → loc Prop . 12.op Crd(_ ,_ ) : AcntId Rat → CRDT . 13.op Db(_ ,_ ) : AcntId Rat → DBT . 14.op ChgL( _,_ ) : AcntId Rat → CHGL · · · 22.rl [credit] : Crd(A,M) < A|bal : B >⇒< A|bal : B +M > . 23.rl [debit] : Db(A,M) < A|bal : B >⇒< A|bal : B −M > . 24.rl [chgl] : ChgL(A,L1) < A|limt : L >⇒< A|limt : L1 > .

[CoorName || (partner ids($partner ids)_)@coord infos] (&[Partneri|partner infos])+

21

Agile Service-Oriented Applications: Rule-based Foundation with Runtime Adaptability Ali Alqahtani, Hussein Zedan The Maude-based formalization of this ECA-driven service interaction is given as follows. To exhibit a maximum of concurrency, we allow different parts of that interaction-as-tuple to be split and recombined. This split / recombine capabilities are captured using two respective rules as given in that composition specification, namely (Split_CfIntf and Recombin_CfIntf). Furthermore, to prepare service superposition of the resulting interaction on different services, we permit the extraction of any part using the rule extractCFIntf (line 27).

1. mod COORD WdrVip is · · · 6. op WdrVip : → Coord_NM . 7. op crd: _: Int → Attribute [ctor gather (&)] ··· 11. crl [WdrVip] : [WdrVip || (CS $ AC) @ crd: C] 12. & [CUST | Wdr(CS, M)] & [ACNT |< AC|bal:B >] 13. ⇒ [WdrVip || (CS $ AC) @ crd: C] 14. & [ ACNT | < AC | bal: B > Db(AC, M)] 15. & [CUST | nul] if (B + C) ≥ M .

1. mod SRV COORD is 2. inc INTF GNR · · · 15. op _$_ : PartnerIds PartnerIds → PartnerIds [ac] . 16. op _;_ : Attributes Attributes → Attributes [ac] . 17. op _ ._ : CoorOpers CoorOpers → CoorOpers [ac] . 18. op _@_ : PartnerIds Attributes → PartnerAttrs . 19. op [_ || _] : Coord_NM PartnerAttrs → ObjCoord . 20. op extractCfIntf(_ ,_ ):ConfCoord Intf NM→EX ConfIntf. 21. op _&_ : ConfCord ConfCord → ConfCord [ac] · · · 25. rl [Split_CfIntf ] : [Inm | CfI1 CfI2] 26. ⇒ [Inm | CfI1] & [Inm | CfI2] . 27. rl [Recombin_CfIntf ] : [Inm | CfI1] & [Inm | CfI2] 28. ⇒ [Inm | CfI1 CfI2] . 29. rl [extractCfIntf ] : extractCfIntf([Inm | CfI1] 30. & CfCt, Inm) ⇒ [Inm | CfI1] .

Both standard and Crdit-withdrawal ECA-driven service interaction rules as completely depicted in the appendix.

6. Dynamic (Un)Weaving Of Maude Aspectual Connectors We just demonstrate how Maude-based service components, service interfaces and ECA-driven service interactions can be specified. The last step towards the strived non-intrusive dynamic service composition adaptability consists in judiciously composing these ingredients. More precisely, towards non-intrusively intercepting events, executing and then weaving triggering ECA-driven interactions, the generic guidelines for any strategy should respect the following steps: (1) Prepare any service interface for intercepting any events and required properties; (2) Intercept only those in agreements at the service interaction instance level; (3) Propagate these intercepted service interface states to the service interaction level; (4) Perform the service interaction ECA-driven rules on these service interface states, enriched with any required interaction elements; and (5) extract all resulting service interface states and weave them on respective running service components. As mentioned already, in terms of aspect-oriented mechanisms, the ECA-driven service interaction behaviors are playing the role of (cross-cutting) advices. The reflection strategy itself represents the ointcuts; that is, how to (intercept and) weave the advices. Finally, the jointpoints represent the (hidden) rules at the service component levels, which are nonintrusively enriched with such ECA-driven composite behaviors. For instance, the debit method is externally enriched, in our case, with the balance sufficiency (plus the credit for the VIP).

Example 5.1 We report on the VIP-withdrawal service interaction rule (WrdVip). We first define the specific attribute Credit (shortly as crd) we need for such interaction. We have chosen CS for the service customer and AC for the service account as identifiers. The VIP-withdrawal customer-account service interaction rule, says that, when a withdrawal event is sent from a customer partner CS, it is intercepted via the customer service interface CUST. It then enters in contact with the balance from an agreed-on account partner AC, provided via the service interface ACNT of the account. The right-hand side says that under a specific credit crd and condition on the balance, this service coordination results in: (1) the withdrawal event being consumed (i.e. [CUST |nil]); and (2) sending of a debit message to the account (i.e.[ACNT | < AC|bal : B > Db(AC,M)]).

Example 6.1 The VIP strategy below reflects these concrete steps. First the SplitAT rule is applied to the Account and Customer service component states. Then, using the belong rule, we extract the state parts in

22

International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010 agreements. Thirdly, through the rules getCfIntfwdr and getCfIntfwdrf, we intercept all withdraw events from the customer in VIP agreement. These service interface states are adapted to the service interaction structure using Subsume. The VIP service interaction rule is then performed using (WdrVip). The rules extractCfIntf and weaveCfIntf permit finally to weave the results on the account service component.

AOP mechanisms have been firstly implemented in the AspectJ language [10]. Since then, different AOP languages have been introduced to address specific issues such as: dynamic and / or compositional weaving mechanisms, strategies for advanced pointcuts, integration of reflection and componentization. We may cite here the JasCo [6] and the Prose [15] languages which allow runtime rule-centric advices and weaving. At the requirement-level, several extensions to UML diagrams are being forwarded [8] to semi-graphically handle cross-cutting concerns. At the architecturallevel, In [3] for instance, the concepts of aspectual components and connectors have been proposed. The aim is to transparently and flexibly cope with crosscutting concerns such as distribution and security. A. Charfi et al. [4] leverages BPEL-like with more agility and modularity, by enhancing it with an extra aspectual level. The resulting new language named AO4BPEL, allows thus externalizing cross-cutting concerns such as security and data handling as advices. AO4BPEL uses XMLQuery language XPath as its pointcuts language. The approach to agile services introduced by Erradi et al. [7] also adopts aspect-orientation, and is specifically devoted to policies and QoS concerns. Another aspectdriven approach to Web-services appeared most recently in [17]. In this approach the emphasis is on the adaptability of business protocols while composing Web-services. The potentials of business rules in Web-services have also been explored. In [13], for instance, a stepwise rule-driven methodology is proposed to enhance the dynamic adaptability while composing Web-Services using BPEL-like standards. They classify in a repository different business rules toWeb Services composition, and then use to incrementally specify and compose services. Nevertheless, no formal verification / validation of the constructed composition is undertaken. Another proposal [16] conceives business rules asWebServices described using extensions to reactive RuleML [19], instead of the passive and static WSDL. The approach is automated with supporting tool called ViDre. Nonetheless, the approach does not tackle the conceptual level.

1. mod ASP_WDR_Str is · · · 11.op Compute : Term Nat → Term . 12.ceq Compute(T, N) 13.= if(N == 1) then 14.(if(SplitAT? :: Result4Tuple) 15.then Compute(getTerm(SplitAT?), N) 17.then Compute(getTerm(belong?),N) 21.then Compute(getTerm(getCfIntfwdr?),N) 25.then Compute(getTerm(getCfIntfbal?),N) 27.then Compute(getTerm(intercept?),N) 31.then Compute(getTerm(Split CfIntf?),N) 33.then Compute(getTerm(WdrVip?), N) 36.then Compute(getTerm(Recombin CfIntf?),0) 38.then Compute(getTerm(extractCfIntf?), 0) 40.then Compute(getTerm(debit?)

Figure 2 depicts concrete application of the above strategy on concrete account and customer service component configurations. Note that both standard and VIP service interaction rules come into play, and not all customer and account services are in agreements with respect to them.

8. Conclusions We proposed in the paper a stepwise approach for dynamically and behavioral composing services in a rigorous manner. We first proposed an ECA-driven architectural service composition descriptive conceptual model, and enrich it with aspect-oriented mechanisms to cope with adaptability. We then demonstrated how to leverage the rewriting-logic based Maude language to faithfully formally specify and validate this descriptive model to behavioral service composition. We first proposed Maude-based service components and interfaces, and then defined how ECA-driven service

Figure 2: Dynamic weaving of Std- and Crdwithdrawal ECA-driven service interactions

7. Related Work

23

Agile Service-Oriented Applications: Rule-based Foundation with Runtime Adaptability Ali Alqahtani, Hussein Zedan [13] B. Orri¨ens, J. Yang, and M.P. Papazoglou. A Framework for Business Rule Driven Web Service Composition. In Proc. of Conceptual Modeling for Novel Application Domains, volume 2814 of Lecture Notes in Computer Science, pages 52–64. Springer, 2003. [14] M.P. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann. Service-Oriented Computing: a Research Roadmap. Int. J. Cooperative Inf. Syst., 17(2):223–255, 2008. [15] A. Popovici, G. Alonso, and T. Gross. Just-in-time aspects: efficient dynamic weaving for Java. In 2nd international conference on Aspect-oriented software development (AOSD03), pages 100–109. ACM press, 2003. [16] F. Rosenberg and S Dustdar. Towards a Distributed Service-Oriented Business Rules System. In Proc. of the of EEE European Conference on Web services (ECOWS). IEEE Computer Society Press, 2005. [17] S. Ruy, B. Benatallah, and F. Casati. A Framework for Managing the Evolution of Business Protocols in Web Services. In In Asia-Pacific Conference on Conceptual Modelling (APCCM’07), 2007.

interaction are to modelled and executed. Finally, with Maude strategies, we addressed the non-intrusive weaving of such ECA-driven service interactions in running service components. For consolidating this promising and practical approach, we are experimenting it with more complex case-studies (e.g. an E-shopping application). Furthermore, an interesting direction is to demonstrate how (service-oriented) context-aware applications can be supported.

9. References [1] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services. Springer-Verlag, 2004. [2] M. Bajec and M. Krisper. A Methodology and Tool Support for Managing Business Rules in Organisations. Information Systems, 30(6):423–443, 2005. [3] T. Batista, C. Chavez, A. Garcia, A. Sant’Anna, U. Kulesza, A. Rashid, and F. Filho. Reflections on Architectural Connection: Seven Issues on Aspects and ADLs. In Proc. of Workshop on Early Aspects at ICSE’06, 2006. [4] A. Charfi and M. Mezini. AO4BPEL: An Aspect-oriented Extension to BPEL. World Wide Web Journal: Recent Advances on Web Services (special issue), 10:309–344, 2007. [5] M. Clavel, F. Duran, S. Eker, P. Lincoln, N. Marti-Oliet, J. Meseguer, and C.L: Talcott. All About Maude - A HighPerformance Logical Framework, How to Specify, Program and Verify Systems in Rewriting Logic. Lecture Notes in Computer Science (springer), 4350, 2007. [6] R. Douence, P. Fradet, and M. Sudholt. Composition, reuse and interaction analysis of stateful spects. In In Proc. In 4th Int. Conf. on Aspect-oriented Software Development (AOSD’04), pages 141–150. ACM Press, 2004. [7] A. Erradi and V. Maheshwari, P. Tosic. Policy-Driven Middleware for Self-adaptation of Web Services Compositions. In ACM/IFIP/USENIX 7th International Middleware Conference, volume 4290 of Lecture Notes in Computer Science, pages 62–80. Springer, 2006. [8] L. Fuentes and P. S´anchez. Towards executable aspectoriented UML models. In Proceedings of the 10th international workshop on Aspect-oriented modeling (AOM’07), pages 28–34. ACM Press, 2007. [9] G. Kiczales et al. Aspect-Oriented Programming. In Proceedings of the European Conference on ObjectOriented Programming (ECOOP). LNCS, 1997. [10] G. Kiczales et al. An Overview of AspectJ. In Proceedings of the European Conference on ObjectOriented Programming (ECOOP’01), pages 327–353. LNCS 2072, 2001. [11] N. Medvidovic and R.N. Taylor. A Classification and Comparison Framework for Software Architecture Description Languages. IEEE Transactions on Software Engineering, 26(1):70–93, 2000. [12] J. Meseguer. Conditional rewriting logic as a unified model for concurrency. Theoretical Computer Science, 96:73–155, 1992.

[18] M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, 1996. [19] S. Tabet, G. Wagner, and H. Boley. MOFRuleUML: The Abstract Syntax of RuleML as a MOF Model. In N. Lenehan, editor, Integrate 2003, 2003. [20] W.M.N. Wan-Kadir and P. Loucopoulos. Relating Evolving Business Rules to Software Design. Journal of Systems Architecture, 2003.

Figure 3: An illustration of strategies in Maude applied on the accounts

24

International Journal of Digital Content Technology and its Applications Volume 4, Number 1, February 2010

Figure 4: The Maude-based account service and its interface

Figure 5: The Maude-based ECA-driven Std- and Crdwithdraw service interactions

25