soa service design

DRAFTCOPY

This is draft content of SOA Enterprise Patterns—Services, Orchestration andBeyond by Dragos Manolescu and Boris Lublinsky, to be published by Morgan-Kaufmann Publishers in 2007. You can find more information about the bookin the About section of the Web site (http://orchestrationpatterns.com/about).

We are making this draft available for comments. Here’s what you can do if you’dlike to get involved:

• Visit the Web site http://orchestrationpatterns.com/ for additionaldrafts.

• Send feedback on the material you read. Try to answer the following ques-tions: Do the patterns convince you about the Problem? Are there any otherimportant Forces? Is the Solution clear to the extent that you can now solvethe problem? Do you know of other Known Uses for these patters? Are wemissing any Related Patterns?

• What would make the pattern better?

• What other aspects of SOA and Service Orchestration you’d like to see cov-ered in this book?

There is also a Yahoo! group (orchestrationpatterns-book) for broadcastingand discussing drafts. The drafts we send to the group also get posted on the Website. If drafts are all you care about then there’s no need to subscribe to the group.

http://orchestrationpatterns.com/about

http://orchestrationpatterns.com/about

http://orchestrationpatterns.com/

DRAFTCOPY

Copyright c© 2004–2006 Dragos Manolescu and Boris Lublinsky

2 http://orchestrationpatterns.com

http://orchestrationpatterns.com

DRAFTCOPY

CHAPTER 2

SERVICE-ORIENTEDARCHITECTURE Defined

2.1 Why Service-Oriented Architecture?

Business and technical people alike are interested in Service-Oriented Architec-ture. Some are taking the Service-Oriented Architecture path because it allowsthem to sharpen their value proposition. The service-oriented enterprise can focuson its core competency, outsourcing the non-core competency functions to trad-ing partners who offer higher quality at a lower price (i.e., rightsourcing). Othersare interested in Service-Oriented Architecture because of it moves software de-velopment away from the large vertical, regional office-driven projects. The ser-vice oriented approach shifts from the monolithic, command-and-control verticalto small, opportunistic, business value-driven applications. There are many, manyother reasons behind the interest in Service-Oriented Architecture. Not all of themare sound; some exploit the confusion and hype around this term. They’ve hadpartial success. There are projects that went down this path only to be buzzword-compliant.

What is Service-Oriented Architecture? Many people talk about it, yet there is lit-

3

DRAFTCOPY


tle agreement of what this widely popular three letter acronym actually represents.The many competing definitions in place make it hard to sort out its true essence.SearchWebServices.com [sea] announced a contest for the best definition. Theyreceived a slew of submissions and little chance of selecting the best one.

One of the main reasons why it is hard to define Service-Oriented Architecture isbecause it means different things to different people [Bro05]:

• From the point of view of a business executive and business analyst, Service-Oriented Architecture is a set of services that constitute business IT assetsand can be exposed to their customers and partners, or other portions of theorganization

• From the point of view of an enterprise architect Service-Oriented Archi-tecture is an architectural style that promotes the concepts of business pro-cesses and the orchestration of enterprise-level business services [LT03]. Itis also a set of architectural principles, patterns and criteria which addresscharacteristics such as modularity, encapsulation, loose coupling, separa-tion of concerns, reuse, composability, etc.

• From the point of view of a project manager Service-Oriented Architectureis a development approach supporting massive parallel development.

• From the point of view of a tester and/or quality assurance engineer Service-Oriented Architecture represents a way to simplify overall system testing.

• From the point of view of a software developer Service-Oriented Architec-ture is a programming model complete with standards, tools and technolo-gies such as Web Services.

2.2 Application-centric Architecture

There is one theme common to many of the Service-Oriented Architecture def-initions which gets to its core: it is a way to decompose enterprise IT systemsinto smaller, more manageable software artifacts called services. Through serviceorchestration these services can be assembled to implement enterprise businessprocesses.



DRAFTCOPY

2.2. APPLICATION-CENTRIC ARCHITECTURE

Decomposition is a technique formalized by classical system theory in the late-1950s. System theory stated that the more complex a system is, the more un-knowns it contains and thus the harder it is to automate it. This theory prescribeddecomposing complex systems into smaller, more manageable ones, which areeasier to control and then treating the whole system as a composition of its parts.The same applies to the complex software development initiatives.

Decomposition represents one of the cornerstones of the good software engineer-ing [Par72]. Architects and designers employ decomposition to influence manyarchitectural qualities.

Manageability Decomposition can split a complex problem into a set of a sim-pler ones, thus making the overall solution more manageable.

Specialization Decomposition can promote the separation of concerns, leading todesign and implementation of specialized parts. This also allows for usingdifferent tools (including programming languages) for different parts of thesystem.

Testability Decomposition can promote the independent testing of each part, thussimplifying overall system testing.

Maintainability Decomposition can localize change, thus improving maintain-ability and decreasing the total cost of ownership (TCO).

Development speed Decomposition can facilitate the parallel development ofparts, thus decreasing overall development time.

Reusability Decomposition opens up the possibility of reuse through the creationof parts which can be used in multiple systems.

2.2.1 Evolution of Decomposition in Software

The first software decomposition approach (introduced in the early 1960s) wassplitting applications into separate “jobs,” each implemented by a separate pro-gram. Later, as more insight into the program internals was gained, each programitself was split into modules or subroutines, according to their function.

The object-oriented paradigm introduced by Simula and Smalltalk in the 1970sgave decomposition a big push by introducing objects: modules of code, each of

http://orchestrationpatterns.com 5


DRAFTCOPY


which implemented a model of a real thing. The idea was to represent in softwarethe “things of the problem domain,” for example “customer,” “order,” or “trade.”However the abstractions provided by objects turned out to be too fine-grained andintertwined with technical concepts to have a meaning on the business level. Forvarious reasons many object-oriented developers wound up spending most of theirtime dealing with technical constructs such as collections, graphical widgets, andso on. As a result, in most cases the “objects of the problem domain” disappearedinside amorphous modules which no longer represented anything recognizable bydomain experts.

In the continued search for a better design paradigm, a different approach to de-composition was introduced in the late 1990s: components. The idea was to fixthe problems of object-orientation by introducing a different abstraction, moretightly linked with the business “things,” and use objects for its implementation.According to version 2.0 of the Unified Modeling Language (UML) the compo-nent concept addresses the area of component-based development and component-based system structuring, and is modeled throughout the development life cycleand successively refined into deployment and run-time [Obj].

A component has the following characteristics:

• It is a type, i.e., it supports a specific set of concepts and interfaces.

• It is visible and tangible throughout the development life cycle and at therun-time.

• It can be built and deployed autonomously; an example of autonomous de-ployment is updating a system with a new version of the component.

• It is intended to be combined and composed with other components withwhich it collaborates to deliver solutions.

While components followed objects and thus represent the next evolutionary step,the increased level of abstraction has additional requirements. Components re-quire advanced middleware capabilities (component-ware), supporting featuressuch as:

• Separation of interfaces and implementation—allowing for substitution ofthe implementation without changing the interface.



DRAFTCOPY


• Incremental deployment.

• Instance pooling—allowing for efficient resource utilization.

• Transactional support—simplifying implementation support for ACID trans-actions, spanning multiple components.

• Security support—providing a standard security model and simplifying theimplementation of security on individual components.

Today several commercial implementation of component ware are available onthe market, most notably COM/DCOM (Microsoft), EJB/J2EE (open specifica-tions headed by SUN), and CORBA components from various vendors followingOMG’s standards. These platforms, along with the corresponding developmentand deployment tools, significantly simplify the development, deployment andmaintenance of components. But this power has its price:

• The component interface definition has to follow the rules of the particu-lar platform. For example, EJB interfaces are expressed in Java, CORBAcomponents implement IDL-based interfaces, and so on.

• The component implementation has to follow the rules and conventions ofthe imposed by the middleware platform. This usually prohibits the intro-duction of existing software or packaged applications as “first class compo-nents.”

• Interoperability between component-ware platforms both on the design andimplementation level is problematic.

The introduction of software components improved the creation of flexible, betterstructured, and more manageable software applications. However the it did notsolve the main enterprise IT problem: its application centric nature. Both objectsand components focus on the better design/development approaches for individualapplications.

2.2.2 Problems of Application-Centric Architecture

Traditional architecture is concerned with a collections of applications. Typicallythe development, enhancements and maintenance of software systems revolved



DRAFTCOPY


around applications. But this application-centric approach to software develop-ment and evolution is one of the major contributors to expensive, inflexible and“siloed” IT systems (see sidebar on the economics of IT).

Sidebar: The Economics of IT

In the last 30 years, Software Engineering has made tremendous advances in termsof system complexity and delivery efficiencies through new levels of modeling andabstractions. As a result, the productivity of developers has grown dramatically, tothe point where any IT organization has to deal with a large number of applicationsand systems automating all but business functions and roles. Incidentally thisnumber is often greater than its own headcount. For each system individually, aclear Return-On-Investment (ROI) justified its construction. However, the levelsof automation we have reached have also created a landscape where the data modelof any given organization spreads across many systems. As an illustration, Figurebelow represents a mockup of the number of attributes of business entities suchas Customer, Order, Bill of Material, in different functional systems (ERP, CRM,SCM,).

Furthermore, these systems are built over periods of time during which infras-



DRAFTCOPY


tructure technologies evolves, creating a de facto broad and complex technologylandscape. As new systems get added the cost of integrating and evolving systemsadded to the cost of managing secure and available information systems will growprobably to the point where it consumes entirely any given IT budget leaving littleroom for innovation.

Let’s understand why by looking at the value and cost of adding a single new in-formation system to an organization versus the number of systems that are alreadysupporting this organization. At first, the value increases rapidly because organi-zations automate the most productive business processes. Over time, lower valueprocesses are automated, though the complexity of adding these new systems re-mains constant or even increases. It may also happen that adding yet anothersystem could potentially decrease the value of existing systems as it is not un-common to find information workers that utilize many applications to performtheir day-to-day activities. This often lowers productivity because they need toswitch context, increasing the risk of inconsistencies between similar data inputs,increasing training costs, ...

Figure above summarizes the plausible trends of cost and value of adding newsystems versus the number of systems in a given IT organization (this figure is notbased on real data). The reason why IT yields less and less competitive advantagetoday is because most organizations have reached the cross over point and haveentered a situation where their financial margins can no longer be improved byIT projects. Even tough many organizations still find innovative ways to improve



DRAFTCOPY


their business, the costs, risks and complexity of the existing IT landscape preventsmost of the projects to go forward.

IT could restore its leadership in supporting business innovation by using tech-nologies and application models that promote reuse and flexibility while reducingintegration costs. The bottom line is that IT can no longer afford to build new sys-tems of record, nor it is necessary. Silos, supported by monolithic architectures,can no longer exist within IT. In parallel, new levels of value could be achievedby consuming third party services that provide access to information that cannotbe hosted within the boundaries of a corporation (e.g. credit check) and by im-proving information worker productivity via composite applications that providesingle views for all user activities. This is precisely what SOA and Web Servicestechnologies are about.

Jean-Jacques Dubray, SOA Enterprise Architect, Safeco Insurance

Large numbers of heterogeneous applications and systems, each of which with itsown data store(s) create segregated islands of data within the enterprise architec-ture. These islands of data have the following characteristics [Lub01a]:

• Each island of data has its own meaning and/or definition of enterprise ob-jects. For example, while in one application “price” denotes the net price,in another application the same term also includes the sales taxes. Alter-natively an “address” can have the same meaning in two applications, butone of them is defining it as a set of address lines, while another one treatsit as street address, city, state, zip and country. Both cases create semanticdissonance between applications.

• Each island of data has information that overlaps with the contents of an-other island. For example, applications dealing with the management ofhealth and dental claims also store the demographics information for the in-sured. At the same time CRM application contains both insured addressesand demographics. This duplication creates integrity issues

• By itself, none of the islands can provide a complete picture of the enterprisedata. For example, a mortgage management application doesn’t contain in-formation about the borrower’s loans from other lines of business. Creating



DRAFTCOPY


a unified view of the enterprise data requires integrating information frommultiple sources.

The Application-centric approach also leads to creation of islands of automation.Each application is built for a single purpose (e.g., loan decisioning, dental claimmanagement, etc.) and for a single set of users. As such it implements only asubset of the enterprise functionality, typically without concerns about integrationthroughout the entire enterprise. The islands of automation have the followingcharacteristics:

• Each island of automation focuses on a limited set of activities within theenterprise. For example, the health claim management application dealsonly with the processing of health claims. This requires users to perform“application hopping” to perform their work, thus impacting their produc-tivity.

• There is duplication between business processes contained within differ-ent islands. For example, as a result of a merger or acquisition an insurancecompany can have several claim processing systems. This requires synchro-nization of business rules, between multiple applications, implementing thesame process.

The effects of the islands of data and automation are invisible at the level of in-dividual applications. However they cause significant problems at the enterpriselevel, most notably:

Information fidelity The redundancy of business data between applications cre-ates an inaccurate representation of enterprise data, even when periodic syn-chronization occurs. The representations themselves are difficult to recon-cile, or at worst contradictory. As the individual applications evolve inde-pendently, the complexity of the problem increases.

Business processes fragmentation Individual applications provide a limited pieceof enterprise functionality. Implementing business processes requires link-ing together the applications containing partial implementations of process.

Solving these problems brought Enterprise Application Integration (EAI) and En-terprise Information Integration (EII) at the focal point of many enterprise projects.Today these activities consume (and will continue to do so) a significant fractionof the enterprise IT budget.



DRAFTCOPY


Characteristic Application-centricarchitecture

Service-OrientedArchitecture

Design andimplementation

Function-oriented Coordination-orientedBuilt to last Built to changeLong development cycle Built and deployed

incrementally

Resulting systemApplication silos Enterprise solutionsTightly coupled Loosely coupledObject-oriented interactions Semantic message oriented

interactions

Table 2.1: Application-centric vs. SOA

2.2.3 From Applications to Processes and Services

Service-oriented computing is an approach that promises to do for enterpriseIT what components have done for applications. The introduction of Service-Oriented Architecture leads to a gradual shift from applications to architecturalelements that are closer to business-level abstractions.

Two key Service-Oriented Architecture abstractions promote the alignment be-tween the business and the IT. Business processes define the functioning of thebusiness. They orchestrate services which represent the activities of these pro-cesses. In effect, at the heart of Service-Oriented Architecture lies the eliminationof the applications as they are known today in favor of flexible business processesimplemented on top of enterprise business services.

Table 2.1 summarizes the key differences between these application-centric andservice-oriented architecture approaches.1

Service-Oriented Architecture’s charter is to create software systems as a set of in-teracting “services,” where every service implements a particular “business thing”or function, which are defined in the context of the overall enterprise. To putit precisely: components provide decomposition for a particular application,whereas services provide decomposition for enterprise IT system as a whole(role which was previously played by the applications).

1Based on correspondence with Jean-Jacques Dubray.



DRAFTCOPY

2.3. SERVICE-ORIENTED ARCHITECTURE AS AN ARCHITECTURALSTYLE

2.3 Service-Oriented Architecture as an Architec-tural Style

Now that we have positioned Service-Oriented Architecture as the successor to theapplication-centric architecture we can present a more formal description of whatit is. Don’t hold your breath though for a formal definition that everybody willagree with: we aren’t going to attempt that. People have yet to reach agreementabout what “software architecture” is.2

There have been several attempts to present Service-Oriented Architecture as ei-ther a new form of distributed systems architecture, as an extension of object-orientation, or as a the next generation EAI. Let’s take a closer look at theseanalogies.

2.3.1 Service-Oriented Architecture and Distributed Systems

The W3C Architecture group defines SOA as a form of distributed systems archi-tecture [Gro04], typically characterized by the following properties:

Logical view The service is an abstracted, logical view of actual programs, databases,business processes, etc., defined in terms of what it does, typically carryingout a business-level operation. In other words service is defined as a busi-ness meaningful action.

Message orientation The service is formally defined in terms of the messagesexchanged between provider and consumer, and not the properties of theprovider and consumer themselves. The internal structure of implemen-tation is deliberately abstracted away. In other words service interface isseparated from the service implementation.

Description orientation A service is described by machine-processable metadata—service definition.

Granularity Services tend to use a small number of operations with relativelylarge and complex messages (payloads).

2The SEI maintains a list with software architecture definitions. Currently this list containsmore than 50 different definitions.



DRAFTCOPY


Figure 2.1: W3C’s SOA model

Network orientation Services tend to be oriented toward use over a network,though this is not an absolute requirement.

Platform neutral Messages are sent in a platform-neutral, standardized formatdelivered through the interfaces. XML is the most obvious format that meetsthis constraint.

The Service-Oriented Architecture model from Figure 2.1 can be defined in termsof invocation message, implementation, owning organization and metadata, de-scribing the service.

• The Message Oriented model defines message in terms of its content (headerand body), delivery transport and originating and executing agents.

• The Resource model defines resources (implementations) in terms of URI,representation and owning organization.

• The Policy model defines policy in terms of its subjects (resource and ac-tion) and organization, supporting policy.

2.3.2 Service-Oriented Architecture and Object-Orientation

Some practitioners consider Service-Oriented Architecture and services a directevolution of objects, considering services as object/components on steroids [Gos05].



DRAFTCOPY


This is as far from the reality as it can get. The similarities do not extend beyondsystem decomposition for definition, and encapsulation for implementation.

Additional features of objects such as inheritance and polymorphism are not ap-plicable to Service-Oriented ArchitectureBut what really sets the two apart is us-age/programming model. (Trowbridge and colleagues [TMQ+03] have a closerlook at these differences in their comparison of Instance-Based and Service-BasedCollaborations.)

• In the object3 paradigm objects are created along with their internal state.This state represents a particular execution context which distinguish multi-ple object instances (potentially existing simultaneously) of the same type.The object’s lifecycle is controlled explicitly by its consumer. Every objectexposes multiple methods which are bound to a particular instance (exe-cution context) and allow to manipulate variables on a given instance. Ingeneral there is no cross-visibility between object instances.

• In Service-Oriented Architecture a service exists regardless of whether par-ticular consumer invokes it or not. In other words, the service lifecycle doesnot correspond to the lifecycle of any particular consumer. Services do notsupport the execution context of a particular consumer—the typical serviceinvocation is stateless—but rather the state of the enterprise resource(s) as-sociated with it. The programming model is the direct invocation of theservice with the assumption that it already exists.4

This difference has a profound impact on the interface definition for objects andservices. In the object paradigm multiple methods defined on the interface alwaysphysically belong to the same instance of the object because they are bound to thesame execution context. In contrast, since services don’t have an execution contextthe association of methods in the service interface is a pure logical construct. Theservice (and consequently service interface) effectively represents a namespaceclustering the service methods,5 which are otherwise independent entities withtheir own quality of service requirements, security, versioning strategy, etc. To

3This discussion is equally applicable to components. However to avoid saying “objects andcomponents” we are using only the former.

4The notable exception to this rule is a conversational composite service. Conversational com-posite services usually have an execution context, supporting a particular conversation. Howeverthis context is created implicitly, upon the receipt of the message starting conversation

5A conversational composite service can be an exception and expose multiple methods, which



DRAFTCOPY


make a programming language analogy, every method of the service is similarto a FORTRAN subroutine, which can exist and be executed independently fromother functions.

Sidebar: Execution state vs. Invocation state

There is a profound difference between the notions of execution and invocationstate:

Execution state represents the state of the service during its execution. It alwaysexists and include internal variables, created during service execution. It isused for keeping track of which part of service execution has completed,storing results of partial service execution and passing parameters betweenmultiple components of service implementation. This state is encapsulatedin service implementation and invisible to the service consumers.

Invocation state is a shared context between service consumer and service im-plementation. In this case a consumer invokes different methods of the sameservice, assuming that the information that was passed to the service duringparticular invocation is available to the service during all consecutive invo-cations. A service, in this case, participates in multiple conversations withdifferent consumers and keeps track of each conversation separately. Thenotion of invocation state is used, for example in the session variables, orstatefull session bean in J2EE. A better term describing this type of state is“session state.”

Throughout this book when we talk about statefull vs. stateless invocation of ser-vices we are referring only to the invocation state.

physically belong to the same service, similar to objects. This usually happens when the compositeservice defines multiple methods that implement conversations with the service consumer, forexample, “create order,” “update order,” “get order status,” etc.



DRAFTCOPY


2.3.3 Service-Oriented Architecture and EAI

Many practitioners are presenting Service-Oriented Architecture as the next gen-eration EAI technology.6 Traditional EAI technology works well for integratingseparately-developed applications. However it is usually based on proprietary so-lutions from EAI vendors, thus creating “lock in” to the vendors’ platforms. Withthe current proliferation of Web Services as a technology for providing “trans-port solutions,” Service-Oriented Architecture and Web Services are becomingstandards-based integration solutions. This makes them an extremely attractive(i.e., vendor-independent) alternative to EAI. The introduction of the EnterpriseService Bus (ESB) products made Web services-based, standards-based integra-tion extremely popular.

More importantly, although the end result of EAI and Service-Oriented Archi-tecture is the implementation of business processes with the existing applicationportfolio, they achieve it in radically different ways. EAI focuses on exposing theapplications’ functionality, effectively shaping the enterprise model in the imageof the existing application portfolio. In contrast Service-Oriented Architecturefocuses (as we will discuss in part ??) on hiding the existing applications andexposing a set of application-independent services instead.

2.3.4 Elements of Service-Oriented Architecture

In spite of superficial similarities, Service-Oriented Architecture represents a rad-ically different approach to building enterprise solutions that is based on the in-sights gained from distributed systems, objects, and EAI. Service-Oriented Archi-tecture involves rethinking the abstractions and their relationships that provide thefoundation of the architecture.

Service-Oriented Architecture is an architectural style promoting the concept ofenterprise business processes that orchestrate the execution of enterprise businessservices. Service-Oriented Architecture supports linking resources (in the form ofservices) on demand by orchestrating them using business processes [RL05]. Theenterprise Service-Oriented Architecture defines a set of business-aligned IT ser-vices (available to participants throughout the enterprise across multiple lines ofbusiness) that collectively fulfill an organization’s business processes and goals.

6The Gartner Group has even come up with the term Service Oriented Integration (SOI).



DRAFTCOPY


These services can be choreographed into enterprise business solutions and in-voked through standard protocols.

Figure 2.2 illustrates the major elements of Service-Oriented Architecture.

Organization owns all of the Service-Oriented Architecture artifacts (models,services, processes, resources) and governs their creation, usage, access,and maintenance. The remainder of the artifacts support the organizationand its goals.

Business Model represents the primary representation of the business’ resourcesand processes that are performed to meet operational, tactical and strategicbusiness goals. Service-Oriented Architecture provides the framework forstructuring and aligning IT to meet those goals. A business model is criticalto successful alignment of services with business goals and requirements.

Semantic Data Model defines the standard business data objects for a given en-terprise (such as customer, agreement, etc). These objects effectively createan ontology of the enterprise data by defining common concepts (and theircontent) which describe the functioning of the enterprise. Using this datamodel for defining the business services interfaces leads to the creation ofinteroperable semantic interface definitions—a semantic Service-OrientedArchitecture.

Documents represent legal entities (such as financial documents, insurance poli-cies and claims, and government regulations) that define the obligations ofthe enterprise and its partners. Documents are a vital part of modern enter-prises and have to be included in the Service-Oriented Architecture imple-mentations as first-class citizens.

Services implement specific business functions and access enterprise data and re-sources. Well defined and business-aligned services are a critical ingredientof a flexible, extensible enterprise. The structure of services allows them tobe independently developed and deployed. Correctly defining and aligningthem with the business and semantic models results in plug and play, allow-ing them to be effectively combined into different enterprise wide businessprocesses.

Information represents the data resources of the organization. Data resides in avariety of different stores, applications and formats. Different levels of data



DRAFTCOPY


Figure 2.2: Enterprise SOA Concepts



DRAFTCOPY


are used by different levels of Service-Oriented Architecture constructs.The semantic data model defines the data for business processes and ser-vices. The Service-Oriented Architecture defines the mechanisms for trans-forming data from its native operational format to the semantic data requiredfor the business services.

Business Processes orchestrate the execution of business services to implemententerprise functionality as specified in the business model—for example,order processing or claims processing. Business processes usually are as-sociated with operational objectives and business goals (such as insuranceclaims processing or engineering development processing); have definedtriggering (initiation) conditions for each new process instance (for exam-ple, the arrival of a claim); and defined outputs at its completion.

Sidebar: SOA Reference Model

Since you are reading this book, there is an assumption that you are both inter-ested in SOA and understand what it is. Perhaps at a high level, there is consensuson SOA, but often getting more granular reveals conceptual level inconsisten-cies. Hence, a formal definition for Service Oriented Architecture varies greatlydepending upon whom you ask and in some cases, the definition is conflicting.While the talk of SOA has dominated the press/analyst coverage, no formal stan-dard definition exists. In 2004, a group attempting to work on a project realizedthey had vastly differing opinions on SOA and felt it was irresponsible to try tospecialize SOA without core consensus on a generalized definition. The project,the OASIS eBusiness SOA Technical Committee1, had a mandate to build a ref-erence architecture for electronic business to marry the patterns of SOA with thepatterns of business. Eventually, the group became somewhat disillusioned whenthey realized a vast disparity in how the patterns of SOA were depicted in variouscontexts. The ebSOA group started asking some rather pragmatic questions aboutSOA. If SOA is architecture, as the name implies it is, how can it be expressedas architecture and how is that architecture different from other architectures? IsSOA significantly unique to warrant its existence? Is Object Oriented equal toSOA? What are the major differences? The group stopped work on the ebSOAproject and began work to reach consensus on these questions and foster a coreunderstanding and definition of Service Oriented Architecture.



DRAFTCOPY


Rather than duplicating the work of the W3C’s Web Services Architecture Groupand build a reference architecture, the group focused on defining a more abstractReference Model, which can quickly confuse non-architect’s who have troubledistinguishing between architecture and models. A Reference Model (RM) isan abstract framework for understanding significant entities and relationships be-tween them within a service oriented environment, and for the development ofconsistent architectures supporting that environment. It is based on unifying con-cepts of SOA and may be used by architects developing specific service orientedarchitectures or in training and explaining SOA. A reference model is not directlytied to any standards, technologies or other concrete implementation details (like“Web Services”). Hence, a good reference model provides common semanticsthat can be used unambiguously across and between different implementations.In fact, the reference model is equally applicable to building a coffee shop busi-ness as it is to software architecture, although the groups focus was on the latter.

The OASIS SOA RM Technical Committee goal was to deliver a Service Ori-ented Architecture Reference Model (SOA-RM). For the software discipline, theRM for SOA was eventually defined as a “paradigm for organizing and utilizingdistributed capabilities that may be under the control of different ownership do-mains.” The intent was not to arrogantly define one single reference model whichthe entire world should be forced to use, rather to place a stake in the ground soindividuals could qualify their definition of SOA by stating either “when I saySOA I am referring to the OASIS RM for SOA” or “when I say SOA, I mean theOASIS RM for SOA with the following exceptions. . . ” Simply stated, it is a stickin the mud (or FUD) by which users may map their own understanding to eachother.

The RM is also infused with patterns. Patterns are abstract templates that canbe reused. Each pattern shows a set of specific concepts mapped to each other,complete with text to describe their externally visible properties and the nature ofthe relationships between them.

The core pattern/view of the RM for SOA starts with the concepts of Service, Vis-ibility, Service Description, Execution Context, Real World Effect and Contractand Policy.



DRAFTCOPY


A service is a mechanism to enable access to a set of one or more capabilities,where the access is provided using a prescribed interface and is exercised consis-tent with constraints and policies (Contract & Policy) as specified by the servicedescription. The consequence of invoking a service (interaction) is a realizationof one or more real world effects, described in detail in the current draft of theRM specification. The execution context of a service interaction is the set of in-frastructure elements, process entities, policy assertions and agreements that areidentified as part of an instantiated service interaction.

Services have many other facets and axioms expressed in the current commit-tee draft of the RM for SOA. As depicted below, services have action models,process models and information models. Information models themselves have as-pects such as semantics and structure which need to be universally interpreted andunderstood by the community of potential consumers.



DRAFTCOPY


In the pattern above (expressed as a concept map), more atomic aspects of interac-tion with a service are noted. Specifically, the information model (further decom-posed into semantics and structure) and the behavior model (further decomposedinto the action and process models). An example of the behavior model mightbe a simple request-response pattern or something more complex such as a sub-scription to receive multiple responses to various endpoints. An example of aninformation model could be an XML schema to describe the structure of the in-stances of XML information being passed in and out of a service interface coupledwith a shared conceptualization of the meaning of each piece of information listedon the schema.

So why is the Reference Model so important? Reference models are important forall industries. The housing industry has an implied reference model “ResidentialDwelling.” It serves a purpose of providing habitable space for human beings.It has clearly defined components such as a door (interface to the community),floors, walls, rooms, a roof, plumbing, heating and electrical systems, windowsand more. The main purpose of this implied reference model is to ensure that theentire industry has consensus on the meanings of these terms, which avoids gen-eral chaos when architecting and building houses. A house architects knows thatwhen he specified a “front door” for a house, that it will be universally understoodby the builder and user what the door does and how it may be built and used. Theyknow a door manufacturer makes that component within the guidelines required



DRAFTCOPY


by the contractors. While the consensus exists, it in no manner constrains indi-vidual implementations and architects are free to design houses for many uniquesituations, locales and clients, each with their own special requirements.

A parallel exists for the world of SOA. Major vendors need to align around thecore concepts of service oriented architecture. If a CIO composes architecturefor a specific facet of his companys infrastructure, he might utilize the referencemodel to aid his design. This can be done in conjunction with other models suchas Model-View-Controller (MVC). He or she may elect to architect a visibilitymechanism, a service description, a service policy declaration and other core com-ponents of the reference model for SOA. When doing this, they require knowledgethat vendors will be capable of supplying components for fulfilling the function-ality of each thing with a shared understanding of the what each piece does andhow it relates to other things in the architecture. This will also guide architects tothe standards that are commonly used to facilitate the functionality. In this exam-ple, the visibility mechanism may be implemented using WS-Enumeration; theservice description using the Web Services Description Language (WSDL); andthe policy declaration using WS-Policy and WS-PolicyAttachment.

The Reference Model for SOA9 is similar in this manner. In the IT space, archi-tects, CIOs and other IT workers, ISVs and others all need to speak a commonlanguage when discussing SOA. The OASIS RM for SOA focuses its’ views onthe abstract service, then progresses to divulge information on the other conceptslinked to the service. In some ways, SOA is really a view of architecture focusingon specific views and things influenced by it. Note how the reference model ishighly abstract yet ties in the core concepts of SOA to tangible specifications onthe right hand side.



DRAFTCOPY


There are a number of things that may not be immediately obvious with respectto the reference model. First, it is non constrictive upon architects. They arefree to use only parts of it if they see fit. Secondly, the process of developing animplementable architecture may involve several steps. The second step may beto develop a Reference Architecture (RA), upon which SOA for specific verticalsmay be based. The process of developing specialized architectures is within thecharter of the OASIS SOA RM TC, however as of April 10, 2006, they have onlyrecently begun work on a single reference architecture. The RA is based upon thereference model for SOA, which is currently a Committee Draft and on its wayto becoming a Committee Specification by way of public review. It may progressto become a full OASIS standard. Architects and other IT workers are welcome(and encouraged) to download and view the work.

Duane Nickull, Chair, OASIS SOA Reference Model Technical Committee

Service-Oriented Architecture stands out as an architectural style promoting thealignment of business and technology because all its elements have business mean-ing. In fact, all of them trace back to Enterprise Business Architecture. Let’s takea closer look at the two key elements, services and business processes.



DRAFTCOPY


Figure 2.3: The evolution of decomposition approaches

2.4 Services

In an interview at Info World Grady Booch stated that “the fundamentals of engi-neering like good abstractions, good separation of concerns never go out of style,”but he also pointed out that “there are real opportunities to raise the level of ab-straction again” [Sca04]. Service-Oriented Architecture increases the abstractionlevel above objects and components, to services. Figure 2.3 illustrates this evolu-tion.

2.4.1 Services, Components and Objects

One can think about a service as a mini “application,” supporting specific func-tionality relevant to an enterprise as a whole and “integratable” by design. Theservice functionality is defined by a service interface, which can be supported bymultiple implementations. Although this simplified explanation sounds very sim-ilar to the basic definition of components, there are important differences betweenservices and components:

• Components represent application concerns and as such they are usually



DRAFTCOPY

2.4. SERVICES

“local”7 to a particular application. In contrast, services represent enterpriseconcerna and are always “remote” to other services and processes invokingor orchestrating them.

• A component represents a “type,” with multiple instances of it being presentin the system simultaneously. Every instance of component is created by itsconsumer explicitly as necessary, with a specific execution context, definedby a consumer. A service represents a singleton instance8, shared by allservices consumers and supporting the enterprise context. A service is notcreated by its consumers, but rather exists within an enterprise and is usedby all of its consumers. When multiple applications “reuse” the same com-ponent, this component’s implementation is physically packaged with eachapplication. In contrast, the same physical service implementation is reusedat run-time by all consumers.

• Component interfaces are defined based on the requirements of a specificcomponent platform. In contrast, the service interface is independent of aparticular middleware platform/language.

• Strong associations create a tight coupling, and, consequently, a dependencybetween the involved types or components. In contrast, services are signifi-cantly more loosely coupled than components, and are more resilient to theinevitable interface changes.

• Components support semantics of the application they are designed for. Incontrast, because services are used throughout the enterprise their interfacesare usually based on enterprise semantics.

• The granularity of services (and their interfaces) is usually larger than thegranularity of components, in order to minimize the amount of networktraffic. Services are usually built using components.

The relationship between services and components is similar to the relationshipbetween components and objects [RL05]. The component introduces a more in-

7Term local to the application does not mean “in process” invocation. There are numerousdistributed applications, build using remote components. The emphasis here is that componentaddresses a particular application is not directly used (through remote invocation) by another ap-plication.

8Although a service represents a “logical” singleton, there may be additional replication andpartitioning to support architectural goals such as availability, security, and so on.



DRAFTCOPY


Figure 2.4: Hierarchy of Service Elements and Concepts

dependent, higher granularity, and more abstract concept than objects, but in factis typically constructed using objects. Similarly, a service is a more independent,higher granularity and more abstract concept than a component, but is frequentlyconstructed using components as illustrated in Figure 2.4.

2.4.2 Types of Services

There are three common types of services: business services, integration servicesand infrastracture services.

At the heart of the Service-Oriented Architecture are business services: program-matic implementation of the business concepts, defined by the enterprise businessmodel. Business services are independent from the current enterprise applicationpotfolio and define “ideal” enterprise architecture. These services are the founda-tion (building bloks) for the entrprise-wde business processes.

Integration services [Lub04a] define an architectural and implementation approachto application integration. They represent a specific use of Service-Oriented Ar-chitecture platform technologies, usually Web Services, for simplifying the inte-gration of applications and legacy systems within the enterprise. By leveragingthe interoperability standards of Web Services this approach promises better in-teroperability and lower cost. It also exploits the enormous hype around Service-Oriented Architecture.



DRAFTCOPY

2.4. SERVICES

There are two major types of integration services that are used:

Data integration services implement data integration between multiple applica-tions [Lub01c]. They are usually invoked by the application or legacy sys-tem in which data has changed. This integration service is usually imple-mented when multiple applications work mostly independently, but datachanges in one applications impacts the functioning of other applications.As such it is similar to publish-subscribe application integration.

Functional integration services expose the functionality of the existing applica-tions for use by other applications and services [Lub01b]. The applicationrequiring this functionality invokes the integration service. Functional inte-gration services can cover a wide spectrum, from simple data accessors—where the service implements data integration through an exposed func-tional interface—to complex—where the service makes an application’sfunctionality available to its consumers. Coincidentally, data recipients ofdata integration are usually implemented using functional integration ser-vices, invoked by either dedicated business process or a centralized broker.

Although integration and business services use the same technologies their archi-tectures differ significantly:

Collaborations Business services are exposed to business processes or other,higher-level business services. In contrast, business processes do not in-voke integration services directly. Business components or other businessservices wrap integration services in order to expose them to the enterprise.These business components and services separate enterprise business pro-cesses from the topologies and data of the existing applications. They mayalso be responsible for additional functionality, extending the capabilities ofthe existing applications.

Granularity Business services are coarse grained, implementing large chunksof functionality. In contrast, integration services can be fine grained. Thegranularity of the integration service is defined by the granularity of thefunctionality exposed by the application.

Temporal Coupling To achieve temporal decoupling business services tend tobe invoked asynchronously. In contrast, synchronous invocation representsthe prevalent communication style with integration services.



DRAFTCOPY


Transactionality Well-designed business services are independent, autonomous,and have separate transactional scopes. In contrast, ACID are often a re-quired property for integration services, especially when the they updateapplication data.

Finally a third type of service—infrastracture services (sometimes referred to ascommon services) are service-oriented implementations of enterprise IT concerns:

• Security, Authentication, etc.

• Error handling.

• Logging.

• Monitoring and management.

• Documents processing.

The centralization of enterprise-wide IT functionality into a set of services ensuresits consistency and improves flexibility and modifiability. Although not directlysupporting enterprise business functionality, infrastructure services typically pro-vide the foundation for Service-Oriented Architecture system implementations.

In the reminder of this book we will concentrate on the business services. Unlessotherwise specified the term service means “business service.”

2.4.3 Service Implementation Concerns

The service implementation concerns span from the ones visible to the serviceconsumer—such as service definition, service interface, and access policies—tothe ones that are not exposed to the consumer—such as service implementation.Figure 2.5 shows these elements and the relationships between them.

In this diagram:

• The service interface describes the capabilities provided to potential con-sumers. The interface is defined as a service name (i.e., a namespace) and



DRAFTCOPY

2.4. SERVICES

Figure 2.5: Service implementation concerns

a set of operations supported by the service. The description of every oper-ation includes definitions of the set of parameters required for service invo-cation (request) and, if applicable, the result returned by the service (reply).The description also covers the operation’s functionality and its pre- andpost-conditions.

• The service interface is usually exposed to service consumers in the form ofservice definition.

• The service contract defines one or more service endpoint addresses forevery operation. Defining multiple endpoint addresses allows for exposingthe same functionality (service operation) with different QoS, as requiredby multiple consumers.

• Each endpoint address is governed by a set of access policies. These poli-cies define the communication protocol used for data transfer and actualservice invocation, security and privacy requirements, etc.

• The service is business aligned with functionality of the enterprise and issupporting the enterprise business goals.

• Granularity and loose coupling represent important service attributes.

• The service implementation strives for maximum reuse of the existing en-terprise functionality.



DRAFTCOPY


• Service orchestration represents the prevalent mechanism for composingservices into larger ones.

Some of the elements presented in Figure 2.5, such as interface and definition, re-semble their counterparts from the component or object worlds. Others representService-Oriented Architecture-specific characteristics that are key to meeting theobjectives outlined in Section 2.1. The following sections take a closer look atsome of them.

Business Alignment

Fundamentally Service-Oriented Architecture decomposes the enterprise IT sys-tems in a set of flexible, “integratable,” reusable business services, providing re-quired architectural qualities (performance, security, throughput. etc.). Thesegoals can be achieved only if the service definitions are aligned with the businessmodel of the enterprise. Consequently, an enterprise business model is a prerequi-site for a successful Service-Oriented Architecture implementation. A high levelmodel needs to be in place to set the direction, partitioning and taxonomy of ser-vices. Its details can be developed over time, in parallel with development of theservices.

This approach to the definition of the enterprise business services allows for bet-ter alignment of business, organizational and application (services) architectures(as prescribed by Convergent Architecture [Tay95, Hub01]). Subsequently, it be-comes easier to trace software implementations (services, processes) back to thebusiness architecture, thus making software applications easier to understand bybusiness analysts and simplifying the implementation of changes in the businessfunctionality.

Service Granularity

In Service-Oriented Architecture the communication channel between a serviceand its consumers involves the network. In other words, all service invocationsare remote.9 The communication channel’s10 latency and availability determine

9There are application domains where Service-Oriented Architecture does not involve net-works. However those are specialized rather than enterprise business applications.

10In information theory parlance.



DRAFTCOPY

2.4. SERVICES

how the service consumers perceive these characteristics. Service-Oriented Ar-chitecture design makes explicit the very different characteristics of intra- (i.e.,inside the service) and inter-service (i.e., across service boundaries) calls. Thisdifferentiation emphasizes that service calls are expensive.

In contrast, traditional distributed technologies such as CORBA and DCOM aimfor local/remote transparency. In other words, they present the same programmingmodel regardless of the target’s location. On the one hand the consistency simpli-fies the programming model. On the other hand it allows developers to spend littletime thinking about and defining boundaries. This tradeoff between simplicity ofdevelopment and execution speed represents one of the major reasons behind thepoor performance of applications built with distributed objects. However this wasnot a problem with the distributed objects technology, but rather the symptom offine grained object interactions across system boundaries [Lub02].

Service-Oriented Architecture makes this tradeoff explicit by making service al-ways remote and consequently granularity one of the explicit goals of servicedesign. Because service invocation involves the network they are designed coarsegrained. In other words, services must deliver value that justifies the latency costof a network request. Similarly, the exposed service interfaces must be coarse-grained. Instead of exposing many interfaces that provide limited functionalityservices should expose a small number of interfaces that allow individual requeststo perform complete business function.

Proper service granularity allows not only create better performing systems, butlowers the coupling. Large grained services tend to be self-contained and as aresult have less dependencies on other services.

Loose Coupling

Loose coupling of services is a prerequisite for the ability to use them to buildand modify flexible enterprise solutions, and support a federated development ap-proach throughout the enterprise. Karin Duermeyer outlines the following conse-quences of coupling [Due]:

• Tighter coupling tends to cost more over time:

– Synchronizing multiple organizations on change

– Adapting, redeploying updated components without affecting others



DRAFTCOPY


– Making changes is hard and expensive, or impossible:

∗ Knowledge is distributed throughout the code.∗ Same people are solving business and infrastructure problems

– Different parts of the solution are difficult to manage separately.

– Hard to move, hard to scale, hard to distribute, hard to replace.

– More coupling implies more expensive testing.

• Looser coupling requires greater investment up front:

– More design work

– More implementation work

The notion of loose coupling is not new. Good object-oriented and componentsoftware development practices revolve around low coupling. Service-OrientedArchitecture takes it even further, considering the coupling in several dimensions.

Functional Coupling Although interface-based design is not new, in Service-Oriented Architecture the (service) interfaces are based on the enterprise-widesemantics. The importance of the enterprise-wide semantics for services inter-operability was downplayed by the early Service-Oriented Architecture adopters.The Web Services community hoped that the well defined content and structure ofSOAP messages, coupled with XML representation of the payload and standard-ization of the transport ensure interoperability of the Web Services communica-tion. In reality this provides only technical interoperability, ensuring that a SOAPmessage from one system can be received and successfully processed by the othersystem. However it does not help in any way with the semantic interoperability,i.e., the ability of two systems to “understand” each other.11 In order to providetrue semantic interoperability it is necessary to ensure that all services within anenterprise use the same messaging semantic model.

Data Coupling The separation of interface and implementation extends to thedata as well. Services accommodate two completely different, but equally impor-tant data models [Hel]:

11The fact that many languages use the Roman alphabet does not mean that understanding thealphabet alone allows one to also understand all these languages.



DRAFTCOPY

2.4. SERVICES

Internal data model used by services implementations. This data model relatesto the internal implementation of the service, and thus is specific to the un-derlying services and components. The internal data model is not exposedto service consumers.

External data model used for inter-service exchanges. This data model must beunderstandable by both the service and its consumers. This requirementpositions the enterprise semantic model as the logical choice for designingthe inter-service messages.

Each service is responsible for the semantic brokering, transforming between theenterprise and internal data models.

Using the enterprise data model for defining service interfaces leads to the creationof interoperable semantic interface definitions [Lub04b]. This semantic Service-Oriented Architecture provides significantly enhanced interoperability betweenservices: all of them work with the same objects at the interface level.

Temporal Coupling Services and especially Web Services publications tend tofocus on synchronous service invocations. Usage of synchronous communicationsfor service invocations creates tight temporal coupling between service consumerand provider:

• The service provider has to be up and running in order for the service con-sumer to access it.

• Because synchronous invocation is a blocking call performance changes ineither service execution or message delivery can have a significant impactat the service consumer.

Making a service call asynchronous with a separate return message allows theconsumer to continue execution while the provider has a chance to respond. Thisleads to a temporally decoupled system. Temporary service provider outages andnetwork delays have little or no impact in this case. As long as service providerreturns a response, overall system functions properly.

Services represent coarse grain singletons in the overall software system, whichmake scalability and high availability of services an extremely important issue.This means that asynchronous invocation is a significantly better fit for Service-Oriented Architecture implementations.



DRAFTCOPY


Transactional Coupling ACID transactions are usually implemented using trans-action monitors (for example Tuxedo, CICS, Encina) or component platforms(for example J2EE aplication server or MTS). This means that support for ACIDtransactions requires coupling through the transactional environment, thus limit-ing interoperability and flexibility. Another requirement for ACID transactionsimplementation is resource locking for the duration of transaction, which requiresguaranteed short execution time of services.12

ACID transactions, while perfectly appropriate for objects and components areusually too restrictive for services. Service-Oriented Architecture favors businesstransactions over the traditional two-phase commit protocol [Lub03, LF03].

2.5 Business Processes

Business Services implement basic business functionality, not entire business so-lutions. Business solutions are created by combining functionality of multipleservices together—creation of composite services. The ability to rapidly assem-ble or reassemble solutions using existing services is one of the main advantagesof Service-Oriented ArchitectureThe prevalent way of combing together multipleservices is by implementing business processes13 that orchestrate the execution ofmultiple services.

Businesses today are defined through dynamic enterprise business processes thatare constantly expanding, contracting and changing as the business progresses.Their survival requires constant management focus on business processes of alltypes. Mere data mining capabilities, used to produce key performance indicatorsof the completed processes, aren’t sufficient for sustained competitive advantage.That requires obtaining fine-grained, accurate, real-time information that mea-sures performance of the business processes.

Companies that want to increase their effectiveness and competitiveness have tomove toward making the process a basic unit of computer-based automation andsupport. They have to shift their focus from systems of record to systems ofprocesses. “Process processing” ought to replace “data processing”. The shifttoward a process-centric enterprise has BPM on everybody’s mind. At the heart of

12Longer transactions time usually leads to worsening of the overall throughput of transactionalresources.

13 In effect any service composition can be defined in the form business process



DRAFTCOPY

2.5. BUSINESS PROCESSES

BPM is the notion of “orchestration,” where a process engine orchestrates severalmanual and automatic process steps while manipulating input/output data.

Unfortunately BPM is often used for all the wrong purposes. This defeats itsfundamental purpose of redefining the way business processes are automated byorchestrating loosely coupled, self-contained process steps. Service-Oriented Ar-chitecture makes the realization of BPM more practical. Business processes inService-Oriented Architecture facilitate the next phase of business process evolu-tion from merely “automated” to “managed flexibility.” Automation shifts Service-Oriented Architecture focus to creation of services that could be reused in differ-ent ways and different processes. This shift allows enterprises to achieve dramaticimprovements in market capture, cost effectiveness and profitability.

The goal of Service-Oriented Architecture is to expose an organization’s comput-ing assets as reusable services that can communicate and integrate more readily.The dichotomy of business services and business processes pave the way to a trulyflexible enterprise:

• Business services support stable business artifacts, incorporating process-ing and rules whose interface changes fairly rarely. (Note though that theservice implementation can and typically does change frequently.)

• Business processes support fairly fluid business procedures and rules, whichcan change every few months or even weeks.

• The interaction between business processes and business services is basedon the enterprise semantics, which minimize impact of services changeson the business processes and simplifies building processes from businessservices.

Just as the object-oriented paradigm unleashed the power of code reuse, based onthe existing objects, a foundation of enterprise business services enables businessanalysts and IT architects to reuse them thru business processes. This approachshifts focus from automated business services creation to optimizing existing pro-cesses and implementing new ones. More importantly, once designed processescan be quickly modified in response to market conditions. All this translates intoincreasing the business flexibility and competitiveness without dramatically in-creasing incremental costs of making frequent process changes.



DRAFTCOPY


While traditional BPM focused on business processes, Service-Oriented Archi-tecture revolves around the business service-business process dichotomy (Fig-ure 2.6):

• Business services can be combined to deliver new, composite business func-tions or processes.

• A single business service can be reused within the context of multiple busi-ness processes.

• A business service itself can be implemented as a process.

This architectural style can be viewed as a set of design principles applicableto both service assets and process assets. Since the design approach to bothservices and process is similar, Service-Oriented Architecture provides a com-mon language for process designers (i.e., business analysts) and service design-ers (i.e., software developers) alike. In other words many of the service patternsdiscussed further in the book (e.g., service versioning, service registry, servicerepository) also apply to business processes. This resulting UBIQUITOUS LAN-GUAGE [Eva03] represents a first step towards closing the gapping chasm betweenbusiness and IT. As others observed, “enterprise software has always sufferedfrom the mismatch between technical and business-related concepts and the dif-ferent languages spoken by the people on both sides of the fence” [KBS04].



DRAFTCOPY

2.5. BUSINESS PROCESSES

Figure 2.6: Relationship between services and processes



DRAFTCOPY




DRAFTCOPY

BIBLIOGRAPHY

[Bro05] Alan W. Brown. Designing and building service-oriented solutionswith the ibm rational software development platform. In IBM IAAUser Group and Insurance Solutions Conference. IBM, Month 2005.

[Due] Karin Duermeyer. Bridging business value to SOA: SOA bestpractices. Available from http://www.websphere.org/docs/presentations/Duermeyer-SOA Executive Event Muenchen.pdf.

[Eva03] Eric Evans. Domain Driven Design. Addison-Wesley, 2003.

[Gos05] James Gosling. SOA: Buzzworld whiplash or real meat? Avail-able from http://blogs.sun.com/roller/page/jag?entry=soa buzzworld whiplash or real, September 2005.

[Gro04] W3C Working Group. Web services architecture. Available fromhttp://www.w3.org/TR/ws-arch/, February 2004.

[Hel] Pat Helland. Data on the outside vs. data on the inside. an examina-tion of the impact of service oriented architectures on data. MSDNtechnical article.

[Hub01] Richard Hubert. Convergent Architecture: Building Model DrivenJ2EE Systems with UML. Wiley, 2001.

41

http://www.websphere.org/docs/presentations/Duermeyer-SOA_Executive_Event_Muenchen.pdf



http://blogs.sun.com/roller/page/jag?entry=soa_buzzworld_whiplash_or_real

http://blogs.sun.com/roller/page/jag?entry=soa_buzzworld_whiplash_or_real

http://www.w3.org/TR/ws-arch/

DRAFTCOPY


[KBS04] Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA: Service-Oriented Architecture Best Practices. Prentice Hall PTR, 2004.

[LF03] Mark Little and Tom Freund. A comparison of web servicestransaction protocols. Developworks, October 2003. Available fromhttp://www-128.ibm.com/developerworks/webservices/library/ws-comproto/.

[LT03] Boris Lublinsky and Dimitry Tyomkin. Dissecting service-oriented architectures. Business Integration Journal, October2003. Available from http://www.bijonline.com/Article.asp?ArticleID=790&DepartmentID=9.

[Lub01a] Boris Lublinsky. Achieving the ultimate EAI implementation. EAIJournal, February 2001. Available from http://www.eaijournal.com/Article.asp?ArticleID=303&DepartmentId=7.

[Lub01b] Boris Lublinsky. Achieving the ultimate EAI implementation.part 2: Message-level integration. EAI Journal, February2001. Available from http://www.eaijournal.com/Article.asp?ArticleID=299&DepartmentId=5.

[Lub01c] Boris Lublinsky. Achieving the ultimate EAI implementa-tion. part 3: Data-level integration. EAI Journal, February2001. Available from http://www.eaijournal.com/Article.asp?ArticleID=301&DepartmentId=6.

[Lub02] Boris Lublinsky. The key to superior EJB design. Java DeveloperJournal, 7, January 2002.

[Lub03] Boris Lublinsky. Transactions and web services. EAI Journal,January 2003. Available from http://www.bijonline.com/PDF/TWSLublinsky.pdf.

[Lub04a] Boris Lublinsky. SOA design: Meet in the middle. Java Pro, August2004.

[Lub04b] Boris Lublinsky. Unifying data, documents and processes. EnterpriseArchitect, 2(2):6–11, Summer 2004.


http://www-128.ibm.com/developerworks/webservices/library/ws-comproto/

http://www-128.ibm.com/developerworks/webservices/library/ws-comproto/

http://www.bijonline.com/Article.asp?ArticleID=790&DepartmentID=9

http://www.bijonline.com/Article.asp?ArticleID=790&DepartmentID=9

http://www.eaijournal.com/Article.asp?ArticleID=303&DepartmentId=7






http://www.bijonline.com/PDF/TWSLublinsky.pdf

http://www.bijonline.com/PDF/TWSLublinsky.pdf


DRAFTCOPY

BIBLIOGRAPHY

[Obj] Object Management Group. UML 2.0 Infrastructure Specification.Available from http://www.omg.org/docs/ptc/03-09-15.pdf.

[Par72] David L. Parnas. On the criteria to be used in decomposing systemsinto modules. Communications of the ACM, 15(12), December 1972.

[RL05] Michael Rosen and Boris Lublinsky. Service-Oriented Integration:Aligning SOA with enterprise integration. In Cutter Executive Re-port, volume 8. The Cutter Consortium, January 2005.

[Sca04] Ed Scannell. IBM’s grady booch on solving complex-ity. Available from http://www.infoworld.com/article/04/02/02/HNboochint 1.html, February 2004.

[sea] Revisiting the definitive soa definition. Available from http://searchwebservices.techtarget.com/originalContent/0,289142,sid26 gci1044083,00.html.

[Tay95] David A. Taylor. Business Engineering with Object Technology. JohnWiley & Sons, 1995.

[TMQ+03] David Trowbridge, Dave Mancini, Dave Quick, Gregor Hohpe,James Newkirk, and David Lavigne. Enterprise Solution PatternsUsing Microsoft .NET Version 2.0. Microsoft Press, 2003.


http://www.omg.org/docs/ptc/03-09-15.pdf

http://www.infoworld.com/article/04/02/02/HNboochint_1.html

http://www.infoworld.com/article/04/02/02/HNboochint_1.html

http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1044083,00.html




soa service design

Documents

serviceoriented enterprise

serviceoriented architecture

service orchestration

service oriented approach

dragos manolescu

business executive

business analyst

boris lublinsky2 http