Service-oriented architectureA service-oriented architecture (SOA) is anarchitectural pattern in computer software design inwhich application components provide services to othercomponents via a communications protocol, typicallyover a network. The principles of service-orientation areindependent of any vendor, product or technology.[1]specified outcome (e.g., check customer credit, provide weather data,consolidate drilling reports)Is self-containedMay be composed of other servicesIs a “black box” to consumers of theserviceA service is a self-contained unit of functionality, suchas retrieving an online bank statement.[2] By that definition, a service is an operation that may be discretely invoked. However, in the Web Services Description Lan2 Overviewguage (WSDL), a service is an interface definition thatmay list several discrete services/operations. And elsewhere, the term service is used for a component that is Services are unassociated, loosely coupled units of funcencapsulated behind an interface. This widespread ambi- tionality that are self-contained. Each service implementsat least one action, such as submitting an online applicaguity is reflected in what follows.tion for an account, retrieving an online bank statementServices can be combined to provide the functionality of or modifying an online booking or airline ticket order.a large software application.[3] SOA makes it easier for Within a SOA, services use defined protocols that desoftware components on computers connected over a net- scribe how services pass and parse messages using dework to cooperate. Every computer can run any number scription metadata, which in sufficient detail describesof services, and each service is built in a way that en- not only the characteristics of these services, but also thesures that the service can exchange information with any data that drives them. Programmers have made extenother service in the network without human interaction sive use of XML in SOA to structure metadata that theyand without the need to make changes to the underlying wrap in a nearly exhaustive description-container. Analoprogram itself.gously, the Web Services Description Language (WSDL)typically describes the services themselves, while SOAP(originally Simple Object Access Protocol) describes the1 Definitionscommunications protocols. SOA depends on data andservices that are described by metadata that should meetThe OASIS group[4] and the Open Group[5] have both the following two criteria:created formal definitions. OASIS defines SOA as:1. The metadata should be provided in a form that softA paradigm for organizing and utilizingware systems can use to configure dynamically bydistributed capabilities that may be under thediscovery and incorporation of defined services, andcontrol of different ownership domains. It proalso to maintain coherence and integrity. For examvides a uniform means to offer, discover, inple, metadata could be used by other applications,teract with and use capabilities to produce delike a catalogue, to perform auto discovery of sersired effects consistent with measurable previces without modifying the functional contract of aconditions and expectations.service.The Open Group’s definition is:2. The metadata should be provided in a form that system designers can understand and manage with areasonable expenditure of cost and effort.Service-Oriented Architecture (SOA) isan architectural style that supports serviceorientation. Service-orientation is a way ofthinking in terms of services and service-baseddevelopment and the outcomes of services.A service:The purpose of SOA is to allow users to combine fairlylarge chunks of functionality to form ad hoc applicationsbuilt almost entirely from existing software services. Thelarger the chunks, the fewer the interfaces required toimplement any given set of functionality; however, verylarge chunks of functionality may not prove sufficientlyIs a logical representation of a repeatable business activity that has a1

