A New Architecture Description Language for Service-Oriented Architecture Xiangyang Jia, Shi Ying, Tao Zhang, Honghua Cao, Dan Xie State Key Lab of Software Engineering, Wuhan University,Wuhan,Hubei,P.R.China
[email protected] Abstract Service Oriented Architecture (SOA) is a new form of distributed software architecture. In SOA, the coarse-grained, discoverable, loosely coupled, autonomous services are its basic constitutional units. This makes the SOA different from other architectures for its special architecture elements (services) and its dynamic and evolving structure. How to model this specific architecture and support service-oriented development is an important research field in service-oriented software engineering community. Present modeling technologies for service and SOA tend to be technology-aligned, and the works that try to model and analyze the service and SOA in a higher and more abstract level are relatively rare. This paper proposes SOADL, a new architecture description language for SOA. SOADL specifies the interfaces, behavior, Semantics and quality properties of services, provides mechanisms to model and analyze the dynamic and evolving architecture, and supports architecture-based service composition.
1. Introduction Service-oriented computing (SOC) is a new breed of internet-oriented computing paradigm, where large amounts of resources in Internet are virtualized as services. Service is a type of coarse-grained, discoverable, loosely coupled, autonomous distributed component. These unique characteristics of services make the architecture of service-oriented system quite different from that of traditional software. Compared with traditional software architecture, service-oriented architecture (SOA) embraces three distinctive characteristics: (1) the coarse-grained, discoverable, loosely coupled, autonomous services being the basic constructional elements;(2) the standard-based interaction between services; (3) dynamic and evolving software architecture: services can be found, composed and replaced in runtime, so
The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007
the structure and behavior of architecture are always changing. On the other hand, the methods of service-oriented analysis and design are also different from that of traditional OO approaches: (1) business agility: service-oriented development approaches should response to the changes of business rapidly; (2) service composition being the main job of service-oriented development: To build a service-oriented software, we always do it by assembling the existing services rather than developing the system from scratch. How to model this specific architecture and support service-oriented development is an important research field. However, current modeling technologies for service and service-oriented system (WSDL [1], OWL-S[2], WS-BPEL[3], and WS-CDL[4]) tend to be technology-aligned. And the works that try to model and analyze the service and service-oriented architecture in a higher and more abstract level is relatively rare. This paper proposes SOADL, a new architecture description language for service-oriented architecture. SOADL specifies the interfaces, behavior, Semantics, and quality properties of services, and provides mechanisms to model and analyze the dynamic and evolving architecture. SOADL can be utilized for design of service-oriented system with business agility and for architecture-based service composition in a simple way.
3. Language structure of SOADL SOADL is a new architecture description language for service-oriented architecture. It specifies the interface, behavior, semantics, and quality properties of services, and provides a simple and effective way to model and analyze the dynamic and evolving architecture. SOADL can be utilized for designing service-oriented system with business agility, and for architecture-based service composition in a simple way.
In SOADL, “services” are the first class citizens of architecture. In architecture level, services (we call them architectural service) are abstract architecture components. They are different from the services in business level (we call them business services) and the services in SOC technological level (such as web services, BPEL process services, etc. We call them application service). Architectural services reflect the requirement of business services, and are implemented by application service. Connectors in SOADL are described in an in-line way: they are expressed as the “bindings” between service ports, and have no first class elements to define their types. The in-line connector makes it simpler to carry out the service composition and architecture evolution. SOADL specifies the architecture in a hierarchical way. There are two kinds of services: atomic services and composite services. An atomic service carries out the basic business functions, and a composite services is composed by a set of sub-services. The system itself is specified as a composite service, and vice versa, the composite service is also a service-oriented system. SOADL adopts XML as meta-language, to take advantage of its well-formed structure, extendibility and powerful tools support. Because SOADL has no connector types and the system itself is also specified as service, the architecture model of SOADL consists of a set of services in various levels of granularity. In SOADL, services have their types, and may be instantiated for several times in the architecture. Every service type dwells in one XML document and have a namespace. Figure 1 illustrates the documental structural of a service-oriented architecture model, which consists of several XML documents. The system is a composite service defined in file system.xml, and composed by three service instances: service1, service2, and SystemServiceType （ system.xml） Service 1
Service 3
Service 2
Service1Type (service1.xml)
Service4Type (service4.xml)
Service2Type (service2.xml)
Service5Type (service5.xml)
Service3Type (service3.xml)
Service6Type (service6.xml)
Figure 1: The documental structure of SOADL architecture model.
The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007
??* + * Interaction Behavior * Configuration Actions Configuration Actions * xs:string * xs:string * ? + xs:string * xs:string * ? +
Figure 2: The syntax of the type definition of service. service3. The service type definitions of these instances reside in three documents: service1.xml, service2.xml, and service3.xml, where service1 and service3 are atomic services, and service2 is a composite services composed by another three service instances. Figure 2 is the pseudo-schema syntax of service type specification. The specification includes four parts: ports, behavior, subArchitecure and properties. Port is the interaction point of service. In the interaction, port plays a specific role: provider or consumer. The behavior is a sequence of actions, and tells the temporal constrains between operations in one or more ports. The subArchitecture part describes the structure of a composite service. The properties part includes a set of properties, which can be used for describing the properties of security, transaction, load balance, version, or the information related to implementation. In the following sections, we will recount them in detail.
3. Specifying the interface and behavior of service Port is the interaction point of service. In the interaction, port plays a specific role: provider or requester. The provider port offers the functionality and the requester port consumes it. Interaction may involve several operations. Operation defines the concrete message exchange actions. According to the
direction of messages, there are four message exchange patterns: in-only, out-only, in-out and out-in. InMessage, out Message and FaultMessage in an operation defines the message the port receives, sends and the fault it may generate. Every message has its type, which is defined in messageTypes part. The type of message is defined in standard XML schema format. In addition, the operations and the message types can have their Semantics annotations like that in WSDL-S. The behaviors part specifies the external behaviors of service. Behavior consists of a sequence of actions, either a basic action or a composite action. The basic actions include: initChannel(create a conversation channel), initChannelGroup(create a channel array) interaction (exchange the message), silentaction (the unobservable inner action), and inaction (do nothing). A composite action is composed by several actions according a certain control flow (sequence, choose, parallel, switch, while, or loop). The behavior tells the temporal constrains between operations in one or more ports. In this paper, we use a simple supply chain management business scenario to demonstrate features of SOADL. This business scenario is a simplified supply chain for a consumer electronics retailer. In a typical B2C model, customers may access the retailer’s Web site, review the catalog, and place orders for products. The retailer system requests fulfillment of a consumer’s order from the warehouse, which responds as to whether line items from the order can be filled. If stock for any line item falls below a minimum threshold in the warehouse, a replenishment order is sent to an external manufacturer using the B2B model. The manufacturer does not immediately fulfill replenishment orders. It will complete the order at some later time (possibly after completing a manufacturing run), and then inform the warehouse through callback. Figure 3 shows how the retailer service can be specified with SOADL. A retailer service has two ports: a retailer port to interact with custom and a warehouse port to interact with warehouse service. The retailer port is a provider port and the warehouse port is a requester port. The retailer service has two independent behaviors: “processOrder” and “getCatalog”. The behavior processOrder is specified as: gets a conversation channel “customerChannel” on retailerPort; interacts with customer through “customerChannel” to receive an order; carries out some unobservable actions; and gets a “shipGoodsChannel” and send out a shipgood request to warehouse through it. In this way, we can specify the ports and the behavior of warehouseService and manufacturerService. The system itself is a composite
...... ...... ......
Figure 3: The interface and behaviors of retailer service service, and also has its ports and behavior. For the limitation of paper space, we don’t go further to specify these services in detail.
The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007
4. Dynamic (re)configuration The subArchitecture part of SOADL describes the structure of the (sub)system of a composite service. There are three sub-parts in subArchitecture part: dependency, configuror, constrain. Dependency part declares the service types that the (sub)system may use. We can import a service types from a XML document located in local or remote machines. The configuror part specifies the topological structure of (sub)system. SOADL can describe the dynamic structure of service-oriented architecture by defining several configurations for one system. The configurations are triggered by events (either an application events raised by one service, or a system events raised by runtime environment). The configuror has one initialization part and several “onevent” parts, and each of these parts define a configuration of the system. The initialization part is the configuration when the system starts, while the onevent parts define the configurations in response to specific events. The constraint part defines a set of design constraints that determine how an architectural design is permitted to evolve over time. SOADL uses a
retailerPort ╳
retailerPort retailer: retailerService shipGoodsPort
POPort
╳
Warehouse: warehouseService shipGoodsPort
retailerPort retailerBak: retailerService shipGoodsPort
callbackPort
POPort manufacturer: manufacturerServic e callbackPort
:SCMSystemService
… ... … …
Figure 4: The example of dynamic reconfiguration in SCM System (dynamically replacing a service). constraint language based on first order predicate logic (FOPL) similar to ACME [7]. The constraint language includes the standard set of FOPL constructs (conjunction, disjunction, implication, quantification, and others), and also includes a number of special functions that refer to architecture-specific aspects of a service-oriented system .For instance, the function bound(port, port) will return true if two ports are bound with each other; the function hasport(service, port) will return true if the service has a specific port. Constraints may be attached to the sub-system in one of two ways: as an invariant or a heuristic. In the first case, the constraint is taken to be a rule that cannot be violated. In the second case, the constraint is taken to be a rule that should be observed, but may be selectively violated. The configuration in SOADL is defined through dynamic (re)configuration behavior. Dynamic configuration behavior consists of basic
The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007
(re)configuration actions or composite (re)configuration actions. There are six basic (re)configuration actions in SOADL: instance (create a new service instance), instanceGroup(create an instance array), removeInstance (remove a service instance from system), bind (bind two complementary ports together and create a conversation channel), relay (map a outside port to a sub-services’ port), unbind (detach a binding), derelay(detach a relaying ).The composite actions (sequence,switch) can be utilized for describing complex structure of architecture. We use an example of dynamical service substitution to show how to model the dynamic architecture: given that there is backup retailer service “retailerbak”, and when the “retailer” is unavailable, “retailerbak” will be put into work. When the “retailer” is recovered, it will be put into work again. Because the events “retailerUnvaliable” and “retialerRecovered” are raised by runtime environment, there is no service needed to specify the event-raising actions. This scenario is specified in figure 4, where the system has two configurations in response to the “retailer1Unavaliable” and “retailerRecovered” events. When the event “retailer1Unavaliable” occurs, the system will remove the binding and relaying that connect to retailer, and then create a bindings and a relaying that connects to retailerbak. Similarly, when the event “retailer1Recovered” occurs, the system will remove the binding and relaying that connect to retailerbak, and create the binding and the relaying that connects to retailer. The “prevent” property defines the pre-configuration of certain configuration. The “retailerRecovered” configuration can only be triggered when its pre-configuration is “retailerUnavaliable”
5. Pi-calculus semantics Pi calculus [14,15] is a kind of process algebra for describing and analyzing the concurrent and dynamic system. The service-oriented system is just such a system, so it’s natural that the pi calculus can be the formal semantics foundation of SOADL. In SOADL, a service is a runtime unit, and it can interact with other services. We describe it as an agent in pi calculus. There is some natural relationship between SOADL and pi calculus: port, message, channel, interaction in SOADL has the same concept in pi calculus; the types in SOADL correspond to the sorts in pi calculus. The behaviors part of the service will be converted to a pi process of the service agent.
5.1. Pi-calculus model of service The behavior of service consists of a sequence of actions: either basic actions (interaction, silentaction, inaction) or composite actions (sequence, choose, all, switch, loop). These actions have their pi calculus semantics as shown in table 1. Table 1: The pi calculus semantics of service behavior Action Initchannel InitchannelGr oup Interaction Silentaction Inaction Sequence Parallel Choose If Switch while loop
Pi Calculus Semantics P(channel) p(c1,c2,…cn) Receive: c(msg ) Send: c(msg ) τ 0 P1.P2.…Pn P1|P2|…|Pn P1+P2+…+Pn [c=true]P [c1=true]P1 +[c2=true]P2+… +([c1=false][c2=false] …[cn-1=false]Pn) WhileProcess= [c=true]P. WhileProcess +[c=false]0 LoopProcess=τ.P. LoopProcess +τ.0
According to table 1, the retailer service in figure 3 can be described as following pi-calculus process. To make the expression briefer, we define following abbreviations: customerChannel(cCh), retailerPort (rPort) ， shipgoodsPort (sPort), submitOrderRequest (oReq), submitOrderResponse (oResp), shipgoodsRequest (sgReq), shipgoodsResponse (sgResp), catalogRequest (cReq), catalogResponse (cResq), shipgoodsChannel (sgCh) . RetailerService( rPort , sPort , o Re q, o Re sp, sg Re q, sg Re sp, c Re q, c Re sp) = !( rPort (cCh).cCh(o Re q ).cCh < o Re sp > .τ .sgPort ( sgCh).sgCh < sg Re q > .sgCh(sg Re sp ) +rPort (cCh).cCh(c Re q).cCh < c Re sp >)
5.2. Pi-calculus model of (sub)system The (sub) system includes a set of service instances, which connect with each other by binding their ports together. A service instance is a process in pi calculus. A binding can also be described as a process. For example, a binding, which connects port r and port p and creates a session channel c, will be described as:
Binding ( r , p, c ) =!(r < c > + p < c >)
The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007
The binding process sends the channel name c to the two services it connects. The services will receive the channel names before they interact with each other. The relaying action in SOADL corresponds to the name substitution operation in pi calculus. If an inner port “i” is relayed to the outside port “o”, then, in the (sub)system process, the port name “i” and the messages it sends and receives will be renamed to that of the outside port “o”. SOADL allows defining the dynamic architecture of service-oriented system. The topology of the system will be different in every configuration. The pi calculus model of the system will be different accordingly. In the figure 4, there are four configurations. The initialization configuration can be described as (to distinguish the port names or message names in different services, we add prefix “r^” to all the names of retailer1, add “w^” to all the names of warehouse, and add “reg^” to all the names of registry ): ni1 = {r ^ rPort , r ^ sPort , r ^ o Re q, r ^ o Re sp, r ^ sg Re q, r ^ sg Re sp, r ^ c Re q, r ^ c Re sp} j n2 = {w ^ sgPort , w ^ POPort , w ^ cbPort , w ^ sg Re q, w ^ sg Re sp, w ^ PO Re q, w ^ POResq, w ^ SN , w ^ ackSN } nj3 = {m ^ POPort , m ^ cbPort , m ^ PO Re q, m ^ PO Re sp, m ^ SN , m ^ ackSN } SCMSystemService(rPort, o Re q, o Re sp, c Re q, c Re sp) = RetailerService(ni1){rPort / r ^ rPort, o Re q / r ^ o Re q
, o Re sp / r ^ o Re sp, c Re q / r ^ c Re q, c Re sp / r ^ c Re sp} | WarehouseService(nj2) | ManufacturerService(nj3) | Binding(r ^ sPort, w ^ sPort, shipGoodsCh) | Binding(w ^ POPort, m ^ POPort, POCh) | Binding (m ^ cbPort, w ^ cbPort, callbackCh)
Where, the system can be described as the parallel composition of the sub-services processes and the binding processes. The “retailerPort” of retailer1 are relayed with the outside port “retailerPort”, thus, there is a name substitution operation on retialerservice.
5.3. Pi-calculus reconfiguration
semantics
of
dynamic
The dynamic (re)configuration behavior in SOADL are able to create, or remove a service instance or a binding form system, therefore it is natural to be described as high-order processes in pi calculus. Because there are no operations that can remove a process from a system in pi calculus, we should do something on our service processes and binding processes: converting them into processes that can stop themselves.
Service' = remove.0 + Service Binding ' = remove.0 + Binding To create a new process for a system, we should do something on our (sub)system process and convert it into System’: SYSTEM ' = P1 + P2 P1 = ( Service1 ' | Service2 ' | ...| Servicem ' | Binding1 ' | Binding 2 ' | ...| Bindingn ') P2 = create( p ).( p | P1 + P2 )
Where, the process P1 consists of all the removable service processes and binding processes. The process P2 can receive a process from “create” port and put this new process into original services and binding processes. Now, the system can receive any new service and binding processes, and can also remove a service or a binding process from its process set. In SOADL, the reconfiguration actions are defined in “configuror”, which can be described as an agent in pi calculus. A configuror agent knows everything of the system and can dynamically create or remove a service instance, a binding or a delaying. In the dynamic (re)configuration “SCMSystemService” illustrated in figure 4, the configuror can be described as: Configuror( n ) = !( ξ ( event ).( [ event = init ](
create < retailer > .create < retailerbak > .create < warehouse > .create < manufacturer > .create( BshipgoodsCh ).create( BPOC h ).create( BcallbackC h ) .retailer ^ remove.create( renamedRetailer ).h1 ) + [ event = retailerUnavaliable ]( ( h1 + h3 ).BshipgoodsCh ^ remove.create( BshipgoodsChbak ) .renamedRetailer ^ remove.create( retailer ) .retailerbak ^ remove.create( renamedRetailerbak ).h2 ) + [ event = retailer Re cov ered ]( h1 .BshipgoodsC hbak ^ remove.create( BshipgoodsCh ) .retailer ^ remove.create( renamedRetailer ) .renamedRetailerbak ^ remove.create( retailerbak ).h3 ) ))
~
Where, n includes all the names of (sub)system: process names, port names, event names, “create” and “remove” port names .etc. The “relay” action that connect the retailer to outside is specified through remove the “retailer” process firstly and then create a “renamedRetailer”. Finally, a reconfigurable system can be described as the parallel composition of Configuror process and the System’ process, so that the Configuror is able to send new process to System’ or remove a process from System’: ReConfigurableSCMSystem＝Configuror|System'
The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007
6. Support for service composition SOADL, as an architecture description language, is used for modeling the service-oriented architecture in an abstract level. The services in SOADL are independent of the platform and technologies. However, SOADL can not only support the modeling and analyzing the system in an abstract level, but also support the service composition by mapping this abstract model onto the implementation technologies to support service composition. SOADL has the ability to analyze the interface compatibility and the correctness of composition, and the ability to translate abstract description of service into service composition code (e.g. BPEL code).
6. 1.
Analysis of interface compatibility
The interface compatibility in SOADL emerges in three levels: syntax, semantics and behavior. The syntax compatibility means that two ports must be consistent in their syntax structures. Two ports must fulfill following conditions if they want to be bound together: (1) complementary roles of ports; (2) complementary operations; (3) the messages passed between two ports must be consistent in its type and data structure. In SOADL, every message has its message type defined with XML schema. It is sufficient to verify this type compatibility of messages. The semantics compatibility denotes that two ports must be consistent in their informational semantics. The same type of messages or same name of operations may have different meanings in real world. SOADL allows adding Semantics annotations on operations and elements of message types. We use an approach like that in WSDL-S [16].With the help of these semantics annotations, we can reason about semantics consistency of operations or messages. The behavior compatibility denotes that the behavior of two services must be complementary if they want to interact correctly. Every service in SOADL has its behavior description. The behavior in SOADL is based on pi calculus. We can translate behavioral description of services into pi calculus process. To verify the behavior compatibility of two services, we should verify if the provider service can satisfy the requirement of the requester service on the bound ports. In pi calculus, one process weakly simulate the other one indicates that the former agent can simulate the latter’s behavior. We can covert the requester service process into its complementary process, and then verify if this complementary process can be weakly simulated by the provider service
process on their bound ports. With this method, we can analyze the behavior compatibility of two services.
6.2. Analysis of the correctness of composition SOADL provides the abilities to analyze the correctness of composition in an abstract level. We can use the analysis tools (for example, MWB tools [8]) of pi calculus to do this work. For one thing, we can check whether the system will lead to deadlock, leakage, or other unexpected behavior. For example, the “deadlock” command of MWB will verify if the system is lock-free, and the “step” command of MWB will be useful for checking the correctness of the interaction between services step by step. For the other thing, we can check whether the composed system fulfills the requirement of the composite service or not. The requirement of behavior is that defined in “behavior” part. To verify whether the composition satisfies the requirement or not, we should check whether the pi process of the sub-system can weakly simulate the pi process of that defined in “behavior” part of composite service. If it is true, then means that the composed system is what we want.
6.3. Code generation for service composition The abstract description of services in SOADL can be used for generating the codes of service composition. We have done the woks for generating the BPEL codes skeleton from service descriptions. In the scenario of centralized composition, we can translate the description of central service into BPEL process. Other services will be the partners of this BPEL process. The ports part of service description will be used for generating the interface part of WSDL code. The behavioral description in SOADL can be translated into BPEL process. Table 2 lists the code generation rules from SOADL behavior to BPEL codes. Table 2: the code generation rules from SOADL behaviors to BPEL Behaviors in SOADL Interaction Inaction Silentaction Sequence Choose,Switch While,Loop
Activities in BPEL Receive，reply，invoke Empty Any internal activities Sequence Switch While
The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007
7. Related works and discussion Our work is most closely related to two general classes of research. The first is architecture description languages, and the second is the service modeling technologies. There are a large number of ADLs aimed at various problems, such as Wright[5]，Darwin[6]，Rapide， Unicon ， ACME[7] ， xADL ， ABC/ADL[8] ， XYZ/ADL[9] , and π-ADL[10]. Many elements of SOADL come from these ADLs. For example, the in-line connector is similar to that in Darwin, but the “binding” has symmetry semantics different from the asymmetry semantics of that in Darwin to simplify the composition of service behavior. The dynamic configuration mechanism comes from Wright, but SOADL does not specify the “event” in the service behavior, and makes the specification simpler. As to the service modeling technologies, many works have been done in recent years. In paper [11], Monika Solanki presents ASDL (Abstract Service Design Language), a wide spectrum language for modeling web services. ASDL provides a notation for the design of service composition and interaction protocols at an abstract level. In paper [12], Quartel D and Dijkman R introduces ISDL(The Interaction System Design Language) modeling language to express the service-oriented design. Luciano Baresi proposes a method to model the SOA by refining business-oriented architectures into service-oriented ones [13]. The refinement is based on conceptual model of the platforms involved as architectural styles, formalized by graph transformation systems. These works all bring some inspiration to SOADL. Based on the traditional ADLs, and combined with modern service modeling technologies, SOADL is designed with specific consideration for SOA. (1) Support for service discovery and composition. SOADL supports the service composition as that discussed in section 6. On the other hand, SOADL is enriched with some elements that can support the service discovery, such as the behavior, properties, and the informational semantics of messages. The support for discovery is useful when we convert the architecture model into executable system, or when we reconfigure the system in runtime with the help of an explicit runtime architecture model. (2) Support for the specification of message-oriented interaction. For example, SOADL allows to specify the two messages within one “interaction” for the synchronous interaction of services. SOADL has an explicit “initchannel” action to simulate the late-binding characteristic of service interaction.
(3) An unified pi-calculus semantics of service behavior and dynamic reconfiguration behavior. The high-order pi calculus semantics of dynamic (re)configuration behavior can be used for analysis how system is constructed and changed. The first-order pi calculus semantics of the service behavior can be used for analysis of interface compatibility of services and the correctness of the composite system. This unified semantics makes it possible for analyzing the impact of dynamic (re)configuration behavior on the service behavior of the system.
8. Conclusion and future work SOADL is a new architecture description language for SOA. SOADL specifies the interfaces, behavior, Semantics and quality properties of services, provides mechanisms to model and analyze the dynamic and evolving architecture, and supports architecture-based service composition. This paper gives an overview of SOADL and discusses the related problems. However, the SOADL is still far from maturity, and we have a lot of works to do, such as: (1) Developing the visual modeling and analysis tools; (2) Exploring the methodology for service-oriented analysis and design based on SOADL; (3) Developing the runtime environment for the management and evolution of service-oriented architecture.
References [1] R. Chinnic, H. Haas, A. Lewis, J. J. Moreau, D. Orchard, and S. Weerawarana. Web services description language (wsdl) version 2.0 part 1: Core language, March 2006. http://www.w3.org/TR/2006/CR-wsdl20-20060327/ [2] The OWL-S Coalition. OWL-S 1.1 Release, 2004. http://www.daml.org/services/owl-s/1.0/. [3] OASIS. Business Process Execution Language for Web Services, Version 2.0, 2007. http://docs.oasis-open.org/wsbpel/2.0/ [4] Nickolas Kavantzas, David Burdett, Gregory Ritzinger, Tony Fletcher, Yves Lafon. Web Services Choreography Description Language Version 1.0, November 2005. http://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/ [5] Allen R, Douence R, Garlan D. Specifying and analyzing dynamic software architectures. In: Proceeding of the Fundamental Approaches to Software Engineering. LNCS 1382, Berlin: Springer-Verlag, 1998: 21-37. [6] Magee J, Kramer J. Dynamic structures in software architectures. ACM SIGSOFT Software Engineering Notes, New York:ACM Press, 1996,21(6):3-14. [7] D. Garlan, R. Monroe, and D. Wile. ACME: An Architecture Description Interchange Language. In Proceedings of the 7th Annual IBM Centre for Advanced Studies Conference, November 1997, 169~183
The Sixth International Conference on Grid and Cooperative Computing(GCC 2007) 0-7695-2871-6/07 $25.00 © 2007
[8]Wang XG, Feng YD, Mei H. ABC/ADL:An XML-Based software architecture description language. Journal of Computer Research and Development, CCF, China,2004,41 (9):1521-1531 (in Chinese). [9] Zhu X Y, Tang Z S. A temporal logic-based software architecture description language XYZ/ADL. Journal of Software, CCF, China, 2003, 14(4): 713--720 (in Chinese). [10]Oquendo F. π-ADL: An architecture description language based on the higher-order typed π-calculus for specifying dynamic and mobile software architectures. ACM SIGSOFT Software Engineering Notes, New York:ACM Press , 2004,29(3):1-14. [11] Monika Solanki, Antonio Cau, and Hussein Zedan. Asdl: A wide spectrum language for designing web services. In Proceedings of 15th International World Wide Web Conference WWW2006, Edinburgh, Scotland, 2006: 687-696 [12] Quartel D,Dijkman R,Sinderen M. Methodological support for service-oriented design with ISDL.In:Proc of the 2nd International Conference on Service Oriented Computing (ICSOC'04).New York: ACM Press,2004.1-10 [13] L. Baresi, R. Heckel, S. Thöne, and D. Varrò. Style-Based Modeling and Refinement of Service-Oriented Architectures - A graph transformation-based approach. Software and Systems Modeling - Springer-Verlag, 2006 ,5(2): 187-207 [14] Milner R, Parrow J, Walker D. A calculus of mobile processes. Information and Computation, 1992,100(1):1− 40. [15] Sangiorgi D. Expressing mobility in process algebras: First-Order and higher-order paradigms [Ph.D. Thesis]. Edinburgh:University of Edinburgh, 1992. [16] Rama Akkiraju, Joel Farrell, John Miller, Meenakshi Nagarajan. Web Service Semantics - WSDL-S, W3C Member Submission version 1.0, 7 November 2005. http://www.w3.org/Submission/WSDL-S/ [17] Victor B, Moller F. The mobility workbench: A tool for the pi-calculus. In proceeding of the 6th International Conference on Computer Aided Verification. Berlin: Springer-Verlag, 1994. 428-440
