One of many definitions of Service-Oriented Architecture (SOA) says that SOA is an architectural style for building next-generation distributed information systems. If wc want to get a reliable arrd good working system, it must be well designed first. This paper deals with Scrvice-Oriented Architecture Design (SOAD), especially with modeling of scrviccs. F\rrthermore, abstraction layers of SOA are introduced and possiblc using of object oriented approach on each layer is discussed in this paper. Besides, three types of service collaboration are prcscntcd. The rnain objective of the paper is to dernonstrate how thesc typcs of collaboration can bc dcscribed in UML 2.0.
Although service-oriented architecture is not a new concept in the area of
distributcd softwarc architccturcs, it comes to the forc in rcccnt ycars thanks to
modern technical solutions, e.g. well-defined communication networks and
modeling disciplincs. SOA irnplementatiorr rarely starts on the green field. That
mcans creating a SOA solution is almost based on integrating existing systems
by decomposing thcm into scrviccs, business processes,and business rules. As
a consequence,the SOAD is composition of well-established practices such as
Object-Oricntcd Analyse and Design (OOAD), Enterprise Architecture Design
(EAD), BusinessProccss Modcling (BPM) and some other innovative elements.
Thc idcas presented in this paper are a part of a greater project, which dcals
with a methodology for SOA systemsmodcling. More precisely,the methodology
is aimcd at building models of inner-entcrprisc scrviccs and modcls of
collaborations of such services . Inputs for thc mcthodology are elements generated by
decomposition of lcgacy (nonSOA) systems. For the decomposition an
appropriate method (c.g. SOMA [
This paper describes which object-oricntcd (OO) features and techniqucs can be used in SOAD and how UML can bc used for modeling of components, assembling componcnts into scrvices,servicesand a service collaboration.
There is no 'standard' definition of SOA. In [5] SOA is presented as an approach for building distributed systems that deliver application functionality as serviccs to either end-user applications or other services.
An abstract view depicts SOA as a partially layered architecture. In this view, SOA consists of three layers: component layer, service layer and business process layer. There are two sections in parallel with these layers. They provide tools for integrating components to scrviccs and servicesto busincss processes and tools for monitoring and maintaining security and QoS of SOA applications.
Businessprocess
Businessprocess layer
collaboration of instances (objccts) of these classes,and the state of the system
is thc combined state of all the objccts in it. Collaboration among objects is
achicvcd by scnding messages.Since SOA is a new paradigm and services and
obiects are two different concepts, the question is "Could OOAD or a part of
OOAD bc used in SOAD?" The following paragraph discusseswhich OO
fcatures and techniqucs [
- Inf ormation hi,di,ng: SOA services are for scrvicc consumers black boxes with well-defined interf'aces.The goal is to separate what service does (its interface) from how it does it (its implemcntation). From the servicespoint of view, components arc also black boxes. Serviceshave only information about components intcrfaccs and route requests (for a scrvice) from a consumer to subordinate components. - Messaging is the fundamental communication model for components and scrvices in SOA. - Inheri,tance car' only be considered on a specification level of component and service modcling. - Polymorphi.sm dcscribesthe situation where the result (of a behavior) depends on the class of an objcct the behavior of which is invoked. In other words, two or more classesaccept the same message,but respond on it differcntly. The possible use of polymorphism in SOAD is similar to inheritance. - Classes and instances: Classesare templates for crcating instances (objects). From SOA point of view, this concept can be applicd to both components and scrvices. - Encapsulat'ion: A service encapsulates the state and bchavior of a number of components.
It results from the previous paragraph that except inheritance and polymorphism thc underlying OO features can bc used in SOA for modeling of components or scrvices.It should be pointed out that all OO featurcs including inheritance and polymorphism can be used for modeling thc inner structure of components. 3 Three Types of Collaboration among Services To model collaborations of services inside an enterprisc, it is useful to distinguish severai categorics of collaborations. Each category is defined by a set of communication rules (a protocol) and by the purposc of the collaboration. The categories are following: - Thc Seruice Co - operati,on describesa collaboration of services,in which one service has to use another service(s) to fulfil incoming requests. - The Seru'ice Aggregati,on is a set of rulcs which defines how to create a new service from two (or morc) existing serviccs. The new service provides combined functionality of its building services. - The Seru'ice Choreography is such collaboration of serviccsthat supports businessprocess.
The basic concept of service co-operation modeling is explaincd latter in this
paper. More about service choreography can be found in [5], [
As mcntioned bcfore, object-oriented technology and languages are great ways to design and irrrplement courponents. Unified Modeling Language (UML) is a specification language fbr object modeling. Since there exists a relationship bctween OO and SOAD (described in scction 2), UML can be used in SOAD. UML providcs extension mechanisms (stereotypes, tagged values, constraints) which cnable to model services. This chaptcr describes thc use of UML 2.0 [10] for modeling components, scrvices and scrvice collaboration. Furthermore, stercotypes for modeling SOA components and serviccs are presented. 4.L
and Services In this papcr, we use a simple example of co-opcrating services to demonstrate the use of the proposcd modeling techniques. We assumetwo collaborating services: Smath and Splus. Smath offers calculation of some mathematical operations, but in fact it docs not perform the opcration. It collaborates with other scrvices. Wc consider only one operation hcrc the sum. The service that really performs it is rcferred to as Splus. A part of this example is shown in Figure 2. The figure depicts a model of Smath. The structure of this model is explained in the following paragraph.
A servicc is modcled as a stereotype service , which is derived from the clement component of the UML. Therc are two possible abstract views of a service - an cxternal and internal one. The internal view (or "white-box" view) shows how the extcrnal behavior is realized internally. In this case, the inner structure depicts how component instances arc interconnected to providc the required functionality. An example of this view is shown in Figure 2 . This level is used only for components interconnection modeling inside a service. The other abstract vicw, the extcrnal view (or "black-box" view), is used to model serviccs in scrvice collaboration. It hides the inner structure (implementation) of services.
The mapping between the internal and external view is by means of a delegation connector . It is reprcsented by a port and an UML predefined-stereotypeof dependcncy detegate The port is shown as a small square symbol on the boundary of the symbol denoting a service.
A port delegatcs to a set of subordinate components (and vice versa ). At cxecution time, signals will bc delivered to the appropriate instance. In thc caseswhcre multiplc target instances support the handling of the same signal, the signal will be delivcred to all these subordinate instances.
Component modeling is easy, bccause UML provides a modeling element component (a subclassof Class in the UML metamodel). A component is a self contained unit that is ablc to intcract with its environment through its provided and requircd interf aces (Classif iers in the UML metamodcl). A component can be rcplacecl at run-tirne by a componcnt that offers equivalent functionality based on intcrface compatibility. Components are modeled as "black-boxes". h{trJn.p |
| lc*urrtr ,"T"*
, | <<component>I>
:ccheck |
I - service can receivc infinite number of incoming messages - incomming requests are qucued up into thc input queue - request processing and communication are processed in parallel - thc service description of each co-opcrating scrvice is known
Following two sections introducc fundamcntals of static and dynamic modeling of servicc co-opcration. Since we focus on modeling servicesinside an enterprise, we assumeserviceswith fine-grained interfaces. 4.3
In gcneral, cach servicc can provide its functionality to other services and it can
also rcquire somc functionality from other scrvices. The formcr role of the service
is rcfcrred to as a "servicc providcr" and the latter one as a "service consumer').
Because cach service can play both roles, it should realize a provided interfacc
of thc scrvice provider and has a rcquired intcrface of the scrvice provider. In
addition, sincc the communication of the serviccsis asynchronous,our model is
based on thc Observer pattern [
Figure 3 depicts a static model of co-operating services Snath and Splus. Here, the servicc Snath plays the role of a serviceconsumer and thc scrvice Splus plays the rolc of a servicc provider. Both servicesrealize intcrfaces: IProvider and fConsumer. IProvider contains a mcthod attach(service). Using this method, a servicc consumer registers at the servicc provider. The registration also includes a service requcst, which is representcd as a service parametcr of thc attachO operation in the model. Such requestsarc queued. It is modeled by mcans of aggregation with the service provider being an aggregate. As soon as the service provider completcs the requcst processing,a method notifyConsumero sends a messagc with the result to the service consumer. The corresponding operation in the model is setResult(servicerslt).
-i-
I r----<-<s-erlv-tc-e>->----r | =o'* | | | theConsumer-> setResult(servicersft) If we want to model scrvice-to-servicc connection during service co-operation, we can not usc the approach we used to model components composition inside a servicc (section 4.1). Components are assembledinto services in advance in design time. On the other hand, servicescan be discovered and are bound dynamically. Consequently, we can model service co-operation only by means of UML behavioral models, namely state machinc and interaction diagrams. We have chosen a sequence diagram to model communication of services. Since the rnodeledentities are services,thc diagram have to fulfill the fbllowing restrictions: - Lifelines are scrvices. - All messagesamong scrvices are asynchronous.
Thc second rcstriction cnsures that a sender does not wait for a rcplay (after a rcquest was sent) and the sender can acccpt anothcr incoming messagesor proccssstored requcsts (replics). Figurc 4 showscommunication of servicesSmath and Splus from Figurc 3.
This paper briefly discussesthe use of object-oriented approach in SOAD. It is shown that information hiding, messaging, classesand instances, and cncapsulation arc concepts that can be used in SOAD. In addition, they are supported by UML. Thereforc, UML was chosen as a modeling languagc for components, services and servicc co-operation. UML providcs well-defined diagrams for modeling composition of componcnts inside a service and for modeling collaborations of serviccs including thcir communication. The future work will focus on improvcmcnt and extension of the approach mentioned above, especially on creating a meta-model of servicc co-operation and service aggregation that will enablc to develop more advanccd and sophisticated models. In addition, it would be uscful to create some vcrification methods for created models .
Th'is research has beensupported bg the Grant Agencg of Czech Republ'ic arants No. 102/05/0723 "A Framework for Formal Speci,ficati,onsand Prototypi'ng of