Modeling enterprise service-oriented architectural styles

SOCA (2010) 4:81–107DOI 10.1007/s11761-010-0059-2

ORIGINAL RESEARCH PAPER

Modeling enterprise service-oriented architectural styles

Longji Tang · Jing Dong · Tu Peng · Wei-Tek Tsai

Received: 11 August 2009 / Revised: 30 January 2010 / Accepted: 31 March 2010 / Published online: 13 May 2010© Springer-Verlag London Limited 2010

Abstract Modern enterprise consists of complicate busi-ness processes and systems. The Enterprise Service-OrientedArchitecture (ESOA) becomes an important architecturalstyle that defines the principles for coping with the complex-ity of designing and implementing business systems. Thispaper classifies ESOA styles to six substyles and proposesa generic and abstract model for ESOA styles. The modelconsists of seven sets: services, service consumers, servicedata, infrastructure, processes, management and quality attri-butes. This paper formally defines each set and their relation-ships in ESOA style model, and discusses the roles of thesesets. The model can be applied to specify various ESOAstyles. As case studies, the definition of instance of ESOAstyle is applied to analyze and evaluate a Java component-based ESOA-style architecture and several other ESOA-stylearchitectures. Finally, this paper concludes by comparing theproposed model with related ESOA models.

L. Tang · J. Dong (B) · T. PengDepartment of Computer Science, University of Texas at Dallas,Richardson, TX 75083, USAe-mail: [email protected]

L. Tange-mail: [email protected]

T. Penge-mail: [email protected]

W.-T. TsaiDepartment of Computer Science and Engineering,Arizona State University, Tempe, AZ 85287, USA

W.-T. TsaiTsinghua University, Beijing, Chinae-mail: [email protected]

Keywords Architectural style · Enterprise service-orientedarchitecture · Domain ontology · Web services · Softwarequality attributes

1 Introduction

With frequently changing business requirements and the fastdevelopment of technology, enterprise systems have to bebuilt based on adaptable, flexible, and reusable architec-ture. To reduce coupling, service-oriented architecture (SOA)[12,18,19,25,59,66,68,79] has been applied in many soft-ware systems by assembling loosely coupled services that canbe used within multiple business domains. SOA provides aflexible set of design principles, constraints and governingconcepts to aid in system design, development and integra-tion. It defines the interface in terms of protocols and func-tionality. It also defines service communications by passingdata in a shared and well-defined format, or by coordinatingan activity among services. SOA can help businesses respondquickly and cost-effectively to changing market-conditionsby promoting interoperability, reusability and extensibility.

Enterprise SOA (ESOA) is a special type of SOA for enter-prise. As an architectural style [54,57,20], it is an abstractionof a family of concrete architectures (instances of a style).It specifies the key aspects of the architectures, encapsu-lates important design decisions of common architecturalelements and emphasizes on common constraints as well astheir relationship. ESOA combines SOA basic principles andconstraints with specific enterprise architecture environmentand business requirements (functional and non-functional).From architectural style prospective, ESOA has more con-straints than SOA. The constraints of ESOA are based onenterprise-wide requirements which will be specified in thenext section. ESOA is a new enterprise software architectural

123

82 SOCA (2010) 4:81–107

style that is an abstraction of concrete SOA architectures inenterprises. Many enterprise architectures, such as Amazonweb service architecture, IBM SOA-based enterprise archi-tectures, are the instances of ESOA. ESOA and its substylesfocus on service orientation, loose-coupled integration andinteroperability [12], agility, performance, reliability, reus-ability and extensibility. Enterprise systems consist of com-plicated applications in heterogeneous environments. ESOAcan better aid application integration because of its interop-erability and relatively loose coupling service nature.

Enterprise architecture (EA) is for both business and cus-tomers. Thus, EA is required to be easy to change with highflexibility. ESOA can help EA to achieve those goals. More-over enterprises believe ESOA can enhance their softwarereusability from “class” to service so that it can help enter-prise to reduce its IT cost. Scientists have developed formalservice models [5], semiformal service models in UML [4],and formal service interaction models [15]. Recently variousESOA models have been proposed, such as

• OASIS SOA Reference Model [45] based on the Entity-Relationship (ER) model;

• SOA Meta Model based on the UML profile [7];• Enterprise Service Bus (ESB) centric ESOA model based

on integration notation [9];• IBM Foundation SOA component model [24];• Microsoft ESOA model BizTalk [40];• BEA Aqualogic Service Bus model [14];• Oracle ESB model [51];• Pattern-oriented SOA model [78,28]; and• RESTful model of Web-Oriented Architecture [63].

All these models either focus on the aspects of ESOA whichare not abstracted as an architectural style or are vendor-spe-cific implementation of the ESOA. Although a style-basedapproach for modeling and validating SOA application isproposed in [4], it does not emphasize enterprise-wide SOAapplication and non-functional constraints.

In addition, lack of understanding of enterprise service-oriented architectural style and its set of constraints whichincluding software architectural quality attributes as well astheir tradeoff often leads to design-by-buzzword and failure-in-runtime in enterprises. Our research work is motivatedby the desire to understand the complicated ESOA architec-tural styles and their design constraints and by the desire toguide the ESOA architecture design. This paper focuses onESOA generic model and styles based on our earlier work[16,62,63,67,68].

This paper classifies a generic ESOA architecture model,specifies the ESOA styles, and evaluates typical ESOA archi-tectures by using the proposed model and ESOA style analy-sis methodology. Our ESOA model and formal and informalstyle specification can help with understanding the compli-

cated ESOA architectures and in guiding better design ofESOA systems.

This paper is organized as follows: Sect. 2 discusses thearchitectural context in service-oriented enterprise; Sect. 3defines a generic ESOA architecture model; Sect. 4 analyzesenterprise service-oriented architectural styles; Sect. 5 spec-ifies the enterprise web service architectural style; Sect. 6provides a comparison among different ESOA sub-styles;Sect. 7 presents several case studies that apply the ESOAmodel and styles to analyze and evaluate several enterprisesystems; Sect. 8 discusses the related work; Sect. 9 summa-rizes the conclusions of this paper.

2 Architectural context in service-oriented enterprise

This section describes the characteristics of modern enter-prise architecture, specifically the architectural context inservice-oriented enterprises. Table 1 summarizes variouscharacteristics of modern enterprise information systems.

The characteristics of enterprise information systemsare also the basic characteristics of enterprise architecture,which indicate the complexity, requirements and concernsin designing enterprise architecture. Enterprise ApplicationIntegration (EAI) as an integration style provides the prin-ciples for building middleware-centric enterprise architec-ture, such as SUN’s J2EE, Microsoft .NET, and has aided insolving more and more complicated enterprise systems inte-gration issues from early 2000 [2]. However traditional EAIdid not fully resolve enterprise integration issues because oftight-coupled traditional EAI architecture, lack of good inter-operability, and poor scalability as well as security. ESOA,as a better approach than EAI, has been broadly adopted byenterprise since 2003 [37]. ESOA is a new architectural stylewhich is a general SOA style for enterprise architectures.

Figure 1 depicts architectural entities and their relation-ships within service-oriented enterprise through a domainontology and reflects the characteristics found in Table 1. Itis the foundation of our study on generic ESOA architec-tural model and styles. Compared with other styles, such asclient-server, component-based EAI, ESOA styles are ser-vice-oriented.

The major architectural entities in service-oriented enter-prises include

• Customer or event – A customer is a person who requestsbusiness services from the enterprise, and an event is anotable thing (“a significant change in state”) that hap-pens inside or outside of an enterprise.

• Application – the interface between customer and ser-vice and another kind of service consumer. Applicationinvokes service either by actions or events.

• Service – the operator of the service provider, which isregistered in service registry and serves functionalities tocustomers.

123

SOCA (2010) 4:81–107 83

Table 1 Characteristics of enterprise information systems

characteristics Description

Customer oriented • System design is based on customers’ requirements

• System is interacted by customers

• Systems serve customers and meet business demands

Heterogeneous environment • Complicate organization structure

• Multiple-vendor software products

Distributed computing • Everything is connected by enterprise networks

• Software systems are highly distributed through the Internet

Integration • Modern software systems are integrated with existing legacy systems

• Different systems in different organization or different enterprises are integrated.

Manage and access customer/business data andsystem data

• Business and customer data is managed and can be accessed

• System data is managed and can be accessed

Support business processes • Business transactions

• Workflows

Meet certain non-functional requirements • Performance

• Security

• Scalability

• Agility

• Flexibility

• Extensibility

• Reusability

• On time and within budget

• Other requirements

• Service provider – the container or engine of service.• Process – the coordinated and composited set of services• Infrastructure – a set of virtual and physical servers and

systems, such as web servers, OS, application servers.database, registry, network, file system.

• Management – the manager and controller of service-ori-ented systems, such as service life cycle manager, securitymanager.

• Data – the data includes customer and business data forenterprise business and system data for defining as wellas building a service-oriented architecture and controllingruntime behaviors

• Functionality – the functional requirement of the systemand the service operation served by service.

• Non-functional requirement – the software quality thatservice-oriented system should meet.

The domain ontology is independent of any technologiesand implementation chosen by enterprises for building a ser-vice-oriented system. It not only specifies the relationshipamong architectural elements, but also describes the rela-tionship between architecture and customers (business) aswell as their requirements. Specifically, the non-functionalrequirements are specified as constraints for analyzing anddesigning the service-oriented systems.

3 A model of enterprise service-oriented architecture

Section 2 presented a domain ontology to describe the archi-tectural entities and their relationships in the ESOA. Based onthe domain ontology and SOA principles [18,19] on ESOA[9,37], this paper proposes a 7-tuple generic abstract modelof ESOA:

E SO A = 〈S, C, D, SI, SM, S P, SQ〉 , (3.1)

An ESOA is a set of SOA elements, environment, processes,principles and quality attributes in an application, which arespecified by the following architectural parts:

S = {si |si is a service} (3.2)

C = {ci |ci is a service consumer} (3.3)

D = {di |di is a SOA data element} (3.4)

SI = {ri |ri is a SOA infrastructure} (3.5)

SM = {mi |mi is a SOA management} (3.6)

S P = {pi |pi is a SOA process} (3.7)

SQ = {qi |qi is a SOA quality attribute} (3.8)

Each architectural part is a set of its specific elements in(3.2–3.8) in which each element in each set is correspondingto one entity of the domain ontology in Fig. 1. Specifically,

123

84 SOCA (2010) 4:81–107

Fig. 1 Domain ontology of service-oriented enterprise

the service in S corresponds the “service” entity; the serviceconsumer in C is one of entities, “customer” or “application”.The SOA data element in D is the system data part of “data”entity. The SOA infrastructure element in SI is the “infra-structure” entity; The SOA management element in SM isthe “management” entity; The SOA process element in SPis the “process” entity. The SOA quality attribute element inSQ is the “non-functional requirement” entity. The formula(3.1) can be described by an upper domain ontology diagramin Fig 2.

This paper differentiates seven different classes ofservice-oriented architectural parts:

• Services;• Service consumers;

S

ESOA

1..*

1

SQ

SM

SP

1 1..*

11..*

C

SI

D

1

1..*

1

*

1

1..*

1

1..*

Fig. 2 ESOA domain model

123

SOCA (2010) 4:81–107 85

