Service-Oriented Architecture (SOA) and Web services are becoming the universally accepted architectural style for development of modern information systems of enterprises. But the methods of design in SOA are not well established yet. The most of current methodologies are focused on composition of business processes from services. In this work, SOA based design is considered as design of information system where modelling of services and processes composed of services is related to modelling of entities comprising service execution context. It is demonstrated, that various forms of UML 2.0 interactions and state machines fit well for representation of SOA related concepts - services, protocols, choreography, orchestrations, and transactions. The proposed design method consists of two steps - making comprehensive specification of requirements and transforming it to design using State Coordinator pattern that enables loose coupling of stateless services into system operating on the base of information about states of entities.
Service-Oriented Architecture (SOA) and Web services [
What are features of service orientation that do not fit to familiar methodologies?
A service is an operation offered as an interface that stands alone in the model,
without encapsulating state, as entities and value objects [
The exclusive feature of service-oriented design is the separation between
behavioural objects, i.e. services, and persistent entities (information objects), in contrast
with object oriented design. A good service design has three characteristics [
In reality, the use of services is dependent on rules of business processes in hand.
These rules are often expressed in terms of states of information entities comprising
service execution context. In this work, design of information systems embracing
services of business domain is considered, and the State Coordinator pattern is
proposed for loose connection of stateless services into system that operates on the base
of information about persisted states of entities. SOA based design is considered as
design of information system where modelling of services and processes composed of
services is related with modelling of entities comprising context. This differs from
majority of proposed techniques, where emphasis is made on modelling of business
processes but information modelling is limited to definition of types of messages and
variables [
The proposed design method consists of two steps – making comprehensive
specification of requirements (Design Independent Model (DIM) [
The paper is structured as follows: in Section 2 service concepts and related work is characterized. In Section 3 the principles of requirements specification for serviceoriented design are presented and illustrated with the example. In Section 4 service design pattern is proposed. In Section 5 transformation from requirements to design is described. Finally, Section 6 makes conclusion and reasoning about future work.
Related approaches for modelling in SOA are associated with Business Process
Modelling Languages BPML [
Design of services deals with three levels of abstraction: operations, services
(groupings of operations) and business processes. Operations represent atomic
business transactions (logical units of work). Execution of an operation usually causes
one or more persistent data records to be read, written, or modified, and additional
operations may be invoked. Service corresponds to class concept. For design of
operations of the service, object (e. a. [
Business processes represent long running flows of actions and activities
performed in order to respond to business events, and to achieve business goals.
Business processes require multiple invocations of business internal services and services
rendered by external business systems. The rules of sequencing of message exchange
patterns of business-to-business collaborations across business process are termed as
process choreography. Besides choreography concept that is used for definition of
business-to-business processes, the concept of orchestration is essential for modelling
of internal business processes serving for execution of interactions that particular
process can manage. Concepts of choreography, orchestration and multiparty
business transactions are extensively used in Web services literature; the intelligible
clarification of terms may be found at EBPML Web site (e.g. [
The goal of service-oriented design is systematic construction of operations,
services, and organised sets of services. Many works are devoted to development of
business processes, composed of services; composition rules and phases [
In this work, system of services is constructed, rather than single business process, and development process is considered going from requirements to code. Specification of choreographies and orchestrations of business processes is based on UML 2.0 interactions and, specifically, interaction overview diagram that represents fruitful combination of activity and sequence diagrams whereas established methods are based on activity diagram-like representations or using activity and sequence diagrams alternately.
For execution of services, transition systems semantics and state machines
mechanisms are universally accepted (e.g. [
The proposed transformation is based on State Coordinator pattern that is
somewhat similar to combination of classical Façade and State patterns [
In this section, principles of specification of requirements relevant for intended goals to formalize service-oriented design are presented. Detailed model of requirements must define overall state and behaviour of intended information system independently of future design. Requirements definition consists of two phases: initial requirements and system requirements.
Initial requirements are described informally using Use Case diagrams and Use Case templates that are filled using terms from domain model. Every step of use case is described as user interaction with the system using pre and post conditions. To be precise, domain and use case model are constructed simultaneously: during use case analysis every time when new object types are discovered domain model is updated.
In second phase, initial requirements are further evolved. Every use case is
transformed into interface between the user and the system, capturing interactions between
(possibly external) interfaces, and every use case step is transformed to operation; use
cases are detailed using sequence diagrams, where operations are specified in OCL.
Initial use case diagram and DIM of illustrative Publication Agency are presented in
Figure 1; sequence diagrams representing interactions between user and system
during execution of single use case (Submit) is presented in Figure 2, together with
specification of operation. Two kinds of sequence diagrams are used for use cases:
interaction between two participants (Business interaction protocol that may be
represented by protocol state machine) and namely interaction protocol that may be
represented by interaction (Business transaction) state machine. Protocol state machines
are introduced in UML 2.0, but interaction state machines are not considered.
Sometimes they may coincide with port state machines [
The interactions and patterns of interactions between participants of business process represent choreographies of this process executed using services; the process of internal coordination of all interactions performed in the system of individual participant makes the orchestration. State Coordinator pattern proposed in this paper may be considered as a kind of orchestration engine.
Author
Register Submit Revise Review Approve
Reviewer
Committee Sequence diagrams like Figure 2a, representing client viewpoint, are not sufficient for comprehensive specification of requirements, because realization of use case may require usage of other services supported by the intended system, or other business systems. Both offered and required interfaces are captured in interaction sequence diagrams like Figure 2b. In Figure 3, interaction fragments represent choreography of global business process “Submission” (for illustrative purpose, suppose that Isubmit, IRevise and IReview are interfaces of different business systems, and “Revise” is automatic service). : : Author ISubmit
submit() accept_submit( )
: : ISubmit IRevise
revise() : : IRevise IReview
appoint() [Publication.Reviewer>=MinCritiques]
: IReview
:
Reviewer checkAppointments( ) resp_checkAppointments( ) b For reconciliation of DIM, all interactions are transformed to state machines where states of the system are represented by states of interfaces and entities of domain model (Fig. 4); composite state machines render compound business transactions.
WaitState
ISubmitStateMachine IReviewStateMachine [ not(Author.oclInState(Registered)) ] WaitState submit()[ Author.oclInState(Registered) ] ^Author.accept_submit()
Committee.revise()[ Publication.oclInState(Submitted) ] Reviewer.review() SubmitState Include/IRevise Committee.resp_review()
StateMachine ReviewState Author.resp_submit()
ISubmit.resp_revise()
Committee.appoint()[ publication.Reviewer->size<=MinCritiques ] Committee.appoint( publication ) RevieweCr.roemvimewitt(e)[en.aopt(ppruobvelic[aPtuiobnli.cAauttiohno.rCInrfioti-q>ueex-i>sstsiz(ae|>a==MRienvCieriwtiqeurIensfo])) ] WaitState
AppointState
ApproveState IReviseStateMachine
Include/IReview
StateMachine
ISubmit.resp_revise() tion scenarios are consolidated and converted to class diagram like the one in Figure 1 (detailed specification is not presented due to limits of space).
Transformation from design independent model to design (PIM) consists of several steps and may be done in several ways. Mapping interfaces to services results in coarse design, and mapping operation constraints to methods is in responsibility of detailed design. Here we are considering architectural design, during which elements of specification are allocated to realizing architectural elements. For service-oriented design, the State Coordinator pattern is proposed (Fig. 5). The Coordinator handles incoming messages that may be of two types: requests for some service operation and response from the service about operation execution results. In Figure 5, Coordinator’s reaction to received messages is presented graphically using sequence diagram and specified in OCL as post-conditions of Coordinator’s operations.
Checker checkPre() checkPost()
Coordinator request() response()
Actor response() exception() accept()
Constraint Entity
Service operation() ConcreteService : Actor : Coordinator : Checker
: Service request(MessageEntity)
checkPre(Operation):Boolean operation(MessageEntity) [checkPre.result=true]
response(MessageEntity) checkPost(Operation):Set(Message) response(MessageEntity) Context Coordinator::request(m:Message) post: let pr:oclMessage=Checker^checkPre(m.Operation) in pr.hasReturned() and if pr.result()=true then m.Operation.Service^m.Operation(m) else Actor^exception(m.Operation.ExceptionMessage) endif Context Coordinator::response(m:Message) post: let ps:oclMessage=Checker^checkPost(m.Operation) in ps.hasReturned() and ps.result()Æ forAll(msg|let op: Operation = msg.Operation in if msg.receiver.oclisKindOf(Interface) then let pr:oclMessage=Checker^checkPre(op) in pr.hasReturned() and if pr.result()=true then op.Service^op(op.RequestMessage) else Actor^exception(op.ExceptionMessage) endif endif if msg.receiver.oclIsKindOf(Actor) then if op.clIsKindOf(Acceptance) then Actor^acceptance(op.Request.AcceptanceMessage) else Actor^response(op.Request.ResponseMessage) endif On received request, State Coordinator handles message, unfolds the name of requested operation and calls checker to check precondition of that operation. Preconditions and post conditions are specified in Constraint base using attributes and relationships of entities from domain model. If Checker returns “false”, the rejection message is sent. If Checker returns “true”, Coordinator calls operation and service returns response about delivery or acceptance of service. Before sending response to requestor, Coordinator asks Checker to check message expressions specified in post conditions and possibly returns the set of messages that must be sent to internal or external services to fulfil the request. It may be zero, one or more messages that must be sent sequentially, in parallel or broadcast. If there are no messages to send, Coordinator resends response to the requestor (as shown in Fig.5). Otherwise, it sends messages to internal or external services as specified in message expressions, and treats received responses in the same way as before.
Message expressions mostly denote sending of message to successive interface, but they may express sequence of messages, messages sent in parallel to different targets (messages joined with “and”) or even multicast message flow with dynamic targets. Indeed, every kind of these interactions may be described in OCL. If responses must be received during operation execution it means that there is composite operation, and every received message presents different operation described with pre and post conditions. In other words, every request, acceptance or response is treated as separate operation what significantly streamline reasoning. Using message expressions in post conditions, services may be composed to the system in the recursive way as services secondarily called may have calls to other services, and so on. The implementation of Checker and Constraint may vary from direct checking operations to complex rule checking engines and repositories.
The purpose of Coordinator is the same as of other design patterns [
State Coordinator pattern is simple alternative for Business Process execution engine. Coordinator handles incoming message and passes it to services according to its actual context. Coordinator uses the assistance of Checker that checks constraints (pre-conditions and post-conditions) of operations. According to the principles of good SOA design, operations of services must be stateless. Information about states is captured by entities, and all constraints describing services subject to state changes are kept in Constraint base.
Coordinator may interact with external services or own composite services but nevertheless they are treated as stateless services. It deals with constraints and signatures of operations described by constraints that represent logic of usage of these operations in Information System, and selects concrete service to fulfil request or sends response about inability to do this. If new services are inserted or business rules are changed, constraints must be supplemented or modified.
There are many ways to proceed from requirements to design though we believe that it would be valid to use State Coordinator in SOA related design when business process execution language is not used. Resulting design may be implemented using J2EE, MS .Net or other framework with message-oriented middleware, creating operations for checking constraints. Checker also may be thought as some kind of rule checking component when rules are stored declaratively in rule base. 5
Transformation from DIM to PIM, based on State Coordination pattern, is presented in Figure 6. Transformations concerning detailed design and implementation are not considered in this design phase. Signatures and body conditions of PIM operations are obtained from body conditions of DIM query operations or post-conditions of non-query operations (except of message expressions that together with preconditions are allocated to constraints). For meaningful design, operations in DIM must have been discovered in the way ensuring right division of responsibilities, and description of post-conditions must hold all information for design of methods implementing behaviour.
The transformation from DIM to PIM is based on mapping between elements of
meta-models. This mapping is described by the set of rules that define how the
elements of the source model (DIM) are allocated to elements of the target model (PIM).
Main elements of DIM and PIM meta-models related by transformation rules are
depicted in Figure 6. These rules are specified using simple transformation language
based on OCL [
Transformations using State Coordinator pattern mainly are straightforward: Coordinator service and abstract Actor class are created in PIM (transformations DIM2Coordinator and DIM2Actor); DIM entities are transformed to PIM entities (transformation Entity2Entity); DIM interfaces are transformed to PIM services with interfaces (transformations Interface2Service and Interface2ServiceInterface); DIM operations are transformed to PIM operations. All the parameters of each DIM operation are allocated to one parameter (of type MessageEntity) of PIM operation (transformation Operation2Operation); PIM message entities (MessageEntity) (also called value objects) are created for DIM request, response, acceptance operations and operation preconditions. The parameters of the operation (object types and data types from model of problem domain) are transformed into elements (MessageElement) of message entities (transformation Operation2Messages); Classifier
0..n Interface 0..n
PIM
Element MessageEntity +i0n.p.unt +rece0i.v.enr Classifier
1 0..n
+output +elements 0..n 0..n +sender
1 0..n MessageElement
Fig. 6. Transformation from requirements model (DIM) to design (PIM)
Transformation DIM2PIM (UML, UML) {source DIM : UML :: Package; target PIM : UML :: Package; source condition DIM.InterfaceÆ notEmpty(); target condition DIM.name=PIM.name; bidirectional; mapping try Interface2Service on DIM.Interface <~> PIM.Service; try Entity2Entity on DIM.Entity <~> PIM.Entity; try DIM2Actor on DIM <~> PIM.Actor; try DIM2Coordinator on DIM <~> PIM.Coordinator;} Transformation Interface2Service(UML,UML) {source int:UML:Interface; target s:UML:Service; target condition s.name=int.name.concat(‘Service’); bidirectional; mapping try Operation2Operation on int.Operation <~> s.Operation; try Interface2ServiceInterface on int <~> s.Interface} Transformation Operation2Operation(UML,UML) {source opDIM:UML::Operation; target opPIM:UML::Operation; target condition opPIM.name=opDIM.name and opPIM.Precondition=opDIM.Precondition and opPIM.Bodycondition = opDIM.Bodycondition and opPIM.Postcondition= opDIM.Postcondition and opPIM.formalParameterÆ exists(m| m.oclIsKindOf(MessageEntity); bidirectional; mapping try Operation2Messages on opDIM <~>opPIM.MessageEntity} Transformation Operation2Messages(UML,UML) Preconditions and message parts of post conditions of DIM operations are transformed to preconditions and post conditions of PIM operations; body conditions (of post conditions) of DIM operations are transformed to body conditions (of methods) of PIM operations (this transformation (Constraint2Constraint) is not shown on the Figure 6 as soon as other details). The ultimate design of methods is deferred to the phase of detailed design; the implementation of methods sometimes may be achieved by direct transformation from OCL to program code, sometimes it must be fulfilled manually.
In presented transformation some assumptions were made that may vary in different circumstances, for example, concrete naming scheme. Also, all preconditions here have textual descriptions, and exception messages are created by concatenation of negation of precondition and standard textual phrase. In practice, requirements for message entities may be predefined in requirements phase.
The implementation of transformations from DIM to PIM as extensions of UML CASE tools may be another topic of research. There are many alternatives to choose of:
To base transformations on MOF to XML mapping (Metadata Interchange (XMl) – OMG specification of standard model transfer format), but there are difficulties raised by incompatibility of different implementations of different XMI versions by CASE tools vendors.
Other alternative is to base on MOF to Java mapping − Java™ Metadata Interface (JMI) created by Sun Microsystems. It is platform independent dynamic infrastructure for metadata creation, storage, interchange and management. But dependency on application programming interface (API) of CASE tool remains unresolved. There are many other similar mappings and repositories with analogous problems. Eclipse Modelling Framework supports several metadata management scenarios and seems the most promising solution capable to sustain compatibility for different functionalities of CASE tools. Transformations in such a case may be implemented as Eclipse plugins.
Trial implementations of transformations, concerned with this work, were made (and are under further development) as extensions to UML CASE tools Argo UML (using native API) and Magic Draw (using JMI and API). Though our objectives are to propose conceptual solution for going from requirements to design and implementation serves only as demonstration of its validity, in the future the implementation issues should be more deeply concerned focusing on Eclipse Modelling Framework. 6
Behaviour has many forms that must be modelled during requirements definition phase for subsequent service-oriented design: party interaction protocols; choreographies and orchestration of business processes, and transactions; interfaces and interface interactions; entities, operations and constraints. It is demonstrated that all of these concepts may be defined, analysed, and reconciled in Design Independent Modelling, where possibilities of UML 2.0 and OCL are employed.
The main purpose of the work was to demonstrate that comprehensive definition of requirements of Information System enables to obtain meaningful design in formal way. As result, transformation from requirements to architectural design is presented, during which elements, defined in requirement specification, are allocated to design elements following State Coordinator pattern proposed for service-oriented design of Information Systems.
Resulting design may be further subjected to detailed design of operations and transformed to implementation in WSDL and web services framework. Proposed pattern is simple alternative for development of service-oriented information systems when business process execution languages are not used.