25 PRINCIPLESgranular for easy reuse. Each interface brings with it 4 Design conceptsome amount of processing overhead, so there is a performance consideration in choosing the granularity of ser- SOA is based on the concept of a service. Dependingvices.on the service design approach taken, each SOA serviceSOA as an architecture relies on service-orientation as its is designed to perform one or more activities by implefundamental design principle. If a service presents a sim- menting one or more service operations. As a result, eachple interface that abstracts away its underlying complex- service is built as a discrete piece of code. This makes itity, then users can access independent services without possible to reuse the code in different ways throughoutthe application by changing only the way an individualknowledge of the service’s platform implementation.[6]service interoperates with other services that make up theapplication, versus making code changes to the serviceitself. SOA design principles are used during software3 SOA frameworkdevelopment and integration.SOA generally provides a way for consumers of serSOA-based solutions endeavour to enable business ob- vices, such as web-based applications, to be aware ofjectives while building an enterprise-quality system. available SOA-based services. For example, several disSOA architecture is viewed as five horizontal layers:[7]parate departments within a company may develop anddeploy SOA services in different implementation lan1. Consumer Interface Layer – These are GUI for end guages; their respective clients will benefit from a welldefined interface to access them.users or apps accessing apps/service interfaces.SOA defines how to integrate widely disparate applica2. Business Process Layer – These are choreographed tions for a Web-based environment and uses multiple imservices representing business use-cases in terms of plementation platforms. Rather than defining an API,applications.SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA3. Services – Services are consolidated together for implementation.whole-enterprise in-service inventory.Service-orientation requires loose coupling of serviceswith operating systems and other technologies that un4. Service Components – The components used to derlie applications. SOA separates functions into distinctbuild the services, such as functional and technical units, or services,[8] which developers make accessiblelibraries, technological interfaces etc.over a network in order to allow users to combine andreuse them in the production of applications. These ser5. Operational Systems – This layer contains the data vices and their corresponding consumers communicatemodels, enterprise data repository, technological with each other by passing data in a well-defined, sharedplatforms etc.format, or by coordinating an activity between two ormore services.[9]There are four cross-cutting vertical layers, each of which For some, SOA can be seen as part of the continuumare applied to and supported by each of the following hor- which ranges from the older concept of distributed comizontal layers:puting[8][10] and modular programming, through SOA,and on to current practices of mashups, SaaS, and cloud[11]1. Integration Layer – starts with platform integration computing (which some see as the offspring of SOA).(protocols support), data integration, service integration, application integration, leading to enterprise application integration supporting B2B andB2C.5 PrinciplesThere are no industry standards relating to the exact2. Quality of Service – Security, availability, perfor- composition of a service-oriented architecture, althoughmance etc. constitute the quality of service param- many industry sources have published their own princieters which are configured based on required SLAs, ples. Some of these[12][13][14][15] include the following:OLAs.3. Informational – provide business information.4. Governance – IT strategy is governed to each horizontal layer to achieve required operating and capability model. Standardized service contract: Services adhere to acommunications agreement, as defined collectivelyby one or more service-description documents. Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires

5.1Service architecturethat they maintain an awareness of each other.35.1 Service architecture Service abstraction: Beyond descriptions in the ser- This is the physical design of an individual service that envice contract, services hide logic from the outside compasses all the resources used by a service. This wouldnormally include databases, software components,, identity stores, XML schemas and any backing Service reusability: Logic is divided into services stores, e.g. shared directories. It is also beneficial to include any service agents employed by the service, as anywith the intention of promoting reuse.change in these service agents would affect the message Service autonomy: Services have control over the processing capabilities of the service.logic they encapsulate, from a Design-time and a The (standardized service contract) design principlerun-time perspective.keeps service contracts independent from their implementation. The service contract needs to be documented Service statelessness: Services minimize resource to formalize the required processing resources by the inconsumption by deferring the management of state dividual service capabilities. Although it is beneficialinformation when necessary[16]to document details about the service architecture, theservice abstraction design principle dictates that any in Service discoverability: Services are supplemented ternal details about the service are invisible to its conwith communicative meta data by which they can sumers so that they do not develop any unstated effectively discovered and interpreted.The service architecture serves as a point of reference forevolving the service or gauging the impact of any change Service composability: Services are effective com- in the service.position participants, regardless of the size and complexity of the composition.5.2 Service composition architecture Service granularity: A design consideration to provide optimal scope and right granular level of the One of the core characteristics of services developed usbusiness functionality in a service the service-orientation design paradigm is that theyare composition-centric. Services with this characteristic Service normalization: Services are decomposed or can potentially address novel requirements by recomposconsolidated to a level of normal form to minimize ing the same services in different configurations. Serviceredundancy. In some cases, services are denormal- composition architecture is itself a composition of the inized for specific purposes, such as performance op- dividual architectures of the participating services. In thetimization, access, and aggregation.[17]light of the Service Abstraction principle, this type of architecture only documents the service contract and any Service optimization: All else being equal, high- published service-level agreement (SLA); internal detailsquality services are generally preferable to low- of each service are not included.quality ones.If a service composition is a part of another (parent) composition, the parent composition can also be referenced Service relevance: Functionality is presented at ain the child service composition. The design of servicegranularity recognized by the user as a meaningfulcomposition also includes any alternate paths, such as erservice.ror conditions, which may introduce new services into thecurrent service composition. Service encapsulation: Many services are consolidated for use under the SOA. Often such services Service composition is also a key technique in software integration, including enterprise software integrawere not planned to be under SOA.tion, business process composition and workflow compo Service location transparency: This refers to the abil- sition.ity of a service consumer to invoke a service regardless of its actual location in the network. This alsorecognizes the discoverability property (one of the 5.3 Service inventory architecturecore principle of SOA) and the right of a consumerto access the service. Often, the idea of service A service inventory is composed of services that autovirtualization also relates to location transparency. mate business processes. It is important to account for theThis is where the consumer simply calls a logical ser- combined processing requirements of all services withinvice while a suitable SOA-enabling runtime infras- the service inventory. Documenting the requirements oftructure component, commonly a service bus, maps services, independently from the business processes thatthis logical service call to a physical service.they automate, helps identify processing bottlenecks. The