• SOA data elements;• SOA infrastructure elements;• SOA management elements;• SOA processes; and• Quality attributes.

3.1 Services

In formula (3.1), S is a finite set of services and a serviceis the fundamental element of SOA. Informally, a serviceis a self-contained software abstraction of business, techni-cal functionality, or infrastructure management, defined by awell-defined interface that focuses normally on the descrip-tions of functional aspects, such as input, output, precon-ditions and effects known as IOPE [16]. Services in S arepublished through the service registry in the Service Infra-structure (SI). They are discovered and bound by the facilitiesin SI. In addition, services are consumed by service consum-ers in C. There are three kinds of fundamental services inESOA in terms of the fundamental service classification in[26]:

• Basic services which are the fundamental elements ofESOA.

• Composed services that are composed from basic ser-vices;

• Process services are those services that perform processcomputation in ESOA.

3.2 Service consumers

To serve service consumers in C and execute business man-agement processes, composed services and process servicesare orchestrated and/or choreographed by the Service Pro-cess (SP). Based on the states of services, Services can beclassified as stateless services and stateful services. The tra-ditional web services are stateless [19], whereas the Gridservices defined by the Web Service Resource Framework(WSRF) [48] are stateful services. Section 6 will discussWSRF services.

3.3 SOA data elements

These (D) include SOA meta-data, policy data and other ser-vice data used by all other parts in the ESOA model. Thereare two kinds of service representations:

• WSDL-based representation [74].• Ontology-based representation, such as OWL-S [73] for

describing semantic web services.

The service representation or specification is a subset of D.

3.4 SOA infrastructure

This (SI) is the heart of ESOA, which discovers, routes andbinds services to proper service providers based on the ser-vice requests from service consumer C . In the previous sec-tion, SI is defined as a layered architecture model. Each layercan consist of a set of services, such as communication ser-vice, on-ramp service and off-ramp service. Thus, any infra-structure service is denoted I S ∈ S ∩ SI .

3.5 SOA Management

This (SM) controls SI, and SP. It relies on SOA quality attri-butes SQ. Four common SOA management functions areprovided:

1. Business Management manages the transformationbetween business model and services model: serviceorchestration and/or service choreography in SP for busi-ness processes, transaction and workflow.

2. Lifecycle Management controls S, SI, SP at servicemodelling, assembling, service routing, transformation,and versioning.

3. Quality-of-Service (QoS) management provides qual-ity of service (QoS) assurance based on the SQ. Forexample, QoWS [52] provides QoS management.

4. Security and Policy Management controls service withsystem level security and policy by using various secu-rity definition data in D as well as security and policyservices in S.

SM monitors SI, S, and SP by observing system run-timebehaviours, measures various performance and QoS metrics,and reports back to a control agent, such as QoWS.

3.6 SOA processes

This (SP) is composed of services in S and defined by busi-ness management in SM. SP includes two main kinds of pro-cesses [53]:

• Service Orchestration (SO) which refers to an executablebusiness process that can interact with both internal andexternal services.

• Service Choreography (SC) which defines the interactionbetween independently defined processes.

They can be formalized by Petri nets [38], π -calculus [15]or other formalisms. Petri nets are suitable for modellingconcurrency. The basic elements, e-service net and orches-tration net for modelling the SO, is developed in [38]. IBM’sWeb Services Flow Language (WSFL) adopts Petri nets forexpressing the service process logic. The π -calculus is a kind

123

86 SOCA (2010) 4:81–107

Fig. 3 Governed service view

of process algebra [41] for modelling processes. It can beused for modelling SO and SC [15]. Moreover, the SOA pro-cess languages, such as Microsoft’s XLANG and Oracle’sWS-CDL, are inspired by π -calculus. Note that once for-malized, software services can be analyzed using numeroustools that have already been developed. For example, if aservice has been formalized by Petri nets, reachability anddeadlock analyses can be conducted.

3.7 SOA quality attributes

These (SQ) are important to all other parts for architec-tural decisions and design. The quality attributes are con-straints for structure and behavior of services, processes,infrastructures and management. They provide the princi-ples and guidelines for analyzing and designing ESOA. Forinstance, the extended service defined in (2.10) in [62] canbe called a “Governed service” depicted in Fig. 3.

Model (3.1) is an abstraction of general ESOA architec-tures which include different families of ESOA architec-tures, such as web service SOA architectures based on SOAP(Simple Object Access Protocol) [18] and RepresentationalState Transfer (REST) web service SOA architectures basedon HTTP protocol [20]. For different ESOA architecturalfamilies, the above seven parts can be specified with theirdifferent characteristics.

4 Enterprise service-oriented architectural styles

Section 3 defined a generic model of ESOA architectures.There are different families of ESOA architectures. In gen-eral, an architectural style defines a family of architec-tures with common structure and constraints. The enterpriseservice-oriented architectural styles are abstractions fromdifferent families of ESOA architectures. Like SOA archi-tectural style, the ESOA architectural style is the umbrella ofall different ESOA substyles. Figure 4 shows various ESOAarchitectural styles based on (3.1).

The SOAP-based enterprise service architecture is the firstsubstyle of ESOA, called EWS-* style in this paper.

The Web SOA (WOA) based on REST architectural style[20,21] and enterprise Web 2.0 is another substyle (calledEWOA) [63] of the ESOA.

Fig. 4 ESOA classification and hierarchy

Unlike the request-driven styles such as EWS-* style andEWOA style, the Enterprise Event-Driven SOA (EEDA) isan event-driven style [55,64].

Because of the maturity of component-based technol-ogy and application server, the enterprise component-basedservices architecture (ECBS), such as the Service Compo-nent Architecture (SCA) [44] and J2EE component-basedenterprise services approach [6], becomes another substyleof ESOA.

Unlike the above styles, the enterprise grid-enabled SOAcalled EGSA style in this paper is a hybrid style of the ESOAstyle and the grid computing style [8,50,34,60] which coor-dinates computing resources that are not subject to central-ized control and provides dynamic scalability and continuousavailability.

In addition, many enterprise systems have used a hybridapproach by combining two or more different ESOA sub-styles. Figure 4 shows the classification of ESOA styles andtheir hierarchy.

Table 2 provides the definition and related references foreach basic ESOA substyle.

5 Enterprise web service architectural style

This section specifies one of ESOA substyles EWS-* with theproposed generic model (3.1). The EWS-* defines a familyof ESOA architectures—SOAP-based web service architec-tures.

5.1 Services

This paper defines an abstract model of services with bothfunctional aspects (operations) and non-functional proper-ties (quality attributes or semantics). Specifically for EWS-*style services, the functional descriptions of services arebased on WSDL 2.0 [74] whereas the non-functional descrip-tions are based on its extensibility that allows extendingWSDL 2.0 at both the element and attribute levels. For exam-ple, SAWSDEL [31] is the Semantics Annotation for WSDL2.0, which is the first standard for adding quality semanticsinto the service descriptions.

123

SOCA (2010) 4:81–107 87

Table 2 Description of basic substyles

Styles Style keywords Descriptions

EWS-* Simple Object Access Protocol (SOAP)Request/ResponseWeb serviceWeb service standards (WS-*)

It is SOAP-based enterprise service architectural style. Specifically thestyle is based on a series of web service standards called WS-* [77].

EWOA Representation State Transfer (REST)HTTP protocolRequest/ResponseWeb 2.0Web-Oriented Architecture (WOA)

It is Enterprise Web-Oriented Architectural style. The Web-OrientedArchitectural style is first defined by Gartner [21]. The EWOA styleis specified in [63].

EEDA EventsEvent-Driven Architecture (EDA)Event-Driven ServicesComplex Events Processing (CEP)Events Channel

It is Enterprise Event-Driven Architectural style which is a hybridstyle with ESOA and EDA style. The EDA is introduced in [37] andis defined as a SOA style by Gartner [55].

ECBS Component-basedService Component Architecture (SCA)Enterprise Java Bean(EJB)Java Business Integration (JBI)

It is Enterprise Component-Based Service Architectural style which isbased on service component-based specifications, such as SCA [44]and SUN’s JBI [56] as well as EJB [6]

EGSA Grid ComputingOpen Grid Services Infrastructure (OGSI)Web Service Resource Framework(WSRF)Grid Standards (OGSI, WS-Resources)

It is Enterprise Grid-Enabled Service Architectural style which is ahybrid style with ESOA and Grid computing style [8].

We define a web service as a set of service operations:

SOp = {oi |oi is an operation} , (5.1)

where

oi = ⟨ni , ini , outi , in fi , out fi , mcpi , qi

⟩

in which ni is the name of operation oi ; ini is the incom-ing message of a service and outi is the outgoing messagefrom a service; inf i and out fi indicates whether a fault (Thefault is an event that happens during the execution of a mes-sage exchange that disrupts the normal flow of message.) isinjected to the service or generated by the service, respec-tively; mcpi denotes message exchange patterns. WSDL2.0 supports eight message exchange patterns as shown inTable 3; qi is the set of quality attributes, such as transactionfor the operation.

Formally, a web service s ∈ S is a 5-tuple:

s = (I, Ms, Pf , l, Qs

), (5.2)

where I = ⟨SOp, QI

⟩, which is the service contracts or

interface in which SOp is the set of operations provided forservice consumers; and QI is the set of quality attributes forthe interface, which can be described by a set of features anda set of properties such as security request features and secu-rity-level properties, through WSDL 2.0 extension, such asSAWSDL [31]. SOpand QI define the functional and non-functional behaviors of a service, respectively.

Ms is a set of internal states of the service, which canrepresent any information it manages, like variables, servicelifecycle states [76], and interaction states.

P f is the internal process which denotes the service func-tionality encoded by the formalism f. P f denotes a serviceimplementation model which is not visible outside of service.The functionalities implemented by P f provide services toconsumers through the interface.

l ∈ SI defines the service location, such as a set ofendpoints: l = {ep|ep is an endpoint} for SOAP-based webservices where the service deployed and its runtime environ-ment. Formally, for a web service,

ep = 〈Binding, Address〉

where the Binding specifies a concrete message format andtransmission protocol used for defining the endpoint; theAddress is an optional WS-Addressing reference.

Qs ⊆ SQ, which defines service quality attributes suchas interoperability, performance, and security at the servicelevel, also called Quality of Service (QoS) and ServicesLevel Agreement (SLA), as well as service properties Sp.We define

Qs = {common quality attributes} ∪ Sp (5.3)

where the common quality attributes for SOA are describedin [49] and

123

88 SOCA (2010) 4:81–107

Table 3 Message exchangepatterns

Pattern name Description

In-Only A standard one-way message exchange where the consumer sends amessage to the service provider only.

Robust In-Only This pattern is for reliable one-way message exchanges. The consumer(client) initiates a message to which the service provider responds withstatus. If the response is a status, the exchange is complete. If theresponse is a fault, the consumer must respond with a status.

In-Out This is equivalent to request-response. A standard two-way messageexchange where the consumer (client) sends a message, the serviceprovider responds with a message or fault and the consumer respondswith a status.

In Optional-Out A standard two-way message exchange where the provider’s response isoptional.

Out-Only The service operation produces an out-only message, and cannot trigger afault. This is equivalent to the notification message pattern.

Robust Out-Only The service operation produces an out-only message, and can trigger a fault.

Out-In This is equivalent to the solicit-response message pattern. The servicesends a message to the consumer and receives a response message fromthe consumer.

