Service-oriented architecture In computing, Service-oriented architecture (SOA) provides methods for systems development and integration where systems

group functionality around business processes and package these as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies which underlie applications.[1] SOA separates functions into distinct units, or services[2], which developers make accessible over a network in order that users can combine and reuse them in the production of business applications.[3] These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. Many commentators[who?] see SOA concepts as built upon and evolving from older concepts of distributed computing[3][2] and modular programming. [edit] Description [edit] Overview

A Service-Oriented Architecture Companies have long sought to integrate existing systems in order to implement information technology (IT) support for business processes that cover all present and prospective systems requirements needed to run the business end-to-end. A variety of designs serve this end, ranging from rigid point-to-point electronic data interchange (EDI) interactions to web auctions. By updating older technologies, for example by Internet-enabling EDI-based systems, companies can make their IT systems available to internal or external customers; but the resulting systems have not proven flexible enough to meet business demands,[citation needed] which require[citation needed] a flexible, standardized architecture to better support the connection of various applications and the sharing of data. SOA offers one such architecture. It unifies business processes by structuring large applications as an ad hoc collection of smaller modules called "services". Different groups of people both inside and outside an organization can use these applications, and new applications built from a mix of services from the global pool exhibit greater flexibility and uniformity.[citation needed] One should not, for example, have to provide redundantly the same personal information to open an online checking, savings or IRA account, and further, the interfaces one interacts with should have the same look and feel and use the same level and type of input data validation.[citation needed] Building all applications from the same pool of services makes achieving this goal much easier and more deployable to affiliate companies. For example: interacting with a rental-car company's reservation system even doing so from an airline's reservation system. Service Oriented Architecture (SOA) provides a design framework for realizing rapid and low-cost system development and improving total system quality. SOA uses the Web services standards and technologies and is rapidly becoming[when?] a standard approach for enterprise information systems.

Web services face significant challenges because of particular requirements. Applying the SOA paradigm to a real-time system throws up many problems, which include response time, support of event-driven, asynchronous parallel applications, complicated human interface support, reliability, etc. This article defines SOA and includes detailed discussion on several issues that arise when applying SOA to industrial systems. [edit] Introduction One can define a service-oriented architecture (SOA) as a group of services that communicate with each other. The process of communication involves either simple data-passing or two or more services coordinating some activity. Intercommunication implies the need for some means of connecting services to each other. SOAs build applications out of software services. Services comprise intrinsically unassociated units of functionality that have no calls to each other embedded in them. They typically implement functionality most humans would recognize as a service, such as filling out an online application for an account, viewing an online bank-statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code, they use defined protocols which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement. Relative to typical practices of earlier attempts to promote software reuse via modularity of functions, or by use of predefined groups of functions known as classes, SOA's atomic-level objects are often 100 to 1,000 times larger.[citation needed] An application designer or engineer associates SOA objects by using orchestration. In the process of orchestration, a software engineer or process engineer associates relatively large chunks of software functionality (services) in a non-hierarchical arrangement (in contrast to a class hierarchy) by using a special software tool which contains an exhaustive list of all of the services, their characteristics, and a means to record the designer's choices which the designer can manage and the software system can consume and use at run-time. Underlying and enabling all of this one requires metadata in sufficient detail to describe not only the characteristics of these services, but also the data that drives them. Programmers have made extensive use of XML in SOA to create data which is wrapped in a nearly exhaustive description container. Analogously, the services themselves are typically described by WSDL, and communications protocols by SOAP. Whether these description languages are the best possible for the job, and whether they will remain the favorites in the future, remains an open question. In the meantime SOA depends on data and services that are described using some implementation of metadata which meets the following two criteria: 1. the metadata must be in a form which software systems can use to configure themselves dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity 2. the metadata must also be in a form which system designers can understand and manage at a reasonable cost and effort

SOA has the goal of allowing fairly large chunks of functionality to be strung together to form ad hoc applications which are built almost entirely from existing software services. The larger the chunks, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not prove granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA suggests that the marginal cost of creating the n-th application is zero, as all of the software required already exists to satisfy the requirements of other applications. Ideally, one requires only orchestration to produce a new application. For this to operate, no interactions must exist between the chunks specified within the chunks themselves. Instead, the interaction of services (all of which are unassociated peers) is specified by humans in a relatively ad hoc way with the intent driven by newly emergent business requirements. Thus the need for services as much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. Programmers develop the services themselves using traditional languages like Java, C#, C++, C or COBOL. SOA services feature loose coupling, in contrast to the functions a linker binds together to form an executable, a dynamically linked library, or an assembly. SOA services also run in "safe" wrappers such as Java or .NET, and other programming languages that manage memory allocation and reclamation, allow ad hoc and late binding, and provide some degree of indeterminate data typing. As of 2008, increasing numbers of third-party software companies[citation needed] offer software services for a fee. In the future, SOA systems may consist of such thirdparty services combined with others created in-house. This has the potential to spread costs over many customers, and customer uses, and promotes standardization both in and across industries. In particular, the travel industry now has a well-defined and documented set of both services and data, sufficient to allow any reasonably competent software engineer to create travel-agency software using entirely off-the-shelf software services. Other industries, such as the finance industry, have also started making significant progress in this direction. SOA as an architecture relies on service-orientation as its fundamental design principle.[4] In a SOA environment, users can access independent services without knowledge of their underlying platform implementation.[5] SOA relies on services exposing their functionality via interfaces which other applications and services can read to understand how to utilize those services. [edit] Requirements In order to efficiently use a SOA, one must meet the following requirements: Interoperability between different systems and programming languages provides the basis for integration between applications on different platforms through a communication protocol. One example of such communication is based on the concept of messages. Using messages across defined message channels decreases the complexity of the end application thereby allowing the

developer of the application to focus on true application functionality instead of the intricate needs of a communication protocol. Desire to create a federation of resources. Establish and maintain data flow to a federated data warehouse. This allows new functionality developed to reference a common business format for each data element.

[edit] Principles The following guiding principles define the ground rules for development, maintenance, and usage of the SOA:[6]: Reuse, granularity, modularity, composability, componentization, portability, and interoperability Standards compliance (both common and industry-specific) Services identification and categorization, provisioning and delivery, and monitoring and tracking