48 ESB IN CONTEXT OF SOAservice inventory architecture is documented from theservice inventory blueprint, so that service candidates[18]can be redesigned before their implementation.5.4Service-oriented enterprise architectureThis umbrella architecture incorporates service, composition, and inventory architectures, plus any enterprisewide technological resources accessed by these architectures e.g. an ERP system. This can be further supplemented by including enterprise-wide standards that applyto the aforementioned architecture types. Any segmentsof the enterprise that are not service-oriented can also bedocumented in order to consider transformation requirements if a service needs to communicate with the business processes automated by such segments. SOA’s maingoal is to deliver agility to business.6Web services approachWeb services can implement a service-orientedarchitecture.[19] They make functional building-blocksaccessible over standard Internet protocols independent of platforms and programming languages. Theseservices can represent either new applications or justwrappers around existing legacy systems to make themnetwork-enabled.look-up requests, number of listings or accuracy ofthe listings. The Universal Description Discoveryand Integration (UDDI) specification defines a wayto publish and discover information about Web services. Other service broker technologies include(for example) ebXML (Electronic Business usingeXtensible Markup Language) and those based onthe ISO/IEC 11179 Metadata Registry (MDR) standard.2. Service consumer: The service consumer or web service client locates entries in the broker registry usingvarious find operations and then binds to the serviceprovider in order to invoke one of its web services.Whichever service the service-consumers need, theyhave to take it into the brokers, bind it with respective service and then use it. They can access multipleservices if the service provides multiple services.7 Web service protocolsSee also: List of web service protocolsImplementers commonly build SOAs using web servicesstandards (for example, SOAP) that have gained broadindustry acceptance after recommendation of Version1.2 from the W3C[20] (World Wide Web Consortium)Each SOA building block can play one or both of two in 2003. These standards (also referred to as web serroles:vice specifications) also provide greater interoperabilityand some protection from lock-in to proprietary ven1. Service provider: The service provider creates a dor software. One can, however, implement SOA usingweb service and possibly publishes its interface and any service-based technology, such as Jini, CORBA oraccess information to the service registry. Each REST.provider must decide which services to expose, howto make trade-offs between security and easy availability, how to price the services, or (if no chargesapply) how/whether to exploit them for other value.8 ESB in context of SOAThe provider also has to decide what category theservice should be listed in for a given broker service and what sort of trading partner agreements While knowing this it is obvious that even peer-to-peerare required to use the service. It registers what applications are no direct linkages and require the midservices are available within it, and lists all the po- dleware agent as well. Otherwise the endpoints needtential service recipients. The implementer of the to program logic to wait for delayed server response,broker then decides the scope of the broker. Pub- network errors, security and encryption and any kindlic brokers are available through the Internet, while of Quality of Service. The more endpoints exchangeprivate brokers are only accessible to a limited au- information mutually the more the need arises for adience, for example, users of a company intranet. well-designed middleware. Such a middleware that proFurthermore, the amount of the offered informa- vides standardized communication services in a multition has to be decided. Some brokers specialize in peer client server architecture is labelled Enterprise Sermany listings. Others offer high levels of trust in vice Bus (ESB). The services provided by an ESB exists inthe listed services. Some cover a broad landscape of any communication, however often they are programmedservices and others focus within an industry. Some individually; they comprise such services like routing, filbrokers catalog other brokers. Depending on the tering, QoS, encryption, archiving, message queuing, logbusiness model, brokers can attempt to maximize ging, communication trace and others.