Out Optional-In The service produces an out message first, which may optionally befollowed by an inbound response.

Sp = {standardized service contracts,

reusability, relative autonomy,

statelessness, discoverability,

relative loose coupling,

abstraction, composability}

Qs also called non-functional properties can be describedthrough service ontology of Web Service Modeling Ontol-ogy (WSMO) [71] or Ontology Semantic Markup for WebServices (OWL-S) [36] and linked through the extensibilityof WSDL 2.0.

Formula (5.2) is an extension of the formula of servicein [22]. The 5-tuple is an abstraction of service in EWS-*,which abstracts away the concrete service implemented byspecific technology with particular formalism f and the rep-resentation of the internal states. Formula (5.2) defines bothservice structures and its behaviors. I defines both functionaland non-functional contracts which include data and ser-vice behaviors. Ms, Pf , Qsmainly define the internal servicelogic which is the implementation of the contracts of data andbehaviors defined by I . l defines an endpoint where a servicecan be accessed. Visually, a web service can be depicted inFig. 5.

Figure 5 not only describes formula (5.2) and (5.3) visu-ally, but also depicts the relationship between the service andexternal system, such as the Data Sources, and the Registry,which belongs to SI in (3.1). Moreover Fig. 5 shows the

Fig. 5 UML model of web service

service composability which means services can be compos-able for completing a business task, such as a transaction.It is one of the service properties in Sp and is a pre-conditionfor constructing SP.

5.2 Service consumers

The traditional service consumers are any applications whichcan access web services, such as a web-based J2EE applica-tion or a .NET application. An action-based service consumer

123

SOCA (2010) 4:81–107 89

Fig. 6 Action-based service consumer

is defined as 5-tuple

c = 〈Ec, Fc, Ac, Mc, Qc〉 , (5.4)

whereEc is a set of elements including

• Data elements, such as data objects• Component elements, such as controller, filter, state man-

ager, web cache• Connector elements, such as adaptor, AJAX

Fc is a set of forms which include

• User interfaces• Web-based interfaces• System properties

Ac is a set of actions which include

• External actions, such as an event trigger for servicerequest or a SOAP message sending to a SOAP-basedweb service.

• Internal actions, such as a trigger for operations or a replyprocessed by the services.

Mc is a set of internal states that determine the consumer’sbehaviour.

Qc ⊆ SQ is a set of client system quality attributes.A typical action-based web service consumer can be mod-

elled as shown in Fig. 6 whose components can be mappedto the formula (5.4) as follows:

Ec = {Connectors, Controller, Filters, Domain objects,State manager, Business delegation objects, Wid-gets},

Fc = {Web forms, GUI components, Interface Config,Server config},

Ac = {Action Events, Action Handlers},Mc = {GUI States, States},Qc = {security (through SSO, ACL), performance (defined

in Config)}

Once this aspect is formally specified, one can perform var-ious analyses based on service consumers:

1. User-service interaction: the interaction can be shortand brief like UML use cases, or can be extensive likeuse scenarios [69], and anything in between [33,35]. Theuser-service interaction can be useful for system compo-sition, integration testing, and automated test script gen-eration. For example, given the user-service interactionspecification of a consumer, it is easy to verify that agiven service can provide the needed service.

2. Profiling and provisioning: Once the workflow andusage pattern of a service consumer is known, the infor-mation can be useful for profiling and resource provision-ing. This is important for QoS-based system evaluationand assurance.

3. GUI representation: System GUI can be formally spec-ified and analyzed [70] for completeness analysis (allinputs or combinations of inputs can be handled by thesystem, and each input button in the GUI has the corre-sponding action routine to respond), reachability analysis(all path leads to an end state), and consistency analysis(the system will deliver consistent answer for consistentinput).

4. Data flow analysis: from input-output and from an archi-tecture description of interconnecting services, one canshow flow from one service to another service. This infor-mation can be useful for data provenance and variousdata analysis such as data integrity analysis.

5.3 SOA data elements

The D in (3.1) is a set of SOA data elements that is a finiteset. For EWS-* style, the D is formed by various web servicemetadata and data files, such as WSDL file, policy defini-tion file, web service process definition files, infrastructureconfiguration file, resource metadata, and SOA managementdata. Table 4 lists major SOA data elements for EWS-*.

In the SOA data, the service metadata, such as service def-inition and service registration data, plays a key role in SOA[13].

Note that many data elements are represented by XMLand thus they can be analyzed or reasoned based on

123

90 SOCA (2010) 4:81–107

Table 4 SOA data elementsData elements Examples of web services

Resource metadata Metadata of Web services, Clients, Database, mainframes, caches

Resource identifier UDDI keys, data sources

SOA metadata XML Schema (XSD)

Service description

Endpoint schema

Infrastructure data Administrative metadata

Process data WS-CDL document

BPEL, XLANG documents

Service specification WSDL documents

Management data Monitor report, SLA data

Policy data XACML documents

XML-related tools. For example, many ontology systemsincluding RDF, OWL, and OWL-S are all based on XMLand many reasoning tools such as DL (Description Logic)can be used for reasoning. Policy data can be subjected tocompleteness and consistency checking, dependency analy-sis, simulation, and performance evaluation [69,70].

5.4 SOA infrastructure

The SOA infrastructure is the heart of ESOA. It supportsthe transformation of business in an enterprise or betweenenterprises into a set of managed services S or repeatablebusiness tasks, which can be accessed over a network whenneeded. The network can be a local network, the internet, ora wireless device network. The SOA infrastructure SI is thebridge of the transformation between business and services.It is defined as three layers, each of which consists of internalservices and components for a traditional ESOA or EWS-*style ESOA:

• Connection layer which includes rich client API, standardprotocols, such as HTTP, SOAP, TCP/IP, and adapt-ers. The layer provides connectivity to different applica-tion systems and services, such as ERP, CRM, Finance,Shopping/Shipping, and Travel, in different platforms,such as J2EE, .NET, and legacy backend systems.

• Communication layer which includes message services,such as JMS and SOAP Engine, and provides the capa-bility of carrying messages between services as well astransfer various messages such as XML message in a reli-able and secure way.

• Mediation layer which includes a set of on-ramps, a setof off-ramps, smart routing services, transformation ser-vices of protocols, and data. It provides the semanticglue between disparate services and different applicationsin enterprises. It includes transport protocol conversion,

smart service routing, service invocation and dispatch,and etc.

The Enterprise Services Bus (ESB) [9] is one of the imple-mentations of SI. It is the core of the SOA infrastructure for atraditional ESOA. For Web SOA, the infrastructure includesthe HTTP servers and other web infrastructure. This paperfocuses on traditional ESOA (EWS-* style).

Another popular trend is the use of a cloud com-puting environment where service requests are automati-cally tracked and provisioned like Google’s App Engine.Such cloud computing environments are still the sub-ject of active research. A cloud computing infrastructureoften consists of three separate infrastructures: parts-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). IaaS is at the bottom and SaaS is on thetop in user interaction.

5.5 SOA management

The SOA Management SM plays an important role in ESOA.It is defined as a 5-tuple for an EWS-* style

SM = (Im, Cm, Sm, Am, Qm), (5.5)

where

Im is a set of SOA management interfaces which providemanagement operations to EWS-* system.

Cm is a channel of SOA management which provides theconnectivity and communication between the manage-ment interfaces and service interfaces.

Sm is a set of management servers which include the direc-tory server, messaging server, policy server, and servicemanagement server. They provide a set of managementoperations:

123

SOCA (2010) 4:81–107 91

Fig. 7 SOA management

• Resource management: services as system resources;• Service and infrastructure discovery;• Network and application monitoring;• Policy enforcement;• Service-level agreement management;• Exception management;• Closed-loop governance; and• Service lifecycle management.

Am is a set of distributed agents which monitor any ESOA-style system.

Qm ⊂ SQ ∪ D, which is a set of metadata and qualityattributes specified in management policies and service-levelagreement.

Figure 7 describes the relationship among elements andtheir relationships in (5.5).

For an EWS-* style, OASIS has proposed several stan-dards: WSDM (Web Service Distributed Management) [47],MUWS (Management Using Web Service) [43] and MOWS(Management of Web Services) [42] for web servicesSOA management. For an EWS-* style with WSDM, theManagement Channel Cm is part of SOA infrastructure, theManagement Interface Im is the set of web services endpoints,the Management Service Sm is the set of web services formanagement, the distributed agent Am is a set of manage-ment agents, and the quality Qm is a set of quality attributesand properties of services and its infrastructures.

5.6 SOA processes

The SOA Process SP is an important part of any ESOA-stylesystem, since a complex business task must be completed inmultiple steps of business process. The business processescan be executed by multiple services which are managed ina SOA process. A SOA process includes a set of compositeand/or coordinating services in various process patterns, such

Table 5 SOA processes

Service process Examples of web serviceprocess standards

Orchestration Web services Composition:

WS-BPEL, XPATH

Choreography Web services coordination:

WS-CDL, BPML,WSCI

Fig. 8 SOA processes view

as sequence or parallel. Its major elements [53] are shown inTable 5.

Figure 8 shows the general SOA processes. DifferentESOA styles have different SOA process styles. An EWS-*process is mainly based on two WS-* standards:

• Web Services Business Process Execution Language(WS-BPEL).

• Web Services Choreography Description Language (WS-CDL).

Formally, we define the orchestration process in the follow-ing form:

SO = {soi |soi is a service orchestration process}where

soi = 〈Sorc, Iorc, Morc, C Sorc, Corc, Horc, Aorc, Qorc〉(5.6)

in which

Sorc ⊆ S is a set of services executed in certain order definedby BPEL [46].

Morc = {STorc, Dorc} in which STorcis a set of states andDorcis a set of variables as well as data.

123

92 SOCA (2010) 4:81–107

Table 6 Mapping to WS-BPEL

Abstract model Component in WS-BPEL

Sorc <partnerLinks> – roles of process participants

Iorc <portType> – the operation interfaces ofparticipants

Morc <variables> – the data and state used withinprocess

C Sorc <correlationSets> – properties that enableconversations, such as the initial state; messageinvocation patterns:request|response|request-response

Horc <compensationHandler>,<eventHandler>,

<terminationHandler>,<faultHandler>

Aorc

aobs <receive>, <pick>, <onEvent>, <onMessage>,<onAlarm>, <reply>

τunobs <assign>,<compensate>,<flow>,<invoke>,<scope>,<sequence>,<switch>,<while>,<wait>

φ <empty>

Qorc Such as <compensationHandler> for transaction;<faultHandler> for reliability

C Sorc is a set of correlations of messages.Corc is a set of orchestration process coordinators or con-

trollers.Horc is a set of handlers;

Aorc = 〈aobs, τunobs, φ〉 in which aobs is a set of observ-able actions, and τunobs is a set of silent actions performedby the process, φ indicates no action for an idle process.Aorc defines the interaction model of an orchestration.

Qorc ⊂ Q is the set of orchestration process quality attri-butes. Table 6 describes a mapping from model (5.6) tothe components in WS-BPEL [46].

From Table 6, one can see the proposed model is an abstrac-tion of WS-BPEL and it is a concise form, which capturesits core concepts and parts, such as process participants,interfaces and activities, and extends it with quality attri-butes.