The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design: Service encapsulation - Many web-services are consolidated to be used under the SOA. Often such services were not planned to be under SOA. Service loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world Service reusability - Logic is divided into services with the intention of promoting reuse Service composability - Collections of services can be coordinated and assembled to form composite services Service autonomy Services have control over the logic they encapsulate Service optimization All else equal, high-quality services are generally considered preferable to low-quality ones Service discoverability Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms[7]

The following references provide additional considerations for defining a SOA implementation: SOA Reference Architecture provides a working design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc.[8] Life cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an

appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information. In addition, the following factors should be taken into account when defining a SOA implementation: efficient use of system resources service maturity and performance EAI Enterprise Application Integration

[edit] Web services approach Web services can implement a service-oriented architecture. Web services make functional building blocks accessible over standard Internet protocols independent of platforms and programming languages. These services can be new applications or just wrapped around existing legacy systems to make them network-enabled. Each SOA building block can play one or both of two roles:

1. Service provider

The service provider creates a Web service and possibly publishes its interface and access information to the service registry. Each provider must decide which services to expose, how to make trade-offs between security and easy availability, how to price the services, or, if they are free, how to exploit them for other value. The provider also has to decide what category the service should be listed in for a given broker service and what sort of trading partner agreements are required to use the service. It registers what services are available with in it, and lists all the potential service recipients. The implementer of the broker then decides the scope of the broker. Public brokers are available through the Internet, while private brokers are only accessible to a limited audience, for example, users of a company intranet. Furthermore, the amount of the offered information has to be decided. Some brokers specialize in many listings. Others offer high levels of trust in the listed services. Some cover a broad landscape of services and others focus within an industry. There are also brokers that catalog other brokers. Depending on the business model, brokers can attempt to maximize look-up requests, number of listings or accuracy of the listings. The Universal Description Discovery and Integration (UDDI) specification defines a way to publish and discover information about Web services. Other service broker technologies include for example ebXML (Electronic Business using eXtensible Markup Language) and those based on the ISO/IEC 11179 Metadata Registry (MDR) standard.List all the services provided by various service providers. 2. Service requester The service requester or Web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its Web services.This Brokers will look for services. Which service they need they have to take into the Brokers then bind with respective service then use it. They can access multiple, if the service provide multiple services. [edit] SOA and web service protocols