59Other SOA conceptsArchitectures can operate independently of specific technologies and can therefore be implemented using a widerange of technologies, including: SOAP, RPC REST DCOM CORBA OPC-UASOA meta-model, The Linthicum Group, 2007 Web services DDS Java RMI WCF (Microsoft’s implementation of web servicesnow forms a part of WCF) Apache Thrift SORCERImplementations can use one or more of these protocolsand, for example, might use a file-system mechanism tocommunicate data following a defined interface specification between processes conforming to the SOA concept.The key is independent services with defined interfacesthat can be called to perform their tasks in a standard way,without a service having foreknowledge of the calling application, and without the application having or needingknowledge of how the service actually performs its tasks.Service-Oriented Modeling Framework (SOMF) Version 2.0These services inter-operate based on a formal definition(or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the languagespecific service. SOA-based systems can therefore function independently of development technologies and platforms (such as Java, .NET, etc.). Services written inC# running on .NET platforms and services written inJava running on Java EE platforms, for example, canboth be consumed by a common composite application(or client). Applications running on either platform canalso consume services running on the other as web services that facilitate reuse. Managed environments canalso wrap COBOL legacy systems and present them assoftware services.[23]High-level languages such as BPEL and specificationssuch as WS-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine-grained services into moreElements of SOA, by Dirk Krafzig, Karl Banke, and Dirkcoarse-grained business services, which architects can in[21]Slamaturn incorporate into workflows and business processes[24]SOA enables the development of applications that are implemented in composite applications or portals.built by combining loosely coupled and interoperable Service-oriented modeling[8] is an SOA framework thatservices.[22]identifies the various disciplines that guide SOA practi-

611tioners to conceptualize, analyze, design, and architecttheir service-oriented assets. The Service-oriented modeling framework (SOMF) offers a modeling language anda work structure or “map” depicting the various components that contribute to a successful service-orientedmodeling approach. It illustrates the major elements thatidentify the “what to do” aspects of a service development scheme. The model enables practitioners to craft aproject plan and to identify the milestones of a serviceoriented initiative. SOMF also provides a common modeling notation to address alignment between business andIT organizations.10Organizational benefitsSome enterprise architects believe that SOA canhelp businesses respond more quickly and more costeffectively to changing market conditions.[25] This styleof architecture promotes reuse at the macro (service) levelrather than micro (classes) level. It can also simplify interconnection to—and usage of—existing IT (legacy) assets.With SOA, the idea is that an organization can look ata problem holistically. A business has more overall control. Theoretically there would not be a mass of developers using whatever tool sets might please them. Butrather they would be coding to a standard that is set withinthe business. They can also develop enterprise-wide SOAthat encapsulates a business-oriented infrastructure. SOAhas also been illustrated as a highway system providingefficiency for car drivers. The point being that if everyone had a car, but there was no highway anywhere,things would be limited and disorganized, in any attemptto get anywhere quickly or efficiently. IBM Vice President of Web Services Michael Liebow says that SOA“builds highways”.[26]In some respects, SOA could be regarded as an architectural evolution rather than as a revolution. It capturesmany of the best practices of previous software architectures. In communications systems, for example, littledevelopment of solutions that use truly static bindings totalk to other equipment in the network has taken place.By formally embracing a SOA approach, such systemscan position themselves to stress the importance of welldefined, highly inter-operable interfaces.[27]A service comprises a stand-alone unit of functionalityavailable only via a formally defined interface. Servicescan be some kind of “nano-enterprises” that are easyto produce and improve. Also services can be “megacorporations” constructed as the coordinated work ofsubordinate services.CHALLENGES1. Separation promotes the concept to the business thatservices can be delivered quickly and independentlyfrom the larger and slower-moving projects commonin the organization. The business starts understanding systems and simplified user interfaces calling onservices. This advocates agility. That is to say, itfosters business innovations and speeds up time-tomarket.[28]2. Separation promotes the decoupling of servicesfrom consuming projects. This encourages good design insofar as the service is designed without knowing who its consumers are.3. Documentation and test artifacts of the service arenot embedded within the detail of the larger project.This is important when the service needs to bereused later.An indirect benefit of SOA involves dramatically simplified testing. Services are autonomous, stateless, withfully documented interfaces, and separate from the crosscutting concerns of the implementation.If an organization possesses appropriately defined testdata, then a corresponding stub is built that reacts to thetest data when a service is being built. A full set of regression tests, scripts, data, and responses is also captured forthe service. The service can be tested as a 'black box'using existing stubs corresponding to the services it calls.Test environments can be constructed where the primitiveand out-of-scope services are stubs, while the remainderof the mesh is test deployments of full services. As eachinterface is fully documented with its own full set of regression test documentation, it becomes simple to identifyproblems in test services. Testing evolves to merely validate that the test service operates according to its documentation, and finds gaps in documentation and test casesof all services within the environment. Managing the datastate of idempotent services is the only complexity.Examples may prove useful to aid in documenting a service to the level where it becomes useful. The documentation of some APIs within the Java Community Process provide good examples. As these are exhaustive,staff would typically use only important subsets. The 'ossjsa.pdf' file within JSR-89 exemplifies such a file.[29]11 ChallengesOne obvious and common challenge faced involves managing services metadata.[30] SOA-based environmentscan include many services that exchange messages to perform tasks. Depending on the design, a single application may generate millions of messages. Managing andA mature rollout of SOA effectively defines the API of providing information on how services interact can bean organization.come complex. This becomes even more complicatedReasons for treating the implementation of services as when these services are delivered by different organizaseparate projects from larger projects include:tions within the company or even different companies

7(partners, suppliers, etc.). This creates huge trust issues provider needs to retain the shared context for each conacross teams; hence SOA Governance comes into the pic- sumer. It also increases the coupling between a serviceture.provider and a consumer and makes switching service[39]Ultimately, some critics feelAnother challenge involves the lack of testing in SOA providers more difficult.thatSOAservicesarestilltooconstrained by applicationsspace. There are no sophisticated tools that provide[40]theyrepresent.testability of all headless services (including message anddatabase services along with web services) in a typicalarchitecture. Lack of horizontal trust requires that bothproducers and consumers test services on a continuousbasis. It is important to invest in a testing framework(build it or buy it) that would provide the visibility required to find the culprit in the architecture. Businessagility requires SOA services to be controlled by the business goals and directives as defined in the business Motivation Model (BMM).[31]Another concern relates to the ongoing evolution of WS* standards and products (e. g., transaction, security),and SOA can thus introduce new risks unless properlymanaged and estimated with additional budget and contingency for additional proof-of-concept work.Significant vendor hype surrounds SOA, which can create exaggerated expectations. Product stacks continue toevolve as early adopters test the development and runtime products with real-world problems. SOA does notguarantee reduced IT costs, improved systems agility orshorter time to market. Successful SOA implementationsmay realize some or all of these benefits depending onthe quality and relevance of the system architecture anddesign.[33][34]In October 2009, at the 2nd International SOA Symposium, a mixed group of 17 independent SOA practitioners and vendors, the “SOA Manifesto Working Group,”announced the publication of the SOA Manifesto.[41] TheSOA Manifesto is a set of objectives and guiding principles that aim to provide a clear understanding and visionof SOA and service-orientation. Its purpose is rescuingthe SOA concept from an excessive use of the term by thevendor community and “a seemingly endless proliferationof misinformation and confusion.”[42]The next step in the design process covers the definitionof a service delivery platform (SDP) and its implementation. In the SDP design phase one defines the businessinformation models, identity management, products, conInteroperability becomes an important aspect of SOA im- tent, devices, and the end-user service characteristics, asplementations. The WS-I organization has developed ba- well as how agile the system is so that it can deal with thesic profile (BP) and basic security profile (BSP) to en- evolution of the business and its customers.force compatibility.[32] WS-I has designed testing tools tohelp assess whether web services conform to WS-I profileguidelines. Additionally, another charter has been estab- 13 SOA Manifestolished to work on the Reliable Secure Profile.12CriticismsThe manifesto provides a broad definition of SOA, thevalues it represents for the signatories and some guidingprinciples. The manifesto prioritizes:Some criticisms of SOA depend on conflating SOA withWeb services.[35] In the absence of native or binary forms Business value over technical strategyof remote procedure call (RPC), applications could run Strategic goals over project-specific benefitsmore slowly and require more processing power, increasing costs. Most implementations do incur these over Intrinsic interoperability over custom integrationheads, but SOA can be implemented using technologies(for example, Java Business Integration (JBI), Windows Shared services over specific-purpose implementaCommunication Foundation (WCF) and data distributionstion service (DDS)) that do not depend on remote procedure calls or translation through XML. At the same time, Flexibility over optimizationemerging open-source XML parsing technologies (such Evolutionary refinement over pursuit of initial peras VTD-XML) and various XML-compatible binary forfectionmats promise to significantly improve SOA performance.Services implemented using JSON instead of XML donot suffer from this performance concern.[36][37][38]As of September 2010, the SOA Manifesto had beenStateful services require both the consumer and the signed by more than 700 signatories and had been transprovider to share the same consumer-specific context, lated to nine languages.which is either included in or referenced by messages exchanged between the provider and the consumer. Thisconstraint has the drawback that it could reduce the 14 Extensionsoverall scalability of the service provi

Service-oriented architecture implementation framework Service(systemsarchitecture) SOAgovernance SOALIB Web-orientedarchitecture 16 References [1] Chapter 1: Service Oriented Architecture (SOA).,20