Visually the orchestration can be depicted both structur-ally and behaviourally by the UML activity diagrams. Fig-ure 9 is an example of sequence services orchestration pro-cess modelled by UML activity diagram.

The service choreography can be formally defined as

SC = 〈C H O, I N Fcho, Pcho, Icho, Lcho, Ccho〉 , (5.7)

in which

C H O = {sci |sci is servicechoreography}where

sci = 〈C H Osub, Mcho, Acho, C Rcho, Qcho〉 , (5.8)

in which

Fig. 9 Service orchestrationprocess

act Orc Process

Web Service2

Web Service1Orchetration Process - ServiceClient

Request services

Interface <receive>interface

<invoke>

interface

<invoke>

<reply>

<invoke>

Web service

Web service

Actor

Web service 3

Web service

interface

«invokes»

123

SOCA (2010) 4:81–107 93

Table 7 Mapping to WS-CDL

Abstract model Component in WS-CDL

SC <package> – a groups of abstract types

sci <choreography> – contains other choreographies,variables, activities, rules and exception handlerand finalizer

I N Fcho <informationType> – declaration of data types

Pcho <participateType> – abstract of a participatingservice, specifically, orchestration process

Icho <roleType> – a specification of operationinterfaces of participants

Lcho <relationshipType> – A relationshipTypeidentifies the roleTypes and behaviors, wheremutual commitments MUST be made forcollaborations to be successful.

Mcho <variables> – the data, state, channel informationused within choreography

Ccho <channelType> – A channelType realizes a pointof collaboration between participantTypes byspecifying where and how information isexchanged.

Achoaobs <sequence>, <parallel>, <choice>, <interaction>,

<perform>, <workUnit>

τunobs <assign>,<silentAction>

φ <noAction>

C Rcho collaboration rules and constraints

Qcho Such as <exception>, <finalizeBlock> forreliability

C H O is a set of choreographies for participating collabora-tions.

I N Fcho is a set of data type declarations for messages.Pcho ⊆ S P ∪ S is a set of services and service processes.Icho is a set of interfaces of participants, which define the

observable behaviour of each participant.Lcho is a set of links among publicly observable participant

behaviour – the constraints between two interfaces.Mcho = {STcho, Dcho, C Hcho} in which STchois a set of

states; Dcho is a set of variables and data; C Hchois aset of information of communication channels, such asURI.

Ccho defines a point of collaboration between participantsby specifying where and how information is exchanged.

Acho = 〈aobs, τunobs, φ〉 in which aobs is a set of observ-able actions performed by the participants, and τunobs isa set of silent actions which are unobservable, but impactglobal observable behaviour, and φ indicates no actionfor an idle participant.

C Rcho defines choreography collaboration rules and con-straints, such as order rules = {sequence, parallel,choice}; exception handling rule; and finalizing rule [75].

Fig. 10 Structural model of service choreography

Qcho ⊂ Q is the set of service choreography quality attri-butes. Table 7 shows a mapping from the abstract modelto the main components in WS-CDL [75].

Table 7 shows the proposed model is an abstraction ofWS-CDL. It is a succinct form in concept and structurewhich catches its core concepts and parts, such as chore-ography, process participants, and activities. Moreover ourmodel extends WS-CDL with quality attributes.

The UML diagram of the service choreography structuralmodel (5.6) is shown in Fig. 10.

The SC behaviours can be modelled in terms of UMLbehavioural diagrams, such as sequence diagram and activ-ity diagram. Figure 11 shows a choreography example withfour participants.

Pcho = {Buyer, Seller, PaymentService, ShipService}Although one can map the orchestration model to WS-BPELin Table 6 and map the choreography model to WS-CDL inTable 7, the proposed models are independent of concretelanguages such as WS-BEPL. They can be mapped to otherprocess description languages.

5.7 SOA quality attributes

Quality is an important requirement for software architec-tural design as well as ESOA system design. Therefore theSOA quality attributes SQ are the rationale for the variouschoices and alternatives in realizing ESOA in enterprise. TheQoS and SLA are based on the quality attributes. In model

123

94 SOCA (2010) 4:81–107

Fig. 11 Service choreographyexample

sd Cho Global Vi...

Buyer Seller PaymentService ShipService

alt ExceptionHandler

[InvalidCredit]

[validCredit]

par

requestQuote()

quoteResponse()

verifyCreditCard()

reject()reject()

requestShipping()

shippingDetail()

shippingDetail()

(3.1), SQ can be defined as a set of SOA quality attributesbased on [49]:

SQ = {I N , RE, AV, U S, SE, P E, SC,

E X, AD, T E, AU, O D, M O} (5.9)

For an EWS-* style ESOA, the SOA quality attributes arespecified and implemented by different service specifications[77]. Table 8 lists part of specifications which relate to SOAquality attributes in EWS-* style system.

Table 8 lists all attribute names and status. The “Status”column refers to the level of maturity of SOA in that area.The green color indicates that there are known solutions forthe SOA based on relatively mature standards and technol-ogies. The yellow color indicates that some solutions existbut need further research to prove their usefulness in han-dling the requirements for the quality attribute. The red colorindicates that the standards and technologies are immatureand further significant effort is required to fully support thequality attribute within an SOA. Detailed descriptions can befound in [49].

5.8 Relationship of parts of EWS-* style

Section 5 has specified common structure, behavior and con-straints of all EWS-* style parts in the generic model (3.1)and discussed some of their relationships. Sections 5.1 and5.2 discussed the relationships between service consumerand services. The consumer, typically a web service client

application, requests services that serve its request. One canalso connect service-level quality attributes to SOA qualityattributes (SQ). Sections 5.5 and 5.6 discussed the relation-ships among SOA Management (SM), SOA processes (SP)and SOA quality attributes (SQ). Figure 12 shows the over-all relationship for EWS-*. All EWS-* parts and their con-straints are formally and informally described from Sect. 5.1to 5.7. Each part in Fig. 12 is described by typical elementsin enterprise or some of graphics, such as web services. Forexample,

C = {Portal, Thin Client, Fat Client, Wireless Client}

This section discussed the relationship of all parts describedin Fig. 12. The services (S) are registered in service regis-try of SOA Infrastructure (SI) and they are represented byusing SOA metadata and data (D). Consumers (C) requestservices through the service discovery and communicationchannel, such as Enterprise Message Bus (ESB) providedby SI. The orchestration and/or choreography of ServiceProcess (SP) consist of a set of services in S, which are man-aged and controlled by SOA Management (SM). Moreoverthe SM also manages SI, S and C. SM security and policymanagement and system management rely on SOA QualityAttributes (SQ). The monitors in SM are monitoring C, SI, Sand SP. The quality attributes and constraints based on themin SQ are applied to all other parts. The D is used by all otherparts.

123

SOCA (2010) 4:81–107 95

Table 8 EWS-* SOA qualityattributes

Quality attribute (abbreviation) Web service specifications Status

Interoperability (IN) WS-I Profiles Green

Reliability (RE) WS-Reliability Yellow

WS-ReliableMessaging

Availability (AV) No direct specification Yellow

Usability (US) WSDL Yellow

Security (SE) WS-Security Red

WS-Trust

Performance (PE) WS-Transaction Red

SOAP Message TransmissionOptimization Mechanism

XML-binary Optimized Packaging

Scalability (SC) Web Service Management Foundation Yellow

Extensibility (EX) WSDL 2.0 Green

Adaptability (AD) No direct specification Yellow

Testability (TE) No direct specification Red

Auditability (AU) No direct specification Red

Operability and Deployability (OD) WSDL, WS-BPEL, WS-CDL Yellow

Modifiability (MO) WSDM-MOWS,WS-ResourceMetadataDescriptor

Green

Fig. 12 ESOA model for EWS-* style

123

96 SOCA (2010) 4:81–107

6 Comparison of ESOA styles

This section compares the major ESOA styles. The EEDAand EGSA are based on traditional web services in Tables 9and 10, which means the services in EEDA are web servicesand the services in EGSA are extension of web services. Weshow an informal comparison of major quality attributes forall five major ESOA styles in Table 9 in which “-” means low,“- -” means much less, “- - -” means dramatically lower, “+”means average, “++” means high and “+++” means dramati-cally higher. We discuss each of quality attributes as follows:

• Performance: the performance of SOAP web servicein enterprise is challenging because of its heavyweightnature and large XML payload. In general, the ser-vices in EEDA are inefficient [64]. To access webresources, EWOA is more efficient than traditional webservices because of its cache feature. Since EGSA’s SOAGrid infrastructure enables middle-tier caching layer, itenhances web service performance [10].

• Transaction: the ACID (atomicity, consistency, isolation,durability) transactions that span multiple applicationsare important for enterprise. EWS-* and other web ser-vice based styles are addressed by WS-AtomicTrans-action which relies on WS-Coordination specification.ECBS, such as stateless EJB service model, also han-dles transaction well. EWOA is not good enough to han-dle ACID transaction, because of its resource-orientednature.

• Interoperability: it is one of the main goals of web ser-vices. WS-I profile addresses web service interoperabil-ity. However, cross-vendor interoperability of traditionalweb services (like EWS-*, EEDA, EGSA) is not perfect(only “+”). The interoperability of ECBS is not as good asother styles, since its components are less standardized.EWOA interoperability is based on web principles [20].

• Scalability: The tier-based ESOA architecture, such as theEWS-* and ECBS architectures, with traditional middle-ware, does not scale linearly and does not allow appli-cations to scale on-demand. The EWOA architecture hasbetter scalability than traditional web service SOA archi-tecture because of web scalability nature, cache adop-tion and unified interfaces. However, its scalability is alsonot dynamic and linear. The EEDA also improves thescalability of traditional SOA, because of event-drivenasynchronous nature. The EGSA can provide predictableand truly linear scalability, because grid computing canhelp ESOA system to improve the scalability bottlenecksacross SOA parts [10].

• Security: the security of EWOA is based on HTTP secu-rity features and Security Socket Layer (SSL). The ECBSsecurity is not only based on HTTP security and SSL, butalso based on component security standards, such as J2EE

security standards. Other styles based on web servicesprovide more security capacities through WS-* securityspecifications [77], such as WS-Security, WS-Trust andWS-SecureConversation.

• Availability: Unlike other styles using redundancy tech-nology for high availability, the EGSA uses SOA Gridto achieve extreme high availability. SOA grid can pro-vide continuous availability and reach 100% active-active server failover. It can also prevent single points offailure and enable automatic service load distribution anda full-range of QoS levels for stateful services and ser-vice orchestration. In addition, it can increase throughputand self-healing management as well as SLA enforce-ment.

• Reliability: EWOA has less reliability since the style doesnot address many enterprise challenges through stan-dards. The styles based on web services are of higherreliability by implementing WS-* reliability specifica-tions, such as WS-ReliableMessaging.

• Simplicity: EWOA is the simplest style of the five styles,since it is protocol dependent and its RESTful web ser-vices have unified interfaces and its infrastructure is builton existing web infrastructure [63]. Therefore it is calledlightweight SOA. EWS-* is more complex than EWOAand ECBS, because it is protocol independent and basedon complicated multiple specifications [77]. EEDA ismore complicated than EWS-* because of its event pro-cessing and its real-time environment. EGSA is the mostcomplex due to its complicated grid environment, state-ful web services and the complexity of managing statesin SOA applications.