This section does not cite any references or sources. Please help improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed. (June 2006) Implementors commonly build SOAs using Web services standards (for example, using SOAP) that have gained broad industry acceptance. These standards (also referred to as Web Service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. One can, however, implement SOA using any service-based technology, such as Jini, CORBA or REST. [edit] Other SOA concepts Architectures can operate independently of specific technologies.[3] Designers can implement SOA using a wide range of technologies, including SOAP, REST, RPC, DCOM, CORBA, Web Services or WCF (Microsoft's implementation of Webservice forms a part of WCF). SOA can be implemented using one or more of these protocols and, for example, might use a file-system mechanism to communicate data conforming to a defined interface-specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that 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 needing knowledge of how the service actually performs its tasks.

Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall, 2005 SOA Meta Model, The Linthicum Group, 2007

Service-Oriented Modeling Framework (SOMF) Version 2.0 One can also regard SOA as a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services.[9] These 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 language-specific service. SOA-based systems can therefore function independently of development technologies and platforms (such as Java, .NET etc). Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as Web services, which facilitates reuse. Managed environments

can also wrap COBOL legacy systems and present them as software services. This has extended the useful life of many core legacy systems indefinitely, no matter what language they originally used. SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services. High-level languages such as BPEL and specifications such as WS-CDL and WSCoordination extend the service concept by providing a method of defining and supporting orchestration of fine grained services into more coarse-grained business services, which architects can in turn incorporate into workflows and business processes implemented in composite applications or portals[citation needed]. The use of Service Component Architecture (SCA) to implement SOA is a current area of research. How can a SOA address interoperability and reusability challenges of computing environments and simplify the heterogeneous business and technological landscapes built over decades? SOA introduces another concept to help practitioners to understand their complex environments by modeling practices. These disciplines are introduced by the Service-Oriented Modeling paradigm [2], a SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented assets. Thus, the ServiceOriented Modeling Framework (SOMF) is a work structure, a "map" depicting the various components that contribute to a successful service-oriented modeling approach. It illustrates the major elements that identify the what to do aspects of a service development scheme. These modeling pillars enable practitioners to craft an effective project plan and to identify the milestones of a service-oriented initiative either a small project or large-scale business or a technological venture. SOMF also provides a common language, a modeling notation to address one of the major intrinsic collaboration requirements of our times: alignment between business and IT organizations. This crucial vocabulary, if employed, can also illustrate the following SOA principles: Business Traceability Architectural Best-Practices Traceability Technological Traceability SOA Value Proposition Software Assets Reuse SOA Integration Strategies Technological Abstraction and Generalization Architectural Components Abstraction

"Service-Oriented Modeling Framework (SOMF) Example". "Download SOMF Examples & Language Notation".

[edit] SOA definitions

SOA is a design for linking computational resources (principally applications and data) on demand to achieve the desired results for service consumers (either end users or other services). OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following: A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. There are multiple definitions of SOA, The OASIS group and the Open Group have created formal definitions with depth which can be applied to both the technology and business domains. Open Group SOA Definition (SOA-Definition)[10] OASIS SOA Reference Model (SOA-RM)[11]

In addition, SOA is an approach to architecture whereby business services are the key organizing principles that drive the design of IT to be aligned with business needs. [edit] Service contract A service contract needs[citation needed] to have the following components: Header o Name - Name of the service. Should indicate in general terms what it does, but not be the only definition o Version - The version of this service contract o Owner - The person/team in charge of the service o RACI Responsible - The role/person/team responsible for the deliverables of this contract/service. All versions of the contract Accountable - Ultimate Decision Maker in terms of this contract/service Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision. Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action. o Type - This is the type of the service to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include: Presentation Process Business Data Integration

Functional o Functional Requirement (from Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished. o Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides. o Invocation - Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for an internal and external clients each with a different invocation means and interface. Examples: SOAP REST Events Triggers Non-Functional o Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke. o Quality of Service - Determines the allowable failure rate o Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that? o Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions o Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service o Process - Describes the process, if any, of the contracted service

[edit] SOA and business architecture SOA has gained ground as a mechanism for defining business services[12] and operating models (e.g., Business-Agile Enterprise) and thus provide a structure for IT to deliver against the actual business requirements and adapt in a similar way to the business. The purpose of using SOA as a business mapping tool is to ensure that the services created properly represent the business view and are not just what technologists think the business services should be. At the heart of SOA planning is the process of defining architectures for the use of information in support of the business, and the plan for implementing those architectures [13]. Enterprise Business Architecture should always represent the highest and most dominant architecture. Every service should be created with the intent to bring value to the business in some way and must be traceable back to the business architecture. Within this area, IBM announced SOMA (service-oriented modeling and architecture[14]) as the first publicly announced SOA-related methodology in 2004. Since then, efforts have been made to move towards greater standardization and the involvement of business objectives, particularly within the OASIS standards group and specifically the SOA Adoption Blueprints group. All of these approaches take a fundamentally structured approach to SOA, focusing more on the Services and Architecture elements and leaving implementation to the more technically focused standards. Another pertinent example is SAP Enterprise Services Architecture, which is focused on a strict governance process and the use of semantics to improve the usefulness of services in business process innovation.

[edit] SOA and network management architecture The principles of SOA are currently being applied to the field of network management. Examples of service-oriented network management architectures are TS 188 001 NGN Management OSS Architecture from ETSI, and M.3060 Principles for the Management Of Next Generation Networks recommendation from the ITU-T. Tools for managing SOA infrastructure include: HP Management Software / Mercury SOA Manager HyPerformix IPS Performance Optimizer IBM Tivoli Framework

[edit] Discussion [edit] Benefits Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing market conditions[15] . This style of architecture promotes reuse at the macro(service) level rather than micro(classes) level. It can also simplify interconnection to - and usage of - existing IT (legacy) assets. In some respects, one can regard SOA as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures. In communications systems, for example, little development has taken place of solutions that use truly static bindings to talk to other equipment in the network. By formally embracing a SOA approach, such systems are better positioned to stress the importance of well-defined, highly inter-operable interfaces.[16] Some[who?] have questioned whether SOA is just a revival of modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s)[citation needed]. SOA promotes the goal of separating users (consumers) from the service implementations. Services can therefore be run on various distributed platforms and be accessed across networks. This can also maximize reuse of services[citation needed]. SOA is an architectural and design discipline conceived to achieve the goals of increased interoperability (information exchange, reusability, and composability), increased federation (uniting resources and applications while maintaining their individual autonomy and self-governance), and increased business and technology domain alignment. Service-Oriented Architecture (SOA) is an architectural approach (or style) for constructing complex software-intensive systems from a set of universally interconnected and interdependent building blocks, called services. SOA realizes its business and IT benefits through utilizing an analysis and design methodology when creating services that ensures they are consistent with the architectural vision and roadmap and adhere to principles of service-orientation. Arguments supporting the business and management aspects from SOA are outlined in various publications.[17]

A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of "nano-enterprises" which are easy to produce and improve. Also services can be "mega-corporations" which are constructed as coordinated work of sub-ordinate services . Services generally adhere to the following principles of service-orientation: formal contract loose coupling abstraction reusability autonomy statelessness discoverability composability

[edit] Challenges in adopting SOA One obvious and common challenge faced involves managing services metadata[citation needed]. SOA-based environments can include many services which exchange messages to perform tasks. Depending on the design, a single application may generate millions of messages. Managing and providing information on how services interact is a complicated task. This becomes even more complicated when these services are delivered by different organizations within the company or even different companies (partners, suppliers, etc). This creates huge trust issue across teams, and hence SOA Governance comes into picture. Another challenge involves the lack of testing in SOA space. There are no sophisticated tools that provide testability of all headless services (including message and database services along with web services) in a typical architecture. Lack of horizontal trust requires that both producers and consumers test services on a continuous basis. SOA's main goal is to deliver Agility to Businesses. Therefore it is important to invest in a testing framework (build or buy) that would provide you with the visibility required to find the culprit in your architecture in no time. Another challenge relates to providing appropriate levels of security. Security models built into an application may no longer be appropriate when the capabilities of the application are exposed as services that can be used by other applications. That is, application-managed security is not the right model for securing services. A number of new technologies and standards are emerging to provide more appropriate models for security in SOA. See SOA Security entry for more info. As SOA and the WS-* specifications practitioners constantly expand, update and refine their output, there is a shortage of skilled people to work on SOA based systems, including the integration of services and construction of services infrastructure. Interoperability becomes an important aspect of SOA implementations. The WS-I organization has developed Basic Profile (BP) and Basic Security Profile (BSP) to enforce compatibility.[18] Testing tools have been designed by WS-I to help assess

whether web services are conformant with WS-I profile guidelines. Additionally, another Charter has been established to work on the Reliable Secure Profile. Significant vendor hype exists concerning SOA; this can create expectations that may not be fulfilled. Product stacks continue to evolve as early adopters test the development and runtime products with real-world problems. SOA does not guarantee reduced IT costs, improved systems agility or faster time to market. Successful SOA implementations may realize some or all of these benefits depending on the quality and relevance of the system architecture and design.[19] [20] [edit] Criticisms of SOA Some criticisms[21] of SOA depend on the assumption that SOA is just another term for Web Services. For example, some critics[who?] claim SOA results in the addition of XML layers introducing XML parsing and composition. In the absence of native or binary forms of Remote Procedure Call (RPC) applications could run slower and require more processing power, increasing costs. Most implementations do incur these overheads, but SOA can be implemented using technologies (for example, Java Business Integration (JBI)) which do not depend on remote procedure calls or translation through XML. At the same time, there are emerging, open-source XML parsing technologies, such as VTD-XML, and various XML-compatible binary formats that promise to significantly improve the SOA performance[22][23][24]. Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. This constraint has the drawback that it could reduce the overall scalability of the service provider because it might need to remember the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult. Another concern is that WS-* standards and products are still evolving (e.g., transaction, security), and SOA can thus introduce new risks unless properly managed and estimated with additional budget and contingency for additional Proof of Concept work. Some critics[who?] feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc). A SOA being an architecture is the first stage of representing the system components that interconnect for the benefit of the business. At this level a SOA is just an evolution of an existing architecture and business functions. SOAs are normally associated with interconnecting back end transactional systems that are accessed via web services. The real issue with any IT "architecture" is how one defines the information management model and operations around it that deal with information privacy, reflect the business's products and services, enable services to be delivered to the customers, allow for self care, preferences and entitlements and at the same time embrace identity management and agility. On this last point, system modification (agility) is a critical issue which is normally omitted from IT system design. Many systems, including SOAs, hard code the operations, goods and services of the

organization thus restricting their online service and business agility in the global marketplace. Adopting SOAs is therefore just the first step in defining a real business system. The next step in the design process covers the definition of a Service Delivery Platform (SDP) and its implementation. It is in the SDP design phase where one defines the business information models, identity management, products, content, devices, and the end user service characteristics, as well as how agile the system is so that it can deal with the evolution of the business and its customers. [edit] Extensions [edit] SOA, Web 2.0, and mashups Web 2.0 refers to a "second generation" of web sites, primarily distinguished by the ability of visitors to contribute information for collaboration and sharing. Web 2.0 applications use Web services and may include Ajax, Flash, or JavaFX userinterfaces, Web syndication, blogs, and wikis. While there are no set standards for Web 2.0, it is characterised by building on the existing web server architecture and using services. Web 2.0 can therefore be regarded as displaying some SOA characteristics[25] [26] [27]. Some commentators[who?] also regard mashups as Web 2.0 applications. The term "enterprise mashup" has been coined to describe Web applications that combine content from more than one source into an integrated experience which share many of the characteristics of service-oriented business applications (SOBAs). SOBAs are applications composed of services in a declarative manner. There is ongoing debate about "the collision of Web 2.0, mashups, and SOA," with some stating that Web 2.0 applications are a realization of SOA composite and business applications. [28] [edit] Internet of Services Tim O'Reilly coined the term Web 2.0 to describe a perceived quickly growing set of Web based applications[29]. A topic that has experienced enormous coverage recently involves the relationship between Web 2.0 and Service-Oriented Architectures (SOAs). SOA is considered as the philosophy of encapsulating application logic in services with a uniformly defined interface and making these publicly available via discovery mechanisms. The notion of complexity-hiding and reuse, but also the concept of loosely coupling services has inspired researchers to elaborate on similarities between the two philosophies SOA and Web 2.0 and their respective applications. Some argue Web 2.0 and SOA have significantly different elements and thus can not be regarded parallel philosophies, whereas others consider the two concepts as complementary and regard Web 2.0 as the global SOA [30]. The philosophies of Web 2.0 and SOA serve different user needs and thus expose differences with respect to the design and also the technologies used in real-world applications. However, very recently, numerous novel use-cases demonstrate the great potential of combining technologies and principles of both Web 2.0 and SOA. [31] .

In an "Internet of Services", all people, machines, and goods will have access via the network infrastructure of tomorrow. The Internet will thus offer services for all areas of life and business, such as virtual insurance, online banking and music, and so on. Those services will require a complex services infrastructure including Service delivery platforms bringing together demand and supply. Building blocks for the Internet of Services are SOA, Web2.0 and Semantics on the Technology side as well as novel business models, and approaches to systematic and community based innovation. Rainer Ruggaber's Talk at the WETICE 2007 conference will motivate and describe the Vision of the Internet of Services, its building blocks, relevant early initiatives and open research questions. [32]. [edit] SOA 2.0 or Advanced SOA Oracle has started taking up SOA 2.0 as "the next-generation version of SOA" combining service-oriented architecture and Event Driven Architecture, and categorizing the first iteration of SOA as client-server driven.[33] Even though Oracle indicates that Gartner is coining a new term, Gartner analysts indicate that they call this advanced SOA and it is "whimsically" referred to as SOA 2.0.[34] Most of the major middleware vendors (e.g., webMethods, TIBCO Software, IBM, Sun Microsystems, and Oracle) have had some form of SOA 2.0 attributes for years. However, some other industry commentators[who?] have criticized attaching a version number ("2.0") to an application-architecture design-approach, while others[who?] have stated that the "next generation" should apply to the evolution of SOA techniques from IT optimization to business development.[35]

Service-oriented architecture (SOA) definition What Is Service-Oriented Architecture by Hao He September 30, 2003 "Things should be made as simple as possible, but no simpler." -- Albert Einstein Introduction Einstein made that famous statement many decades ago, and it's still relevant today for building superior software systems. Unfortunately, as anyone who has been in the IT industry for long can point out, far too many software systems have failed Einstein's test. Some are made too simple to carry out the duties they are supposed to perform. Others are made too complex, and the costs of building and maintaining them have rocketed, not to mention the nearly impossible tasks of integrating different systems together. It seems that reaching the right level of simplicity is more like a dream than reality. Where have we gone wrong?

Related Reading

Loose Coupling We don't have to look far to find the problems. As we build more and more software systems, we see similar situations and patterns appearing. Naturally, we want to reuse the functionality of existing systems rather than building them from scratch. A real dependency is a state of affairs in which one system depends on the functionality provided by another. If the world only contained real dependencies, Einstein's test would have been satisfied long time ago. The problem is that we also create artificial dependencies along with real dependencies. If you travel overseas on business, you know that you must bring power adapters along with you or your life will be miserable. The real dependency is that you need power; the artificial dependency is that your plug must fit into the local outlet. Looking at all the varying sizes and shapes of those plugs from different countries, you would notice that some of them are small and compact while many others are big and bulky.

Web Services Essentials Distributed Applications with XML-RPC, SOAP, UDDI & WSDL By Ethan Cerami Table of Contents Index Sample Chapter Read Online-Safari Search this book on Safari:

Code Fragments only

The lesson here is that we cannot remove artificial dependencies, but we can reduce them. If the artificial dependencies among systems have been reduced, ideally, to their minimum, we have achieved loose coupling. In that sense, Einstein was just talking about was loose coupling. We might rework his famous principle thus: "Artificial dependencies should be reduced to the minimum but real dependencies should not be altered." SOA Defined and Explained Now we are able to define a Service Oriented Architecture (SOA). SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. This sounds a bit too abstract, but SOA is actually everywhere. Let's look at an example of SOA which is likely to be found in your living room. Take a CD for instance. If you want to play it, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different. The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems.

The results of a service are usually the change of state for the consumer but can also be a change of state for the provider or for both. After listening to the music played by your CD player, your mood has changed, say, from "depressed" to "happy". If you want an example that involves the change of states for both, dining out in a restaurant is a good one. The reason that we want someone else to do the work for us is that they are experts. Consuming a service is usually cheaper and more effective than doing the work ourselves. Most of us are smart enough to realize that we are not smart enough to be expert in everything. The same rule applies to building software systems. We call it "separation of concerns", and it is regarded as a principle of software engineering. How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints: 1. A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers. 2. Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services. As illustrated in the power adapter example, interfacing is fundamentally important. If interfaces do not work, systems do not work. Interfacing is also expensive and error-prone for distributed applications. An interface needs to prescribe system behavior, and this is very difficult to implement correctly across different platforms and languages. Remote interfaces are also the slowest part of most distributed applications. Instead of building new interfaces for each application, it makes sense to reuse a few generic ones for all applications. Since we have only a few generic interfaces available, we must express applicationspecific semantics in messages. We can send any kind of message over our interfaces, but there are a few rules to follow before we can say that an architecture is service oriented. First, the messages must be descriptive, rather than instructive, because the service provider is responsible for solving the problem. This is like going to a restaurant: you tell your waiter what you would like to order and your preferences but you don't tell their cook how to cook your dish step by step. Second, service providers will be unable to understand your request if your messages are not written in a format, structure, and vocabulary that is understood by all parties. Limiting the vocabulary and structure of messages is a necessity for any efficient communication. The more restricted a message is, the easier it is to understand the message, although it comes at the expense of reduced extensibility. Third, extensibility is vitally important. It is not difficult to understand why. The world is an ever-changing place and so is any environment in which a software system lives. Those changes demand corresponding changes in the software system,

service consumers, providers, and the messages they exchange. If messages are not extensible, consumers and providers will be locked into one particular version of a service. Despite the importance of extensibility, it has been traditionally overlooked. At best, it was regarded simply as a good practice rather than something fundamental. Restriction and extensibility are deeply entwined. You need both, and increasing one comes at the expense of reducing the other. The trick is to have a right balance. Fourth, an SOA must have a mechanism that enables a consumer to discover a service provider under the context of a service sought by the consumer. The mechanism can be really flexible, and it does not have to be a centralized registry. Additional Constraints There are a number of additional constraints one can apply on SOA in order to improve its scalability, performance and, reliability. Stateless Service Each message that a consumer sends to a provider must contain all necessary information for the provider to process it. This constraint makes a service provider more scalable because the provider does not have to store state information between requests. This is effectively "service in mass production" since each request can be treated as generic. It is also claimed that this constraint improves visibility because any monitoring software can inspect one single request and figure out its intention. There are no intermediate states to worry about, so recovery from partial failure is also relatively easy. This makes a service more reliable. Stateful Service Stateful service is difficult to avoid in a number of situations. One situation is to establish a session between a consumer and a provider. A session is typically established for efficiency reasons. For example, sending a security certificate with each request is a serious burden for both any consumer and provider. It is much quicker to replace the certificate with a token shared just between the consumer and provider. Another situation is to provide customized service. Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. The drawback of this constraint is that it may reduce the overall scalability of the service provider because it may need to remember the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult. Idempotent Request Duplicate requests received by a software agent have the same effects as a unique request. This constraint allows providers and consumers to improve the overall service reliability by simply repeating the request if faults are encountered.

Deriving Web Services from SOA Everyone knows roughly what a "web service" is, but there is no universally accepted definition. The definition of web service has always been under hot debate within the W3C Web Services Architecture Working Group. Despite the difficulty of defining web services, it is generally accepted that a web service is a SOA with at least the following additional constraints: 1. Interfaces must be based on Internet protocols such as HTTP, FTP, and SMTP. 2. Except for binary data attachment, messages must be in XML. There are two main styles of Web services: SOAP web services and REST web services. SOAP Web services A SOAP web service introduces the following constraints: 1. Except for binary data attachment, messages must be carried by SOAP. 2. The description of a service must be in WSDL. A SOAP web service is the most common and marketed form of web service in the industry. Some people simply collapse "web service" into SOAP and WSDL services. SOAP provides "a message construct that can be exchanged over a variety of underlying protocols" according to the SOAP 1.2 Primer. In other words, SOAP acts like an envelope that carries its contents. One advantage of SOAP is that it allows rich message exchange patterns ranging from traditional request-and-response to broadcasting and sophisticated message correlations. There are two flavors of SOAP web services, SOAP RPC and document-centric SOAP web service. SOAP RPC web services are not SOA; document-centric SOAP web services are SOA. SOAP RPC Web Services A SOAP RPC web service breaks the second constraint required by an SOA. A SOAP RPC Web service encodes RPC (remote procedure calls) in SOAP messages. In other words, SOAP RPC "tunnels" new application-specific RPC interfaces though an underlying generic interface. Effectively, it prescribes both system behaviors and application semantics. Because system behaviors are very difficult to prescribe in a distributed environment, applications created with SOAP RPC are not interoperable by nature. Many real life implementations have confirmed this. Faced with this difficulty, both WS-I basic profile and SOAP 1.2 have made the support of RPC optional. RPC also tends to be instructive rather than descriptive, which is against the spirit of SOA. Ironically, SOAP was originally designed just for RPC. It won't be long before someone claims that "SOAP" actually stands for "SOA Protocol". REST Web Services The term REST was first introduced by Roy Fielding to describe the web architecture. A REST web service is an SOA based on the concept of "resource". A resource is

anything that has a URI. A resource may have zero or more representations. Usually, people say that a resource does not exist if no representation is available for that resource. A REST web service requires the following additional constraints: 1. Interfaces are limited to HTTP. The following semantics are defined: o HTTP GET is used for obtaining a representation of a resource. A consumer uses it to retrieve a representation from a URI. Services provided through this interface must not incur any obligation from consumers. o HTTP DELETE is used for removing representations of a resource. o HTTP POST is used for updating or creating the representations of a resource. o HTTP PUT is used for creating representations of a resource. 2. Most messages are in XML, confined by a schema written in a schema language such as XML Schema from W3C or RELAX NG. 3. Simple messages can be encoded with URL encoding. 4. Service and service providers must be resources while a consumer can be a resource. REST web services require little infrastructure support apart from standard HTTP and XML processing technologies, which are now well supported by most programming languages and platforms. REST web services are simple and effective because HTTP is the most widely available interface, and it is good enough for most applications. In many cases, the simplicity of HTTP simply outweighs the complexity of introducing an additional transport layer. Understanding Service-Oriented Architecture

David Sprott and Lawrence Wilkes CBDI Forum January 2004 Summary: Gives a concise explanation of service-oriented architecture, what it is, and how it affects what architects, CIOs, project managers, business analysts, and lead developers do. (13 printed pages) Introduction It seems probable that eventually most software capabilities will be delivered and consumed as services. Of course they may be implemented as tightly coupled systems, but the point of usageto the portal, to the device, to another endpoint, and so on, will use a service-based interface. We have seen the comment that architects and designers need to be cautious to avoid everything becoming a service. We think this is incorrect and muddled thinking. It might be valid right now given the

maturity of Web Service protocols and technology to question whether everything is implemented using Web services, but that doesn't detract from the need to design everything from a service perspective. The service is the major construct for publishing and should be used at the point of each significant interface. serviceoriented architecture allows us to manage the usage (delivery, acquisition, consumption, and so on) in terms of, and in sets of, related services. This will have big implications for how we manage the software life cycleright from specification of requirements as services, design of services, acquisition and outsourcing as services, asset management of services, and so on. Over time, the level of abstraction at which functionality is specified, published and or consumed has gradually become higher and higher. We have progressed from modules, to objects, to components, and now to services. However in many respects the naming of SOA is unfortunate. Whilst SOA is of course about architecture, it is impossible to constrain the discussion to architecture, because matters such as business design and the delivery process are also important considerations. A more useful nomenclature might be Service Orientation (or SO). There are actually a number of parallels with object orientation (or OO) and component-based development (CBD): Like objects and components, services represent natural building blocks that allow us to organize capabilities in ways that are familiar to us. Similarly to objects and components, a service is a fundamental building block that 1. Combines information and behaviour. 2. Hides the internal workings from outside intrusion. 3. Presents a relatively simple interface to the rest of the organism. Where objects use abstract data types and data abstraction, services can provide a similar level of adaptability through aspect or context orientation. Where objects and components can be organized in class or service hierarchies with inherited behaviour, services can be published and consumed singly or as hierarchies and or collaborations. For many organizations, the logical starting place for investigating service-oriented architecture is the consideration of Web services. However Web services are not inherently service oriented. A Web service merely exposes a capability that conforms to Web services protocols. In this article we will identify the characteristics of a well

formed service, and provide guidance for architects and designers on how to deliver service oriented applications. Principles and Definitions Looking around we see the term or acronym SOA becoming widely used, but there's not a lot of precision in the way that it's used. The World Wide Web Consortium (W3C) for example refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. We see similar definitions being used elsewhere; it's a very technical perspective in which architecture is considered a technical implementation. This is odd, because the term architecture is more generally used to describe a style or set of practicesfor example the style in which something is designed and constructed, for example Georgian buildings, Art Nouveau decoration or a garden by Sir Edwin Lutyens and Gertrude Jekyll . CBDI believes a wider definition of service-oriented architecture is required. In order to reach this definition, let's start with some existing definitions, and compare some W3C offerings with CBDI recommendations. We'll begin by looking at definitions of basic Service concepts. Service A Component capable of performing a task. A WSDL service: A collection of end points (W3C). A type of capability described using WSDL (CBDI).

A Service Definition A vehicle by which a consumer's need or want is satisfied according to a negotiated contract (implied or explicit) which includes Service Agreement, Function Offered and so on (CBDI). A Service Fulfillment An instance of a capability execution (CBDI).

Web service

A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a format that machines can process (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards (W3C).

A programmatic interface to a capability that is in conformance with WSnn protocols (CBDI).

From these definitions, it will be clear that the W3C have adopted a somewhat narrower approach to defining services and other related artefacts than CBDI. CBDI differs slightly insofar as not all Services are Components, nor do they all perform a task. Also CBDI recommends it is useful to manage the type, definition and fulfilment as separate items. However it is in the definition of SOA that CBDI really parts company with the W3C. Service-Oriented Architecture: A set of components which can be invoked, and whose interface descriptions can be published and discovered (W3C). CBDI rejects this definition on two counts: First the components (or implementations) will often not be a set. Second the W3C definition of architecture only considers the implemented and deployed components, rather than the science, art or practice of building the architecture. CBDI recommends SOA is more usefully defined as: The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. (CBDI) CBDI defines SOA as a style resulting from the use of particular policies, practices and frameworks that deliver services that conform to certain norms. Examples include certain granularity, independence from the implementation, and standards compliance. What these definitions highlight is that any form of service can be exposed with a Web services interface. However higher order qualities such as reusability and independence from implementation, will only be achieved by

employing some science in a design and building process that is explicitly directed at incremental objectives beyond the basic interoperability enabled by use of Web services. SOA Basics It's would be easy to conclude that the move to Service Orientation really commenced with Web servicesabout three years ago. However, Web services were merely a step along a much longer road. The notion of a service is an integral part of component thinking, and it is clear that distributed architectures were early attempts to implement service-oriented architecture. What's important to recognize is that Web services are part of the wider picture that is SOA. The Web service is the programmatic interface to a capability that is in conformance with WSnn protocols. So Web services provide us with certain architectural characteristics and benefits specifically platform independence, loose coupling, self description, and discovery and they can enable a formal separation between the provider and consumer because of the formality of the interface. Service is the important concept. Web Services are the set of protocols by which Services can be published, discovered and used in a technology neutral, standard form. In fact Web services are not a mandatory component of a SOA, although increasingly they will become so. SOA is potentially much wider in its scope than simply defining service implementation, addressing the quality of the service from the perspective of the provider and the consumer. You can draw a parallel with CBD and component technologies. COM and UML component packaging address components from the technology perspective, but CBD, or indeed Component-Based Software Engineering (CBSE), is the discipline by which you ensure you are building components that are aligned with the business. In the same way, Web services are purely the implementation. SOA is the approach, not just the service equivalent of a UML component packaging diagram. Many of these SOA characteristics were illustrated in a recent CBDI report, which compared Web services published by two dotcom companies as alternatives to their normal browser-based access, enabling users to incorporate the functionality offered into their own applications. In one case it was immediately obvious that the Web services were meaningful business servicesfor example enabling the Service Consumer to retrieve prices, generate lists, or add an item to the shopping cart.

In contrast the other organization's services are quite different. It implemented a general purpose API, which simply provides Create, Read, Update, and Delete (CRUD) access to their database through Web services. While there is nothing at all wrong with this implementation, it requires that users understand the underlying model and comply with the business rules to ensure that your data integrity is protected. The WSDL tells you nothing about the business or the entities. This is an example of Web services without SOA. SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed. So what we need is a framework for understanding what constitutes a good service. If, as we have seen in the previous example, we have varying levels of usefulness, we need some Principles of Service Orientation that allow us to set policies, benchmarks and so on. We can discern two obvious sets here: Interface related principlesTechnology neutrality, standardization and consumability. Design principlesThese are more about achieving quality services, meeting real business needs, and making services easy to use, inherently adaptable, and easy to manage. Interestingly the second set might have been addressed to some extent by organizations that have established mature component architectures. However it's certainly our experience that most organizations have found this level of discipline hard to justify. While high quality components have been created perhaps for certain core applications where there is a clear case for widespread sharing and reuse, more generally it has been hard to incur what has been perceived as an investment cost with a short term return on investment. However when the same principles are applied to services, there is now much greater awareness of the requirements, and frankly business and IT management have undergone a steep learning curve to better understand the cost and benefits of IT systems that are not designed for purpose. Here we have to be clearnot all services need all of these characteristics; however it is important that if a service is to be used by multiple consumers, (as is typically the case when a SOA is required),

the specification needs to be generalized, the service needs to be abstracted from the implementation (as in the earlier dotcom case study), and developers of consumer applications shouldn't need to know about the underlying model and rules. The specification of obligations that client applications must meet needs to be formally defined and precise and the service must be offered at a relevant level of granularity that combines appropriate flexibility with ease of assembly into the business process. Table 1 shows principles of good service design that are enabled by characteristics of either Web services or SOA. Table 1. Web services and SOA Enabled by Web services Technology neutral Standardized Consumable Enabled by SOA Reusable Abstracted Published Formal Relevant Endpoint platform independence. Standards-based protocols. Enabling automated discovery and usage. Use of Service, not reuse by copying of code/implementation. Service is abstracted from the implementation. Precise, published specification functionality of service interface, not implementation. Formal contract between endpoints places obligations on provider and consumer. Functionality presented at a granularity recognized by the user as a meaningful service.

If the principles summarized in Table 1 are complied with, we get some interesting benefits: There is real synchronization between the business and IT implementation perspective. For many years, business people haven't really understood the IT architecture. With well designed services we can radically improve communications with the business, and indeed move beyond alignment and seriously consider convergence of business and IT processes. A well formed service provides us with a unit of management that relates to business usage. Enforced separation of the service provision

provides us with basis for understanding the life cycle costs of a service and how it is used in the business. When the service is abstracted from the implementation it is possible to consider various alternative options for delivery and collaboration models. No one expects that, at any stage in the foreseeable future, core enterprise applications will be acquired purely by assembling services from multiple sources. However it is entirely realistic to assume that certain services will be acquired from external sources because it is more appropriate to acquire them. For example authentication services, a good example of third party commodity services that can deliver a superior service because of specialization, and the benefits of using a trusted external agency to improve authentication. Process Matters As indicated earlier, CBDI advises that good SOA is all about stylepolicy, practice and frameworks. This makes process matters an essential consideration. Whilst some of the benefits of services might have been achieved by some organizations using components, there are relatively few organizations that rigorously enforce the separation of provision and consumption throughout the process. This gets easier with services because of the formality of the interface protocols, but we need to recognize that this separation needs managing. For example it's all too easy to separate the build processes of the service and the consumer, but if the consumer is being developed by the same team as the service then it's all too easy to test the services in a manner that reflects understanding of the underlying implementation. With SOA it is critical to implement processes that ensure that there are at least two different and separate processesfor provider and consumer. However, current user requirements for seamless end-to-end business processes, a key driver for using Web Services, mean that there will often be clear separation between the providing and consumer organizations, and potentially many to many relationships where each participant has different objectives but nevertheless all need to use the same service. Our recommendation is that development organizations behave like this, even when both the providing and consuming processes are in-house, to ensure they are properly designing services that accommodate future needs

For the consumer, the process must be organized such that only the service interface matters, and there must be no dependence upon knowledge of the service implementation. If this can be achieved, considerable benefits of flexibility accrue because the service designers cannot make any assumptions about consumer behaviours. They have to provide formal specifications and contracts within the bounds of which consumers can use the service in whatever way they see fit. Consumer developers only need to know where the service is, what it does, how they can use it. The interface is really the only thing of consequence to the consumer as this defines how the service can be interacted with. Similarly, whilst the provider has a very different set of concerns, it needs to develop and deliver a service that can be used by the Service Consumer in a completely separate process. The focus of attention for the provider is therefore again the interfacethe description and the contract. Another way of looking at this is to think about the nature of the collaboration between provider and consumer. At first sight you may think that there is a clear divide between implementation and provisioning, owned by the provider, and consumption, owned by the consumer. However if we look at these top level processes from the perspective of collaborations, then we see a very different picture. What we have is a significant number of process areas where (depending on the nature of the service) there is deep collaboration between provider and consumer. Potentially we have a major reengineering of the software delivery process. Although we have two primary parties to the service-based process, we conclude there are three major process areas which we need to manage. Of course these decompose, but it seems to us that the following are the primary top level processes. The process of delivering the service implementation. 'Traditional' Development Programming Web Services automated by tools

The provisioning of the servicethe life cycle of the service as a reusable artefact. Commercial Orientation Internal and External View Service Level Management

The consumption process. Business Process Driven Service Consumer could be internal or external Solution assembly from Services, not code Increasingly graphical, declarative development approach Could be undertaken by business analyst or knowledge worker

The advantage of taking this view is that the collaborative aspects of the process are primarily contained in the provisioning process area. And the provisioning area is incredibly important because the nature of the agreement has a major influence on the process requirements. There are perhaps two major patterns for designing consumer/provider collaborations: NegotiatedConsumer and Provider jointly agree service When new services are developed though, there is an opportunity for both provider and consumer to agree what and how the services should work. In industries where there are many participants all dealing with each other, and where services are common to many providers, it is essential that the industry considers standardizing those services. Examples include: Early adopters New Services Close partners Industry initiativeforming standards Internal use

InstantiatedThis is it. Take it or leave it One party in the collaborative scenario might simply dictate the services that must be used. Sometimes the service will already exist. You just choose to use it, or not. Examples include: Dominant partner Provider ledUse this service or we can't do business Consumer ledProvide this service or we can't do business Industry initiativestandards compliance Existing system/interface

Architectures

This process view that we have examined at is a prerequisite to thinking about the type of architecture required and the horizons of interest, responsibility and integrity. For SOA there are three important architectural perspectives as shown in Figure 1. The Application Architecture. This is the business facing solution which consumes services from one or more providers and integrates them into the business processes. The Service Architecture. This provides a bridge between the implementations and the consuming applications, creating a logical view of sets of services which are available for use, invoked by a common interface and management architecture. The Component Architecture. This describes the various environments supporting the implemented applications, the business objects and their implementations.

Figure 1. Three Architectural Perspectives These architectures can be viewed from either the consumer or provider perspective. Key to the architecture is that the consumer of a service should not be interested in the implementation detail of the servicejust the service provided. The implementation architecture could vary from provider to provider yet still deliver the same service. Similarly the provider should not be interested in the application that the service is consumed in. New unforeseen applications will reuse the same set of services.

The consumer is focused on their application architecture, the services used, but not the detail of the component architecture. They are interested at some level of detail in the general business objects that are of mutual interest, for example provider and consumer need to share a view of what an order is. But the consumer does not need to know how the order component and database are implemented. Similarly, the provider is focused on the component architecture, the service architecture, but not on the application architecture Again, they both need to understand certain information about the basic applications, for example to be able to set any sequencing rules and pre and post conditions. But the provider is not interested in every detail of the consuming application. The Service Architecture At the core of the SOA is the need to be able to manage services as first order deliverables. It is the service that we have constantly emphasized that is the key to communication between the provider and consumer. So we need a Service Architecture that ensures that services don't get reduced to the status of interfaces, rather they have an identity of their own, and can be managed individually and in sets. CBDI developed the concept of the Business Service Bus (BSB) precisely to meet this need. The BSB is a logical view of the available and used services for a particular business domain, such as Human Resources or Logistics. It helps us answer questions such as: What service do I need? What services are available to me? What services will operate together? (common semantics, business rules) What substitute services are available? What are the dependencies between services and versions of services?

Rather than leaving developers to discover individual services and put them into context, the Business Service Bus is instead their starting point that guides them to a coherent set that has been assembled for their domain. The purpose of the BSB is so that common specifications, policies, etc can be made at the bus level, rather than for each individual service. For example, services on a bus should all follow the same semantic standards, adhere to the same security

policy, and all point to the same global model of the domain. It also facilitates the implementation of a number of common, lower-level business infrastructure services that can be aggregated into other higher level business services on the same bus (for example, they could all use the same product code validation service). Each business domain develops a vocabulary and a business model of both process and object. A key question for the Service Architecture is 'What is the scope of the service that is published to the Business Service Bus?' A simplistic answer is 'At a business level of abstraction'. However this answer is open to interpretationbetter to have some heuristics that ensure that the service is the lowest common denominator that meets the criteria of business, and is consumer oriented, agreed, and meaningful to the business. The key point here is that there is a process of aggregation and collaboration that should probably happen separately from the implementing component as illustrated in Figure 2. By making it separate, there is a level of flexibility that allows the exposed service(s) to be adjusted without modifying the underlying components. In principle, the level of abstraction will be developed such that services are at a level that is relevant and appropriate to the consumer. The level might be one or all of the following: Business Services Service Consumer Oriented Agreed by both Provider and Consumer Combine low-level implementation-based services into something meaningful to business Coarser Grained Suitable for External Use Conforms to pre-existing connection design

Figure 2. Levels of Abstraction The SOA Platform The key to separation is to define a virtual platform that is equally relevant to a number of real platforms. The objective of the virtual platform is to enable the separation of services from the implementation to be as complete as possible and allow components built on various implementation platforms to offer services which have no implementation dependency. The virtual SOA platform comprises a blueprint which covers the development and implementation platforms. The blueprint provides guidance on the development and implementation of applications to ensure that the published services conform to the same set of structural principles that are relevant to the management and consumer view of the services. When a number of different applications can all share the same structure, and where the relationships between the parts of the structure are the same, then we have what might be called a common architectural style. The style may be implemented in various ways; it might be a common technical environment, a set of policies, frameworks or practices. Example platform components of a virtual platform include: Host environment Consumer environment Middleware Integration and assembly environment Development environment Asset management Publishing & Discovery

Service level management Security infrastructure Monitoring & measurement Diagnostics & failure Consumer/Subscriber management Web service protocols Identity management Certification Deployment & Versioning

The Enterprise SOA The optimum implementation architecture for SOA is a component-based architecture. Many will be familiar with the concepts of process and entity component, and will understand the inherent stability and flexibility of this component architecture, which provide a one to one mapping between business entities and component implementations. Enterprise SOA (ESOA) brings the two main threadsWeb services and CBD (or CBSE)together. The result is an enterprise SOA that applies to both Web services made available externally and also to core business component services built or specified for internal use. It is beyond the scope of this article to explore ESOA in more depth. For more on this topic there is a five part CBDI Report Series on Enterprise SOA. Summary The goal for a SOA is a world wide mesh of collaborating services, which are published and available for invocation on the Service Bus. Adopting SOA is essential to deliver the business agility and IT flexibility promised by Web Services. These benefits are delivered not by just viewing service architecture from a technology perspective and the adoption of Web Service protocols, but require the creation of a Service Oriented Environment that is based on the following key principals we have articulated in this article; Service is the important concept. Web Services are the set of protocols by which Services can be published, discovered and used in a technology neutral, standard form.

SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.

With SOA it is critical to implement processes that ensure that there are at least two different and separate processesfor provider and consumer. Rather than leaving developers to discover individual services and put them into context, the Business Service Bus is instead their starting point that guides them to a coherent set that has been assembled for their domain.

For further guidance on planning and managing the transition to Web Services and SOA, CBDI are providing the 'Web Services Roadmap', a set of resources that are freely available at http://roadmap.cbdiforum.com/.