• Flexibility: The ECBS is less flexible than other stylessince it is not based on common standards and relativelytight couplings. EEDA and EGSA are more flexible sincethe event processing is added to EEDA SOA and flexiblegrid computing infrastructure with predicable scalabilityand continuous availability.

• Business Agility: The ECBS has less business agility thanother styles because of its relatively tight coupling.

• Resource Manageability: The resource manageability ofEGSA is the best since the grid computing brings max-imum resource utilization, such as virtualization, intoESOA architecture.

• Consciousness: All ESOA styles guide building enter-prise service-oriented nervous systems. However most oftraditional styles systems, like EWS-*, EWOA and ECBSsystems, are comatose, meaning they are unaware of theirsurroundings. They cannot independently act on condi-tions without instruction from central controller or the aidof human administration. However EDA of EEDA bringsconsciousness into the enterprise SOA nervous systems.With the right mix of smart event processing and rules,the EDA enables the ESOA system to consciously react

123

SOCA (2010) 4:81–107 97

Table 9 Major qualityattributes comparison

SOA Quality Attributes (SQ)

Style EWS-* EWOA EEDA ECBS EGSA

Performance - + - + +

Transaction ++ - ++ ++ ++

Interoperability + + + - +

Scalability + ++ ++ + +++

Security + - + + +

Availability ++ ++ ++ ++ +++

Reliability ++ + ++ ++ ++

Simplicity - ++ - - + - - -

Flexibility + + ++ - ++

Business agility + + + - +

Resource manageability + + + + +++

Consciousness - - +++ - +

Loose coupling ++ ++ +++ - ++

to internal and external conditions that affect the businesswithin a real-time context [64].

• Loose coupling: EEDA is the most loosely coupled archi-tecture because of its event-driven nature and asynchro-nous communication protocol [64].

Table 10 compares five main ESOA styles, which includeEWS-*, ECBS and Hybrid styles in this paper and EWOAin [63]. The service is the core of all styles. The main differ-ence between EGSA service (Grid service or WSRF service)and the services of other styles is that WSRF service is state-ful whereas the services of other styles are stateless. TheWSRF service consists of a stateless web service and a state-ful resource with unique key [48]. Adopting stateless or state-ful services in both academia and industry has been debatedfor many years. On one hand, stateless services scale betterand more fault-tolerant. On the other hand, stateful servicescan be more efficient and support continuous availability, asthe services’ states are stored in a stateful resource. More-over recent technology, such as virtualization, makes statefulservices (WSRF or Grid) scale dynamically, so that they canprovide the new capacity of building dynamic IT infrastruc-ture and meet enterprise business requests on-demand [10].The hybrid style with both stateless and stateful services willbe adopted by most service-oriented enterprises as designguidance of their ESOA systems.

7 Case studies

This section analyzes several enterprise systems in order toshow if they meet the ESOA model specified in this paper. For

an enterprise system to meet the ESOA model requirement,the system needs to satisfy the following conditions:

(1) The structure and behavior of EA satisfy the enterpriseservice orientation formula (3.1)

(2) EA is an instance of any of the following styles:

◦ EWS-* style;◦ EEDA style;◦ EWOA style;◦ ECBS style;◦ EGSA style and◦ Hybrid style.

(3) The core services in EA satisfy the service propertiesdefined in Sp.

We define that an Enterprise Architecture (EA) is an instanceof ESOA if it satisfies the above conditions. An EA evalua-tion form is designed for evaluating the following differententerprise architectures.

This section chooses five concrete EA for case studies.Section 7.1 is a traditional EAI integration architecture basedon Gartner Research [29]. We show it is not an instance ofESOA. Section 7.2 is a typical EA of ESOA hybrid style withEWS-* and ECBS. Section 7.3 shows an EA, similar to theEA in Sect. 7.2, is not an instance of ESOA if it lacks SOAmanagement and security components in design. Sect. 7.4shows an EA based on open source ESOA is an instance ofESOA. This will help architects to make decisions on choos-ing open source as ESOA building blocks. Finally, Sect. 7.5shows an EA built on IBM ESOA products can be an instanceof ESOA. It can help architects to make right decision on

123

98 SOCA (2010) 4:81–107

Table 10 Comparison of Parts and their Constraints of ESOA Styles

Style Services (S) Consumers (C) SOA Data(D)

SOA Infrastructure(SI)

SOA Management (SM)

SOA Process (SP)

EWS-* • SOAP-based web services• Machine-processable description

of services, such as WSDL• Machine-processable description

of composition of services, such as BPEL

• Address challenges by WS-* specifications

• StandardsWS-*[77]

• Application protocol -SOAP• Transport protocols HTTP,

TCP, SMTP, JMS,MQ,IIOP• Different applications expose

different interfaces• Contract-first and contract-last• Both RPC-style and messaging

communication• Both Request-response and one-

way• Request/action driven• Both synchronous and

asynchronous service invocation• Stateless

• Web service client applications

• Web applications

Table 4 Section 5.4 Section 5.5 • Web service orchestration • Web service chorography• Process coordination

scheduler required • Process is triggered by

consumer

EWOA • RESTful web service• Need to model system as

resources• Not all challenges are tackled• Web standards [20]• Application protocol HTTP• Transport protocol HTTP• Different applications expose its

resources through the same interfaces: GET,POST,PUT and DELETE [63]

• Contract-less• REST-style communication• Request-response• Request or action driven• Both synchronous and


• Web applications• Customers or users

who interact with services, such as Wiki, directly. [11]defines this kind of SOA as Consumer-Centric SOA (CCSOA) or User-Centric SOA (UCSOA).

• Resources• Resource

metadata• Resource

representation• Resource

identifier• Service

description• Configuration

data

• Web servers• Web proxy servers• Load balancer• DNS• Gateway• Web container• Server connector• Cache

• RESTful WS registry

• Firewall server• Single Sign On

security manager• Logging service• System monitor

• RESTful web service orchestration, such as Mashup

• Lack of standard• Not support chorography

EEDA • Traditional SOA and Web services

• EDA web services• Standards:

WS-Eventing [72]• Both synchronous and

asynchronous

• Traditional WS client applications

• EDA applications

• Traditional SOA data

• EDA data• Event

metadata

• Traditional SOA infrastructure

• Traditional SOA message infrastructure with pub/sub message queues (ESB)

• EDA infrastructureGlobal Event Listeners

• Traditional SOA management

• EDA events system management

• Event-Driven Web service orchestration support both traditional orchestration and publish/subscribe (EDA style)

• Events-Driven Web service

service invocation• Event-Driven• Support real-time business• Stateless

Global Event ProcessorsGlobal Event ProducersComplex Events Processing (CEP)

chorography• Support both scheduled

and unscheduled process coordination

• Process is triggered by consumer or producer

ECBS • Component-based Services• RPC-style, such as RMI

communication• Standards:

Service Component Architecture standards [44]Java Business Integration [65]

• Request-response• Request or action driven• Both synchronous and


• Web client applications

• Desktop applications

• Wireless client application

• Traditional component data

• Service component metadata

• Policy data• Configuration

data

• Traditional SOA infrastructure

• Traditional component infrastructure


• Traditional component-based management

• Security management (SSO, ACL)

• Performance management

• Component service orchestration

• Component service chorography

• Process coordination scheduler required

• Process is triggered by consumer

EGSA • Grid Web services-extension of traditional web services

• Standards: WS-Resources [48]WSRF [48],OGSA[27],OGSI[50]

• Request-response• Request or action driven• Stateful

• Web service client applications

• Grid client applications

• Traditional SOA data

• Grid data• Web service

resource properties

• WSRF Specification

• Grid service registry data

• Policy data• SLA data

• SOA Grid infrastructure• Grid-enabled

middleware• Grid-enabled ESB• Grid service registry• Scheduling service• Job-submit service

• Data grid• Enterprise Data Bus• Visualization resources


• Grid management• State management• SLA management• Grid resource

management• Self-management

• Grid Web service orchestration

• Grid Web service chorography

123

SOCA (2010) 4:81–107 99

Fig. 13 TraditionalEAI—spaghetti-like architecture

evaluating and selecting vendor’s products when designESOA systems.

7.1 Traditional EAI

Figure 13 depicts a traditional EAI—Spaghetti-like enter-prise architecture [29]. It is easy to see that the enterprisearchitecture does not satisfy conditions (1), (2) and (3). Thus,it is not an ESOA style architecture. Table 11 specifies whytraditional EAI is not an instance of ESOA.

Traditional EAI was attempted to solve enterprise integra-tion, such as application integration and business to businessintegration (B2B). However, it failed to deliver its promiseand resolve some business issues. The lessons learned fromtraditional EAI are as follows.

• A data centric EAI approach is not good enough for enter-prise architecture which needs to serve complicate busi-ness process. That is why SOA process is one of mainparts in the ESOA style.

• Tight coupling leads to hard to maintain enterprise sys-tems. Loose coupling is a way to increase business agility.

• ESOA is a better way for enterprise application integra-tion.

7.2 Hybrid ESOA system

Figure 14 describes the typical concrete enterprise architec-ture (CEA). This example assumes that stateless EnterpriseJava Bean (EJB) Version 3 is chosen as the internal businessservice component for internal customers and its wrapperof SOAP-based web service as external business service for

Table 11 Evaluation form for traditional EAI

EA evaluation form

Condition Satisfy Rationale

(1) No Not service oriented, but application oriented

(2) No • Traditional EAI style.

• Complex application infrastructure

(3) No • Tight coupling between applications.

• Hard to change and adapt to business needs.

• Poor scalability.

• Security is not well addressed.

external customers; either Weblogic 10.3 or WebSphere 6.1 ischosen as the application server; either BEA System’s Aqua-logic Service Bus or IBM ESB is chosen as the EnterpriseService Bus (ESB); and Apache Tuscany is chosen as ser-vice component process engine. The EA is adopted by someenterprises whose traditional EAI is based on SUN J2EE andhas many existing J2EE applications and services [23].

Table 12 shows the EA is an instance of ESOA with hybridstyle.

In Table 12, the parts of the EA can be defined in detail asfollows:

SC E A = {s | s is a stateless Java session EJB or a Message-Driven EJB or SOAP-Based Web Service}

CC E A = {Inside Services Clients, Outside ServicesClients}

DC E A = {Server metadata, EJB metadata, Web serverconfiguration data, Application server configura-tion data, ESB configuration data}

123

100 SOCA (2010) 4:81–107

Table 12 Evaluation form of a hybrid ESOA System

EA evaluation form


(1) Yes E AC E A = ⟨SC E A, CC E A, DC E A, SIC E A,

SMC E A, S PC E A, SQC E A⟩

(2) Yes Hybrid of EWS-* style and ECBS style

• Evaluation Form of a Hybrid ESOASystem ESB for exposing web serverinterfaces to outside service consumers:EWS-* style

• Application server for exposingcomponent-based server interfaces toinside service consumers: ECBS style

(3) Yes Detail rationalization is specified in lastpart of the subsection.

SIC E A = {Web server infrastructure, Application serverinfrastructure, ESB}

SMC E A = {Application Server Management, ESB Manage-ment, Monitors, Security Management, NetworkManagement}

SPC E A = {EJB-based component workflows} ∪ {SCA-based service process}

SQC E A = {Performance, Scalability, Reusability, Relia-bility, Security, Maintainability}∪Sp

One just needs to verify if the EJB-based core services satisfycondition (3).

• Standard Service Contracts – stateless session EJB usesremote and local EJB interfaces of the component-basedcontracts. The message-driven EJB provides an onMes-sage interface for asynchronous client’s interaction. If allEJB services are designed with enterprise standard inter-faces, then the core EJB services have standardized ser-vice contracts. We will discuss how to specify standardEJB interface in an EJB-based service inventory in anenterprise in our future work.

• Reusability – unlike a public web service, such as theweather service, which has a universal reusability, EJB isa reusable Java component in enterprise business domain.

• Relative Autonomy – An EJB can perform its work inde-pendent of most of the other components or applications.However, an EJB must be executed inside an EJB con-tainer. Therefore EJB has service-level and contractualautonomy, rather than pure autonomy.

• Statelessness – both stateless sessions EJB and message-driven EJB are stateless.

• Discoverability - EJB uses JNDI (Java Naming DirectoryInterface) for locating home interfaces, business methods,and metadata. Therefore it can be dynamically discover-able.

Fig. 14 An enterprise architecture

Table 13 Evaluation of the incomplete ESOA System

EA evaluation form


(1) Partial Without security and monitoring inenterprise architecture, itsinfrastructure and services as well astheir processes do not satisfy theSOA Management (SM) defined in(2.1) and Section 2.5.

(2) Yes Hybrid style

(3) Partial • Moreover without securitymanager, the architecture does notsatisfy the architecture securityattribute;

• Without system monitors in anenterprise architecture, there is noway to detect failures of serviceand infrastructure and to measureperformance of services andprocesses.

• Relative Loose coupling – in the concrete EA, thecore services are wrapped by public services interfacesexposed to outside service consumers. From the view ofan outside client, they are loosely coupled. However theyexpose the services to inside service consumers becauseEJB plus Remote Method Invocation (RMI) are coupledat both its Java language and platform. The message-

123

SOCA (2010) 4:81–107 101

Table 14 Evaluation of FUSE ESB ESOA Architecture

EA Evaluation form


(1) Yes The ServiceMix [56] is built based on SUN’s JBIspecification [65]. Its core includes theServiceMix Enterprise Service Bus (ESB)based on JBI Normalized Message Route(NMR) and an OSGi-based ServiceMix Kernel.It is not only an ESB, but also provides aJMX-based SOA management and many otherenterprise capabilities, such as ActiveMQ forsupporting EDA, Apache ODE BPEL engine asa drop-in JBI component for ServiceMix.Therefore the ServiceMix-based architectureSMA in Fig. 15 satisfies the service orientedformula:

E ASM A = 〈SSM A, CSM A, DSM A, SISM A, SMSM A,

S PSM A, SQSM A〉(2) Yes ServiceMix combines the functionalities of SOA

and EDA, as well as supports multiple types ofservices; therefore SMA is a hybrid system with

• EWS-* style

• EEDA style

• ECBS style

(3) Yes • A subset of WS-* specifications aresupporting through ServiceMix’s bindingcomponents as listed in Table 15.

• ServiceMix supports SOA security, reliability,manageability and transactionability throughsupporting WS-* specifications. Moreover itsupports clustering and load balancing throughmultiple ServiceMix instances communicationvia JMS using ActiveMQ. It also can uselightweight cache binding component forimproving SOA performance.

• The web services in EWS-*, EEDA and ECBSstyles satisfy the service properties definedinSp .

driven EJB supports loose coupling at the service-levelby its asynchronous messaging. The stateless session EJB(before EJB 3.0) is also tightly coupled with its clients tocertain degree through RMI stub. However the couplinghas been improved by EJB 3.0. Moreover the dependencyinjection supported by EJB 3.x also greatly reduces thecoupling between EJB components and infrastructure.Through adopting group services versioning and the “unitof deployment” for services and service consumers, thetight coupling will benefit execution performance. There-fore one can say the design of core services of the EAachieves certain degree of loose coupling.

• Abstraction – EJB specification abstracts the non-essential service information through several types ofmeta abstraction which are defined in ejb-jar.xml foreach EJB. The annotation metadata model is introducedin the newest EJB 3.0. The container managing the

Fig. 15 FUSE-ServiceMix for ESOA style architecture

transaction behaviors is hidden by the tag <container-transaction>. The QoS policy, such as performance(pool size) and security (run-as-identity-principle), canbe defined in EJB meta XML files.

• Composability – Software component is composable bydefinition [35]. EJB is a Java-based component, therefore,in nature, it can be composable with other components,such as other EJBs, for executing a business process, suchas workflow and transaction.

In conclusion, the EA described in Fig. 14 is an instance ofhybrid ESOA. From the case study, it is clear that the hybridstyle’s core style is ECBS based on components (such as EJBand .NET). It may have tightly coupled API and thus mayhave to be tightly controlled. Thus, the style is still inflexibleand hard to scale. Although the component services are onlyused for internal consumers, and other technologies, such asversioning and the “unit of deployment”, can reduce the badeffort from tight coupling, the maintainability and agility areimpacted. The adoption of the style is based on performanceconsideration and existing EAI systems for some enterprises.

7.3 An incomplete ESOA system

If two important components–security and monitor—areremoved from the EA in Fig. 14 by design, the EA becomesan incomplete ESOA system. Table 13 specifies the incom-pletion of the EA. The architecture does not satisfy the archi-tecture quality attributes reliability and performance (part ofQoS policy) defined in (3.1) and Sect. 5.7. Therefore thearchitecture does not satisfy ESOA QoS policy.

If the core services use stateful EJB, then they also vio-late the “statelessness”—one of service properties defined inSect. 5.1. Therefore the EA is not a complete ESOA system.

123

102 SOCA (2010) 4:81–107

Table 15 WS-* specificationfor ServiceMix

WS-* Spec Purpose Supported by ServiceMix

WS-Security Authentication, Encryption, DigitalSignature

Yes, for HTTP and CXF (An opensource service framework) bindingcomponents and subsequentauthentication/authorization

WS-RM Reliable Messaging Yes, for CXF binding component

WS-Address Addressing Yes, for HTTP, JMS (Java MessageService) and CXF bindingcomponents

WS-Policy Policy management Yes, for CXF binding component

WS-Notification Events Yes

WS-TX Transaction No, though WS-TX headers can bepassed through as normalizedmessage headers for services tohandle

WSDM Management No, JMS is used instead

WS-Management Management Not directly, JMX (Java ManagementExtensions) is used instead; abridge from JMS toWS-Management is beingdeveloped.

Table 16 Evaluation of IBMSOA-based architecture

EA Evaluation form


(1) Yes The EA can be represented in the enterprise service orientation for-mula (2.1) based on Fig 16 and [1]:

E AI B M = 〈SI B M , CI B M , DI B M , SII B M , SMI B M ,

S PI B M , SQI B M 〉(2) Yes IBM Enterprise SOA solutions and products support service loose

coupling and event-driven architecture through mediation, such asESB, and messaging, such as MQ; they also support RESTful webservices through provisioning Web 2.0 Feature Pack; they alsosupport SCA through provisioning SCA Feature Pack. Thereforean EA based on IBM ESOA can have multiple ESOAstyles—EWS-*, EWOA, EEDA and ECBS.

(3) Yes • IBM Enterprise SOA Application Architecture is built on SOAprinciples. Many non-functional requirements (or SOA qualityattributes) are considered when designing IBM SOA products,such as WebSphere, and other products. Therefore it canguarantee an EA built on IBM SOA solution to reach its QoS andSLA goals. Table 17 shows how IBM SOA solution meets theenterprise SOA quality requirements Table 17.

• Moreover the services satisfy the service properties defined in Sp .

However, this system can be changed so that it will be qual-ified as an ESOA by adding those missing components andattributes.

From the case study, the proposed ESOA style model ishelpful not only in understanding ESOA, but also in analyz-ing and evaluating SOA enterprise architecture, and findingthe missing parts in an ESOA system. Moreover the nextsection shows that the ESOA style model and its instance

enterprise ESOA style architecture defined in this paper canhelp enterprise architects to make decision on adopting theright open source products in building ESOA architecture.

7.4 FUSE ESB for ESOA architecture

This subsection shows that the open source FUSE ESB prod-ucts based on Apache ServiceMix can be used for building

123

SOCA (2010) 4:81–107 103

Fig. 16 EA Built on IBM SOA products

ESOA architecture by using the model and style analysis pro-posed in this paper. Table 14 specifies the characteristics ofthe ServiceMix-based architecture (SMA).

Based on SMA as shown in Fig. 15, one can define theparts of SMA in Table 14:

SSM A = {s | s is a stateless Java session EJB or a Message-Driven EJB or SOAP-based Web Service, RESTfulWeb Service}

CSM A = {Internal Services Clients, External ServicesClients}

DSM A = {Web server infrastructure data, Application serverconfiguration data, ESB configuration data, jmx.xml,file-poller-su, eip-wiretap-su, camel-persist-su, eip-cbr-su, jms-producer-su, …}

in which all *-su are configuration XML files for service unitwhich provide information of the service and their endpointsto the component.

SISM A = {Web server infrastructure, Application serverinfrastructure, ESB}

SMSM A = {Service life-cycle management, Service Pol-icy Management, Monitors, Security Management,Network Management}

S PSM A = {ODE-based service process}∪ {SCA-based ser-vice process}

SQSM A = {Performance, Scalability, Reusability, Reliabil-ity, Security, Transactionability, Scalability, Man-ageability, Interoperability}∪Sp

Table 17 IBM SOA quality attributes

SOA quality attributes IBM solutions & Products

Performance WebSphere DataPower,

Performance Monitoring

Provisioning enhancements of

Web Service and EJB 3.0

Scalability WebSphere eXtreme Scale

Security Tivoli Identity Manager

WebSphere Security Management

WebSphere ESB

Interoperability WebSphere Interaction Service

WebSphere MQ

WebSphere ESB

Reliability WebSphere eXtreme Scale

Workload management

Reliable messaging

Availability Failover

High-availability clustering

On-demand routing

Workload management controller

Transactionability WebSphere Process Service

Workflow management

Manageability WebSphere Informantion service

Tivoli Monitoring

Tivoli Infratructure Management

WebSphere ESB

Maintainability WebSphere Adminitraction Services

IBM SOA lifecycle management

Testability WebSphere Test Envirnmrnt & tools

Therefore based on the evaluation of ServiceMix-based EA,such as SMA in Fig. 15, the system is an instance of ESOA.However, because the ServiceMix supports only a subset ofWS-* specifications together with limited management andSOA process, it can be used for creating agile and lightweightESOA system for small or middle size service orientationenterprises.

7.5 Enterprise systems based on IBM WebSphere

Many SOA solution providers, such as IBM, SAP, Oracle,and Microsoft, have developed their SOA models and prod-ucts for building service-oriented enterprise, such as IBMWebSphere [1,24], SAP NetWeaver [67,11], Oracle FusionMiddleware [51] and Microsoft WCF as well as its products[3]. It is easy to show that the enterprise architecture basedon any one of them is an instance of ESOA. For example,Fig. 16 illustrates an enterprise system built on IBM SOAapplication architecture is an instance of hybrid style.

123

104 SOCA (2010) 4:81–107

Table 16 describes main characteristics of IBM SOA-based application architecture.

In Table 16, the parts of the EA can be described in detailas follows:

SI B M = {s | s is a Component-based service, SOAP-basedWeb Service, RESTful Web Service, or Event-Based Service}

CI B M = {Web client, event-based client, offline client,web service client}

DI B M = {Web server infrastructure data, WebSphereserver configuration data, WebSphere Servicemetadata, WebSphere policy data, WebSphereProcess Execution Rules}

SII B M = {Web server infrastructure, WebSphere infra-structure,WebSphere ESB,WebSphere MQ,Web-Sphere Service Registry,WebSphere ServiceIntegration Bus}

SMI B M = {IBM Service life-cycle management, IBM Ser-vice Policy Management, Tivoli Monitors, Web-Sphere Business Monitor,WebSphere SecurityManagement,Tivoli Identity Management,IBMSOA Connectivity Management,WebSphereProcess Server}

S PI B M = {WS-BPEL based process}∪ {SCA-based ser-vice process}

SQI B M = {Performance, Scalability, Reusability, Reliabil-ity, Security, Transactionability, Scalability,Manageability, Testability,Interoperability, Main-tainability}∪Sp

In conclusion, IBM SOA-based EA is an instance of hybridESOA. From the case study, it is clear that

• IBM as an ESOA product vendor can provide a pack-age of products from services, SOA data, service infra-structure, service management to SOA quality of service.Therefore IBM can be chosen as a vendor for building anESOA system.

• The advantage of a single vendor approach, such asIBM’s, for building ESOA systems is that it is easy tomanage and maintain the systems because of high com-parability among ESOA parts. However a single vendormay not guarantee that every product is the best in themarket in pricing and quality, so some large enterprisesprefer building ESOA systems based on diversifying ven-dor products, such as choosing Weblogic as applicationserver and Wily product as application monitor.

8 Related work

The work presented in this paper is rooted in the fol-lowing three main research areas: (1) traditional software

architecture models and styles, (2) enterprise service-ori-ented architectural model and its styles which include theirformal as well as informal specifications and classifications,and (3) ESOA architectural evaluation.

A traditional software architecture model has been intro-duced in [54], which defines software architecture as Soft-ware Architecture = {Elements, Form, Rational}. Perry andWolf define architectural styles [54] based on this model.Shaw and Garlan define architectural style as “a vocabularyof components and connector types, and a set of constraintson how they can be combined.” [57]. Traditional architec-tural model and concepts of architectural style are funda-mental to our research on ESOA model and styles. Howevertraditional architectural style [54,57] is based on three mainparts in software architecture:

• Components (Elements - Perry/Wolf style)• Connector types• Constraints, such as a set of configuration rules.

They are not enough to specify modern complicated enter-prise service-oriented architecture. We define seven sets ofparts in (3.1) for specifying ESOA styles. The componentsare extended to services, consumers and SOA processes. Theconnector types are extended to SOA infrastructure whichincludes not only connector types, but also complicated loadbalancers, application servers, service bus and other networkfacilities. The set of constraints are extended to SOA man-agement (including configuration management) and SOAquality attributes. In our approach, the quality attributes asnon-functional constraints are applied to all other parts. Kleinet al. proposed the quality attribute-based architectural styles[30] which describe styles based on quality attributes. Ourapproach adapts their core idea and takes the quality attri-butes as constraints of ESOA styles.

The traditional Enterprise Application Integration (EAI)is an approach to integrated distributed systems. The ESOAare the extension and improvement of EAI as we discussed inSect. 7.1. This paper focuses on ESOA model and its styles.The triangle model of SOA presented in the literature is abasic SOA model [39]. It presents the interaction model ofthree parties in SOA. However, it does not provide specificfeatures in SOA or ESOA, for example, SOA Quality andSOA management.

The OASIS SOA Reference Model is an abstract frame-work which “defines the essence of SOA and emerges witha vocabulary and a common understanding of SOA” [45].The model is a conceptual SOA model that does not coverthe complicated ESOA architecture issues. Many SOA ven-dors, such as IBM [24], Microsoft [40], BEA [14] and Oracle[51] propose their specific SOA models. Butler [7] developeda SOA meta-model based on SAE UML profile. The SOA

123

SOCA (2010) 4:81–107 105

meta-model approach provides a vehicle to quickly beginusing the existing UML tools for visually depicting SOA.

Singh et al. propose an SOA model—Commitment-Based Service-Oriented Architecture (CSOA) in [58]. CSOAdefines components as business services and connectorsas patterns, modeled as commitments which support keyelements of service engagements. Although our approachfor modeling ESOA styles is very different from [58], theESOA specifies services as enterprise services which arebased on customers’ functional and non-functional require-ments. Moreover we consider quality attributes as constraintsof ESOA styles, which are similar to the CSOA commit-ments.

Various formal models [5,15,61] for services, serviceprocesses and software architecture have been developed.However the formal model for ESOA has not been defined.McGovern and Erl discuss various SOA and ESOA mod-els in [37,18] based on web services. In contrast to theseapproaches, this paper defines a tuple model for specify-ing ESOA. Although this paper used the traditional ESOA(EWS-*) as an example for defining the parts and exposingthe relationships in the model, as shown in Figs. 2 and 12,the proposed model (3.1) is a generic model which can covermany ESOA styles, such as EWS-* style ESOA, RESTful-style Web ESOA and next generation Grid-style ESOA (seeSect. 6), and the proposed model is independent of specificconcrete architecture, technology and vendors’ products. Theservices defined in the model (3.1) can be traditional webservices or other types of services, such as RESTful web ser-vices [63]. Therefore it is different from other SOA modelsand provides an overall picture of ESOA.

The proposed ESOA model is not a concrete archi-tecture, but a set of architectural parts, infrastructure andprinciples with different styles. Different concrete ESOAarchitectures can be derived from the model. We have alsospecified the EWOA style of ESOA in [63] based on the sim-ilar model. Another example is the ServiceMix [56] devel-oped by Apache discussed in Sect. 7. The investigations ofhigh assurance SOA-based systems [16,17] address the con-cerns of the assurance of multiple quality attributes, such asreliability, availability, performance, security and real-timeresponse, for a variety of critical applications.

Another characteristic of the proposed approach is that itcombines ESOA with quality attributes. A new methodol-ogy and model [11,67] for classifying SOA-based applica-tion architectures has been proposed based on the structure ofapplication, the runtime re-composition capability, the fault-tolerance capability, and the system engineering support.A classification on ontology and semantic web technologiesfor software development has been studied in [80]. Our modelin this paper focuses primarily on ESOA styles and theirquality attributes. Thus, it can be used for common under-standing of the whole ESOA and it can be helpful in analysis,

evaluation and design of concrete ESOA systems, as shownin Sect. 7. Finally model (3.1) does not specify any concreteESOA structure; instead, it is an abstraction of the structureand behavior of ESOA systems. The definitions (5.1–5.9)imply both structural and behavioral aspects. The SP and SQinclude their structural and behavioral aspects, respectively,which will be addressed in future work.

9 Conclusions

This paper proposed a model for ESOA, and specified theEWS-* substyle in terms of the model. Moreover this paperanalyzed and evaluated several ESOA style application archi-tectures. The contributions of this paper are:

1. Defining a classification of ESOA styles and the stylehierarchies.

2. Comparing ESOA styles based on the classification.3. Introducing a generic abstract model of various ESOA

styles. The model defines the 7-tuple form of ESOA, inwhich the elements are defined as a set of SOA archi-tectural parts, a set of SOA infrastructures, a set of SOAmanagement, a set of processes, and a set of quality attri-butes in (3.1):

• Services: they are the building blocks in any ESOA sys-tems.

• Service consumers: they are customers or customer fac-ing applications of enterprise business. Services shallprovide business and technical services for consumers.

• Data elements: Various representations and data will beused to specify services, workflows, and data used inESOA.

• Infrastructure: Enterprise services and providers mustbe supported by ESOA infrastructure for guaranteeingQoS.

• Management: Enterprise services must be managed andcontrolled by SOA management services based on Ser-vice Level Agreement (SLA).

• Processes: Enterprise services shall be capable of exe-cuting business processes and workflows.

• Quality attributes: Enterprise services and their sup-ports as well as management shall satisfy both functionaland non-functional requirements.

In terms of EWS-* substyle, we then formally define andinformally describe each part in (3.1) as well as provide arelationship view of the model in Figs. 2 and 12.

1. Specifying the EWS-* style in terms of the tuple model.2. Defining the instance of ESOA style based on the pro-

posed model, analyzing and evaluating (1) a concrete

123

106 SOCA (2010) 4:81–107

ESOA style architecture for finding missing parts in anESOA system and (2) open source SOA application archi-tecture for helping to make architecture design decisionon using open source (3) EA based on IBM enterpriseSOA solutions and products for proving vendor’s SOAsolutions and products.

3. Specifying an ESOA substyle Web-Oriented Architec-ture in [63] based on the proposed model.

4. Providing an informal comparison of five main ESOAstyles.

The model proposed in this paper can be used for model-ing various ESOA systems. Thus, it provides new insightson how ESOA style—principles, structure and behavior—are defined. The defined ESOA style instance can be used asa methodology for analyzing and evaluating concrete enter-prise architectures, providing ESOA architects an analysisand evaluation methodology of ESOA application architec-tures.

Future research work includes:

• Developing model application, such as specifying andanalyzing other ESOA substyles, such as EEDA andEGSA.

• Building the formalism of ESOA quality attributes andservice properties.

• Developing a lightweight ESOA style and its model.• Developing methodology for designing ESOA style

architecture.

References

1. Agopyan A, Huebler H, Puah T, Schalze T, Vilageliu DS, Keen M(2009) WebSphere application server V7: concept, planning, anddesign. IBM Redbook, Feb 2009

2. Arora S (2005) Business process management, process is the enter-prise. LuLu Publish, Raleigh

3. Bahree A, Cicoria S, Mulder D, Pathak N, Peiris C (2007) ProWCF: practical microsoft SOA implementation. Apress, New York

4. Baresi L, Heclel R, Thone S, Varro D (2003) Modeling andvalidation of service-oriented architectures application versusStyle. ESEC/FSE’03, Sept 1–5

5. Broy M, Kruger IH, Meisinger M (2007) A formal model of ser-vices. ACM Trans Softw Eng Methodol 16(1):Article No. 5

6. Burke B, Monson-Haefel R (2006) Enterprise JavaBeans 3.0,O’Reilly

7. Butler J (2008) Creating a UML profile from the CBDI SAE metamodel. CBDI Journal, Jan 2008

8. Cakic J, and Paige RF (2006) Origins of the grid architectural style.In: Proceedings of the 11th IEEE international conference on engi-neering of complex computer systems

9. Chappell DA (2004) Enterprise service bus. O’Reilly, Sebastopol10. Chappell D, Berry D (2008) Next-generation grid-enabled SOA:

not your MOM’s bus. SOA Magazine, Issue XIV

11. Chen Y, Tsai WT (2008) Distributed service-oriented softwaredevelopment. Kendall Hunt Pub Co

12. Chung J-Y, Lin KJ, Mathieu RG (2003) Web services comput-ing—advancing software interoperability. IEEE Comput. 35–37,October 2003

13. Curbera F, Mukhi N (2003) Metadata-driven middleware for webservices. WISE 2003, Proceedings of the Fourth International Con-ference, 10–12 Dec, pp 278–283

14. Davies J (2007) SOA: BEA. Apress, New York15. Decker G, Puhlmann F, Weske M (2006) Formalizing service inter-

actions. LNCS 4102, pp 414–41916. Dong J, Paul R, Zhang L-J (2008) High assurance service-oriented

architecture. IEEE Comput 41(8):22–2317. Dong J, Paul R, Zhang L-J (2009) High assurance services com-

puting. Springer, Berlin18. Erl T (2005) Service-oriented architecture. Pearson Education,

London, UK19. Erl T (2008) SOA Principles of Service Design. Prentice Hall,

Englewood Cliffs20. Fielding RT (2000) Architectural styles and the design of network-

based software architectures, PhD Thesis. University of California,Irvine

21. Gall Nick (2008) Why WOA vs. SOA Doesn’t Matter? http://www.itbusinessedge.com/item/?ci=47620&sr=1

22. Guidi C, Lucchi R (2007) Formalizing mobility in Service OrientedComputing. J Softw 2(1):1–13

23. Gorton I, Liu A (2005) An architects’ guide to enterprise applica-tion integration with J2EE and .NET. In: Proceedings of the inter-national conference on software engineering, ICSE, pp 726–727

24. High R, Kinder S, Graham S, IBM’s SOA Foundation: AnArchitectural Introduction and Overview, http://www.ibm.com/developerworks/webservices/

25. Huhns MN, Singh MP (2005) Service-oriented computing: keyconcepts and principles. IEEE Internet Comput 9(1):75–81

26. Josuttis Braunschweig NM (2008) SOA in Practices. O’ReillyMedia, Inc, Sebastopol

27. Karasavvas K, Antonioletti M, Atkinson M, Hong NC, Sugden T,Hume A, Jackson M, Krause A, Palansuriya C (2005) Introductionto OGSA-DAI services. LNCS 3458:1–12

28. Keen M, Bond J, Denman J, Foster S, Husek S, Thompson B,Wylie H (2005) Patterns: integrating enterprise service buses in aservice-oriented architecture. IBM Redbooks

29. Klein J (2001) Architecture for HIPAA Compliance, Gartner Sym-posium ITxpo (Gartner Research)

30. Klein MH, Kazman R, Bass L, Carriere J, Barbacci M, andLipson H (1999) Attribute-Based Architecture Styles. IFIPConference Proceedings, vol 140:225–244

31. Kopecky J, Vitvar T, Bournez C, Farrell J (2007) SAWSDL: Seman-tic annotations for WSDL and XML Schema. IEEE Internet Com-put 11(6):60–67

32. Laliwala Z, Chaudhary S (2008) Event-driven service-orientedArchitecture. Serv Syst Serv Manag, pp 1–6

33. Lee J et al (2008) Integrating service composition flows with userinteractions. In: Proceedings of IEEE service-oriented system engi-neering, pp. 103–108

34. Leymann F (2006) Choreography for the Grid: towards fittingBPEL to the resource framework. Concurr Comput Pract Exp18(10):1201–1217

35. Liang D (2006) Servicetizing User Experiences for Complex Busi-ness Application. In: Proceedings of IEEE service-oriented systemengineering, pp 147–155

36. Martin D, Burstein M, McDermott D, McIlraith S, Paolucci M,Sycara K, McGuinness DL, Sirin E, Srinivasan N (2005) Bring-ing Semantics to Web Services: The OWL-S Approach. LNCS3387:26–42

123

http://www.itbusinessedge.com/item/?ci=47620&sr=1

http://www.itbusinessedge.com/item/?ci=47620&sr=1

http://www.ibm.com/developerworks/webservices/

http://www.ibm.com/developerworks/webservices/

SOCA (2010) 4:81–107 107

37. Mcgovern J, Sims O, Jain A, Little M (2006) Enterprise serviceoriented architecture. Springer, Berlin

38. Mecella M, Presicce FP, Pernici B (2002) Modeling E-serviceorchestration through petri nets. LNCS 2444:38–47

39. Michlmayr A, Rosenberg F, Platzer C, Treiber M, Dustdar S (2007)Towards recovering the broken SOA triangle—a software engi-neering perspective. IW-SOSWE’07, Sept. 3

40. Microsoft ESB Guidance for BizTalk Server 2006 R2, http://msdn.microsoft.com/en-us/libray/bb931189.aspx

41. Milner R (1999) Communication and mobile systems: the π -cal-culus. Cambridge University Press, Cambridge

42. OASIS MOWS V1.1 Specification http://www.oasis-open.org/committees/download.php/20574/wsdm-mows-1.1-spec-os-01.pdf

43. OASIS MUWS 1.1 Specification. http://www.oasis-open.org/committees/download.php/20576/wsdm-muws1-1.1-spec-os-01.pdf

44. OASIS SCA http://www.oasis-opencsa.org/sca45. OASIS SOA Reference Model, http://www.oasis-open.org/46. OASIS, Web Services Business Process Execution Language Ver-

sion 2.0, OASIS, 2007, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

47. OASIS WSDM 1.1 Specification http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm

48. OASIS, Web Service Resource Framework (WSRF) – Primer v1.2,2006, http://docs.oasis-open.org/wsrf/wsrf-primer-1.2-primer-cd-02.pdf

49. O’Brien L, Bass L, Merson P Quality Attributes and Service-Oriented Architectures. Technical Note, CMU/SEI-2005-TN-014

50. OGF (2003) Open Grid Service Infrastructure (OGSI), http://www.ggf.org/documents/GFD.15.pdf

51. Oracle Application Server 10g ESB http://www.oracle.com/technology/products/integration/esb/pdf/ds_esb_v10_1_2.pdf

52. Ouzzani M, Bouguettaya Athman (2004) Efficient access to webservices. IEEE Internet Comput 8(2):34–44

53. Peltz C (2003) Web services orchestration and choreography. IEEEComput 36(10):46–52

54. Perry DE, Wolf AL (1992) Foundations for the study of softwarearchitecture. ACM Softw Eng Notes 17(4):40–52

55. Schulte W, Sholler D (2009) SOA Overview and Guide to Research.Gartner Research Report (G00166742)

56. ServiceMix, http://servicemix.apache.org57. Shaw M, Garlan D (1996) Software Architecture. Prentice Hall,

Englewood Cliffs, NJ58. Singh MP, Chopra AK, Desai N (2009) Commitment-based ser-

vice-oriented architecture. IEEE Comput 42(11):72–7959. Singh MP, Huhns MN (2005) Service-oriented computing. Wiley,

New York60. Slomiski A (2005) On using BPEL extensibility to implement

OGSI and WSRF Grid workflows. Concurr Comput Pract Exp18(10):1229–1241

61. Tang L, Dong J (2007) A Survey of Formal Methods for SoftwareArchitecture. In: Proceedings of the international conference onsoftware engineering theory and practice, pp 221–227

62. Tang L, Dong J, Peng T (2008) A generic model of enterpriseservice-oriented architecture. In Proceedings of 4th IEEE interna-tional symposium on service-oriented system engineering (SOSE),pp 1–7, December 2008

63. Tang L, Zhao Y, Dong J (2009) Specifying enterprise web-orientedarchitecture. In: High assurance services computing. Springer,pp 241–260

64. Taylor H, Yochem A, Phillips L, Martinez F (2009) Event-DrivenArchitecture. Addison-Wesley, Reading

65. Ten-Hove R, Walker P (2005) Java business integration (JBI) 1.0.final release. Sun Microsystems, Inc, Santa Clara

66. Tsai WT (2005) Service-oriented system engineering: a new para-digm. In: Proceedings of the IEEE international workshop on ser-vice-oriented system engineering (SOSE), pp 3–6

67. Tsai WT, Fan C, Chen Y, Paul R, Chung JY (2006) Architectureclassification for SOA-based applications. In: Proceedings of IEEE9th international symposium on object and component-orientedreal-time distributed computing (ISORC), April, pp 295–302

68. Tsai WT, Bai X, Chen Y (2008) Introduction to service-orientedsystem engineering. TsingHua University Press, Beijing

69. Tsai WT et al (2005) Semantic interoperability and its verificationand validation in C2 systems. In: Proceeding of the 10th interna-tional command and control research and technology symposium(ICCRTS). McLean, VA

70. Tsai WT et al (2000) Automatic test case generation for GUInavigation. Quality Week

71. Vitvar T, Kopecky J, Viskova J, Fensel D (2008) WSMO-lite anno-tations for web services. LNCS 5021:674–689

72. W3C, Web Services Eventing (WS-Eventing), http://www.w3.org/Submission/WS-Eventing/, 2006

73. W3C, “OWL-S: Semantic Markup for Web Services”, http://www.w3.org/Submission/OWL-S/, 2004.

74. W3C, Web Services Description Language (WSDL) Version2.0 Part 1: Core Language, W3C, 2007, http://www.w3.org/TR/wsdl20/

75. W3C, Web Services Choreography Description Language Version1.0, W3C, 2005, http://www.w3.org/TR/ws-cdl-10/

76. W3C, Web Service Management: Service Life Cycle, W3C, 2004,http://www.w3.org/TR/wslc/

77. Wikipedia, List of Web Service Specifications, http://en.wikipedia.org/wiki/List_of_Web_service_specifications

78. Zdun U, Hentrich C, Aalst WMPvan der (2006) A survey of pat-terns for service-oriented architectures. Int J Internet Protoc Tech-nol 1(3):132–143

79. Zhang L-J, Zhang J, Cai H (2007) Services computing. Springer,Oct 2007

80. Zhao Y, Dong J, Peng T (2009) Ontology classification for seman-tic web based software engineering. IEEE Trans Serv Comput2(4):303–317

123

http://msdn.microsoft.com/en-us/libray/bb931189.aspx

http://msdn.microsoft.com/en-us/libray/bb931189.aspx

http://www.oasis-open.org/committees/download.php/20574/wsdm-mows-1.1-spec-os-01.pdf



http://www.oasis-open.org/committees/download.php/20576/wsdm-muws1-1.1-spec-os-01.pdf



http://www.oasis-opencsa.org/sca

http://www.oasis-open.org/

http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm

http://docs.oasis-open.org/wsrf/wsrf-primer-1.2-primer-cd-02.pdf

http://docs.oasis-open.org/wsrf/wsrf-primer-1.2-primer-cd-02.pdf

http://www.ggf.org/documents/GFD.15.pdf

http://www.ggf.org/documents/GFD.15.pdf

http://www.oracle.com/technology/products/integration/esb/pdf/ds_esb_v10_1_2.pdf

http://www.oracle.com/technology/products/integration/esb/pdf/ds_esb_v10_1_2.pdf

http://servicemix.apache.org

http://www.w3.org/Submission/WS-Eventing/

http://www.w3.org/Submission/WS-Eventing/

http://www.w3.org/Submission/OWL-S/

http://www.w3.org/Submission/OWL-S/

http://www.w3.org/TR/wsdl20/

http://www.w3.org/TR/wsdl20/

http://www.w3.org/TR/ws-cdl-10/

http://www.w3.org/TR/wslc/

http://en.wikipedia.org/wiki/List_of_Web_service_specifications

http://en.wikipedia.org/wiki/List_of_Web_service_specifications

Modeling enterprise service-oriented architectural styles

Documents

Transcript of Modeling enterprise service-oriented architectural styles