Report on Service Oriented Architecture (SOA) ABSTRACT SOA is a design for linking business and computational resources (principally

organizations, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services). Service orientation describes an architecture that uses loosely coupled services to support the re!uirements of business processes and users. "esources on a network in a SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation. #hese concepts can be applied to business, software and other types of producer$consumer systems. #he main drivers for SOA adoption are that it links computational resources and promotes their reuse. %nterprise architecture believes that SOA can help businesses respond more !uickly and cost effectively to changing market conditions. #his style of architecture promotes reuse at the macro (service) level rather than micro (ob&ects) level. #he following guiding principles define the ground rules for development, maintenance, and usage of the SOA ' "euse, granularity, modularity, compos ability, componentization, and interoperability ' (ompliance to standards (both common and industry specific)

' Services identification and categorization, provisioning and delivery, and monitoring and tracking. One obvious and common challenge faced is managing service metadata. Another challenge is providing appropriate levels of security. )nteroperability is another important aspect in the SOA implementations.

Introduction SOA implementations rely on a mesh (Mesh consists of semi permeable barrier made of connected strands of metal, fiber, or other fle*ible$ductile material. +esh is similar to web or net in that it has many attached or woven strands.)Of software services. Services comprise unassociated, loosely coupled units of functionality that have no calls to each other embedded in them. %ach service implements one action, such as filling out an online application for an account, or viewing an online bank statement, or placing an online booking or airline ticket order. )nstead of services embedding calls to each other in their source code they use defined protocols that describe how services pass and parse messages, using description metadata. SOA developers associate individual SOA ob&ects by using orchestration (Orchestration describes the automated arrangement, coordination, and management of comple* computer systems, middleware, and services.). )n the process of orchestration the developer associates software functionality (the services) in a non hierarchical arrangement (in contrast to a class hierarchy) using a software tool that contains a complete list of all available services, their characteristics, and the means to build an application utilizing these sources. ,nderlying and enabling all of this re!uires metadata in sufficient detail to describe not only the characteristics of these services, but also the data that drives them. -rogrammers have made e*tensive use of .+/ in SOA to structure data that they wrap in a nearly e*haustive description container. Analogously, the 0eb Services 1escription /anguage (0S1/) typically describes the services themselves, while theSOA- protocol describes the communications protocols. 0hether these description languages are the best possible for the &ob, and whether they will become$remain the favorites in the future, remain open !uestions. As of 2334 SOA depends on data and services that are described by metadata that should meet the following two criteria5

6. #he metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity. 2. #he metadata should come in a form that system designers can understand and manage with a reasonable e*penditure of cost and effort. SOA aims to allow users to string together fairly large chunks of functionality to form ad hoc applications that are built almost entirely from e*isting software services. #he larger the chunks, the fewer the interface points re!uired to implement any given set of functionality7 however, very large chunks of functionality may not prove sufficiently granular for easy reuse. %ach interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. #he great promise of SOA suggests that the marginal cost of creating the n th application is low, as all of the software re!uired already e*ists to satisfy the re!uirements of other applications. )deally, one re!uires only orchestration to produce a new application. 8or this to operate, no interactions must e*ist between the chunks specified or within the chunks themselves. )nstead, humans specify the interaction of services (all of them unassociated peers) in a relatively ad hoc way with the intent driven by newly emergent re!uirements. #hus the need for services as much larger units of functionality than traditional functions or classes, lest the sheer comple*ity of thousands of such granular ob&ects overwhelm the application designer. -rogrammers develop the services themselves using traditional languages like 9ava, (,(::, (; or (O<O/. SOA services feature loose coupling, in contrast to the functions that a linker binds together to form an e*ecutable, to a dynamically linked library or to an assembly. SOA services also run in =safe= wrappers (such as 9ava or .>%#) and in 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 2334, increasing numbers of third party software companies offer software services for a fee. )n the future, SOA systems may consist of such third party services combined with others created in house. #his has the potential to spread costs over many customers and customer uses, and promotes standardization both in and across industries. )n 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. )f a service presents a simple interface that abstracts away its underlying comple*ity, users can access independent services without knowledge of the service?s platform implementation. SOA relies on services e*posing their functionality via interfaces that other applications and services can read to understand how to utilize those services.

Requirements )n order to efficiently use a SOA, one must meet the following re!uirements5

)nteroperability between different systems and programming languages that provides the basis for integration between applications on different platforms through a communication protocol. One e*ample of such communication depends on the concept of messages. ,sing messages across defined message channels decreases the comple*ity 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. 1esire to create a federation of resources. %stablish and maintain data flow to a 8ederated database system(A federated database system is a type of meta database
management system (1<+S) which transparently integrates multiple autonomous database systems into a single federated database). #his allows new functionality developed to

reference a common business format for each data element.

Principles #he following uidin principles define the ground rules for development, maintenance, and usage of the SOA5

"euse, granularity, modularity, composability, componentization and interoperability. Standards compliance (both common and industry specific). Services identification and categorization, provisioning and delivery, and monitoring and tracking.

#he following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behavior of a system and the style of its design5

Attributes of a SOA

Service encapsulation @ +any web services are consolidated for use under the SOA. Often such services were not planned to be under SOA. Service loose couplin @ Services maintain a relationship that minimizes dependencies and only re!uires 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 @ <eyond descriptions in the service contract, services hide logic from the outside world. Service reusability @ /ogic is divided into services with the intention of promoting reuse. Service composability @ (ollections of services can be coordinated and assembled to form composite services. Service autonomy @ Services have control over the logic they encapsulate. Service optimi!ation @ All else e!ual, high !uality services are generally preferable to low !uality ones. Service discoverability @ Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms. Service relevance @ 8unctionality is presented at a granularity recognized by the user as a meaningful service.

#he following references provide additional considerations for defining a SOA implementation5

SOA "eference Architecture provides a working design of an enterprise wide SOA implementation with detailed architecture diagrams, component descriptions, detailed re!uirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc.. /ife cycle management SOA -ractitioners Auide -art B5 )ntroduction to Services /ifecycle introduces the services lifecycle and provides a detailed process for services management through the service lifecycle, from inception to retirement or repurposing of the services. )t also contains an appendi* that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information.

Conceptual model of a SOA architectural style

)n addition, one might take the following factors into account when defining a SOA implementation5

efficient use of system resources service maturity and performance %A) ("nterprise Application Inte ration #"AI$ is defined as the use of software and
computer systems architectural principles to integrate a set of enterprise computer applications.)

%eb services approach 0eb services can implement a service oriented architecture. 0eb services make functional building blocks accessible over standard )nternet protocols independent of platforms and programming languages. #hese services can represent either new applications or &ust wrappers around e*isting legacy systems to make them network enabled. %ach SOA building block can play one or both of two roles5

1. Service -rovider

#he service provider creates a web service and possibly publishes its interface and access information to the service registry. %ach provider must decide which services to e*pose, how to make trade offs between security and easy availability, how to price the services, or (if no charges apply) how$whether to e*ploit them for other value. #he 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 re!uired to use the service. )t registers what services are available within it, and lists all the potential service recipients. #he implementer of the broker then decides the scope of the broker. -ublic brokers are available through the )nternet, while private brokers are only accessible to a limited audience, for e*ample, users of a company intranet. 8urthermore, 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. Some brokers catalog other brokers. 1epending on the business model, brokers can attempt to ma*imize look up re!uests, number of listings or accuracy of the listings. #he ,niversal 1escription 1iscovery and )ntegration (,11)) specification defines a way to publish and discover information about 0eb services. Other service broker technologies include (for e*ample) eb.+/ (%lectronic <usiness using e*tensible +arkup /anguage) and those based on the )SO$)%( 666CD +etadata "egistry (+1") standard.

2. Service consumer

the service consumer 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. 0hichever service the service consumers need, they have to take it into the brokers, then bind it with respective service and then use it. #hey can access multiple services if the service provides multiple services.

SOA and %eb service protocols )mplementers commonly build SOAs using web services standards (for e*ample, SOA-) that have gained broad industry acceptance. #hese standards (also referred to as 0eb 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 9ini, (O"<A or "%S#. Other SOA concepts Architectures can operate independently of specific technologies. 1esigners can implement SOA using a wide range of technologies, including5

SOA-, "-( "%S# 1(O+ (O"<A 0eb Services 0(8 (+icrosoft?s implementation of 0eb service forms a part of 0(8)

)mplementations can use one or more of these protocols and, for e*ample, might use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. #he 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. Eweasel wordsF +any implementers of SOA have begun to adopt an evolution of SOA concepts into a more advanced architecture called SOA 2.3.

%lements of SOA, by 1irk Grafzig, Garl <anke, and 1irk SlamaEDF

SOA meta model, #he /inthicum Aroup, 233C

Service Oriented +odeling 8ramework (SO+8) Hersion 2.3 SOA enables the development of applications that are built by combining loosely coupled and interoperable services. #hese services inter operate based on a formal definition (or contract, e. g., 0S1/) that is independent of the underlying platform and programming language. #he interface definition hides of the language specific service. SOA based systems can therefore function independently of development technologies and platforms (such as 9ava,.>%#, etc). Services written in (; running on .>%# platforms and services written in 9ava running on 9ava %% platforms, for e*ample, 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 that facilitate reuse. +anaged environments can also wrap (O<O/ legacy systems and present them as software services. #his has e*tended the useful life of many core legacy systems indefinitely, no matter what language they originally used. SOA can support integration and consolidation activities within comple* enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services.

Iigh level languages such as <-%/ and specifications such as 0S (1/ and 0S (oordination e*tend 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 As of 2334 researchers have started investigating the use of Service (omponent Architecture (S(A) to implement SOA. Service oriented modeling is a SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service oriented assets. #he Service oriented modeling framework (SO+8) offers a modeling language and a work structure or =map= depicting the various components that contribute to a successful service oriented modeling approach. )t illustrates the ma&or elements that identify the Jwhat to doK aspects of a service development scheme. #he model enables practitioners to craft a pro&ect plan and to identify the milestones of a

service oriented initiative. SO+8 also provides a common modeling notation to address alignment between business and )# organizations. SO+8 addresses the following principles5

business traceability architectural best practices traceability technological traceability SOA value proposition software assets reuse SOA integration strategies technological abstraction and generalization architectural components abstraction

SOA definitions (ommentators have provided multiple definitions of SOA. #he OAS)S group and the Open Aroup have both created formal definitions.
Organization for the Advancement of Structured )nformation Standards (OAS)S) is a global consortium that drives the development, convergence and adoption of e business and web service standards. +embers of the consortium decide how and what work is undertaken through an open, democratic process.

OAS)S defines SOA as the following5

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.

Service contract A service contract needs to have the following components5

Ieader >ame @ >ame of the service. #his should indicate in general terms what the service does, not &ust its definition Hersion @ #he version of this service contract Owner @ #he person$team in charge of the service

"esponsibility assignment ("A()) "esponsible @ #he role$person$team responsible for the deliverables of this contract$service. All versions of the contract Accountable @ ,ltimate 1ecision +aker in terms of this contract$service (onsulted @ 0hom one must consult before action is taken on this contract$service. #his is two way communication. #hese people have an impact on the decision or the e*ecution of that decision. )nformed @ 0ho must be informed that a decision or action is being taken. #his is a one way communication. #hese people are impacted by the decision or e*ecution of that decision, but have no control over the action.

#ype @ #his is the type of the service5 to help distinguish the layer in which it resides. 1ifferent implementations will have different service types. %*amples of service types include5

-resentation -rocess <usiness 1ata )ntegration

8unctional 8unctional "e!uirement (from "e!uirements 1ocument) @ )ndicates the functionality in specific bulleted items L what e*actly this service accomplishes. #he language should encourage test cases to prove the functionality is accomplished. Service Operations @ +ethods, actions etc. +ust be defined in terms of what part of the functionality it provides.

)nvocation @ )ndicates how to invoke the service. #his includes the ,"/, interface, etc. #here may be multiple invocation paths for the same service. One may have the same functionality for an internal and some e*ternal clients, each with different invocation means and interfaces. %*amples5 SOA

"%S# %vents #riggers

>on 8unctional Security (onstraints @ 1efines who can e*ecute this service in terms of roles or individual partners etc. and which invocation mechanism they can invoke. Muality of Service @ 1etermines the allowable failure rate #ransactional @ )s this capable of acting as part of a larger transaction and if so, how do we control thatN Service /evel Agreement @ 1etermines the amount of latency the service is allowed to have to perform its actions Semantics @ 1ictates or defines the meaning of terms used in the description and interfaces of the service -rocess @ 1escribes the process, if any, of the contracted service

SOA and net&or' mana ement architecture As of 2334 the principles of SOA are being applied to the field of network management. %*amples of service oriented network management architectures include #S 644 336 NGN Management !! Architecture from %#S), and +.B3O3 "rinciples for the Management f Next Generation Networ#s recommendation from the )#, #. #ools for managing SOA infrastructure include5

I- Software P Solutions Iy-erformi* )-S -erformance Optimizer )<+ #ivoli 8ramework

Benefits Some enterprise architects believe that SOA can help businesses respond more !uickly and cost effectively to changing market conditions. #his style of architecture promotes reuse at the macro (service) level rather than micro (classes) level. )t can also simplify interconnection to @ and usage of @ e*isting )# (legacy) assets. )n some respects, one can regard SOA as an architectural evolution rather than as a revolution. )t captures many of the best practices of previous software architectures. )n communications systems, for e*ample, little development has taken place of solutions that use truly static bindings to talk to other e!uipment in the network. <y formally embracing a SOA approach, such systems can position themselves to stress the importance of well defined, highly inter operable interfaces. Some have !uestioned whether SOA simply revives concepts like modular programming (6DC3s), event oriented design (6D43s) or interface$component based design (6DD3s). 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. #his can also ma*imize reuse of services SOA is an architectural and design discipline conceived to achieve the goals of increased interoperability (information e*change, 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 comple* software intensive systems from a set of universally interconnected and interdependent building blocks, called services. SOA realizes its business and )# benefits through utilizing an analysis and design methodology when creating services. #his methodology ensures that services remain consistent with the architectural vision and roadmap, and that they adhere to principles of

service orientation. Arguments supporting the business and management aspects from SOA are outlined in various publications.

A service comprises a stand alone unit of functionality available only via a formally defined interface. Services can be some kind of =nano enterprises= that are easy to produce and improve. Also services can be =mega corporations= constructed as the coordinated work of sub ordinate services. Services generally adhere to the following principles of service orientation5

abstraction autonomy composability discoverability formal contract loose coupling reusability statelessness

A mature rollout of SOA effectively defines the A-) of an organization. "easons for treating the implementation of services as separate pro&ects from larger pro&ects include5 6. Separation promotes the concept to the business that services can be delivered !uickly and independently from the larger and slower moving pro&ects common in the organization. #he business starts understanding systems and simplified user interfaces calling on services. #his advocates agility.

2. Separation promotes the decoupling of services from consuming pro&ects. #his encourages good design insofar as the service is designed without knowing who its consumers are. B. 1ocumentation and test artifacts of the service are not embedded within the detail of the larger pro&ect. #his is important when the service needs to be reused later. An indirect benefit of SOA involves dramatically simplified testing. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross cutting concerns of the implementation. #he industry has never been e*posed to this circumstance before.

)f an organization possesses appropriate defined test data, then when a service is being built, a corresponding stub is built that reacts to the test data. A full set of regression tests, scripts, data, and responses is also captured for the service. #he service can be tested as a ?black bo*? using e*isting stubs corresponding to the services it calls. #est environments can be constructed where the primitive and out of scope services are stubs, while the remainders of the mesh are test deployments of full services. As each interface is fully documented, with its own full set of regression test documentation, it becomes simple to identify problems in test services. #esting evolves to merely validating that the test service operates according to its documentation, and in finding gaps in documentation and test cases of all services within the environment. +anaging the data state of idempotent services is the only comple*ity. %*amples may prove useful to aid in documenting a service to the level where it becomes useful. #he documentation of some A-)s within the 9ava (ommunity -rocess provide good e*amples. As these are e*haustive, staff would typically use only important subsets. #he ?oss&sa.pdf? file within 9S" 4D e*emplifies such a file.

Challen es in adoptin SOA One obvious and common challenge faced involves managing services metadata. SOA based environments can include many services that e*change messages to perform tasks. 1epending on the design, a single application may generate millions of messages. +anaging and providing information on how services interact can become comple*. #his becomes even more complicated when these services are delivered by different organizations within the company or even different companies (partners, suppliers, etc). #his creates huge trust issues across teams, and hence SOA Aovernance comes into picture. Another challenge involves the lac' of testin in SOA space. #here are no sophisticated tools that provide testability of all headless services (including message and database services along with web services) in a typical architecture. /ack of horizontal trust re!uires that both producers and consumers test services on a continuous basis. SOA?s main goal is to deliver Agility to $usinesses #herefore it is important to invest in a testing framework (build or buy) that would provide the visibility re!uired to find the culprit in the architecture. <usiness agility re!uires SOA services to be controlled by the business goals and directives as defined in the <usiness +otivation +odel (<++). Another challenge relates to providing appropriate levels of security. Security models built into an application may no longer suffice when an application e*poses its capabilities as services that can be used by other applications. #hat is, application managed security is not the right model for securing services. A number of new

technologies and standards have started to emerge and provide more appropriate models for security in SOA. See SOA Security entry for more information. As SOA and the 0S Q specifications practitioners e*pand, update and refine their output, they encounter 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. #he 0S ) organization has developed <asic -rofile (<-) and <asic Security -rofile (<S-) to enforce compatibility. 0S ) has designed testing tools to help assess whether web services conform to 0S ) profile guidelines. Additionally, another charter has been established to work on the "eliable Secure -rofile.

Significant vendor hype surrounds SOA7 this can create e*pectations that may not be fulfilled. -roduct stacks continue to evolve as early adopters test the development and runtime products with real world problems. SOA does not guarantee reduced )# costs, improved systems agility or faster time to market. Successful SOA implementations may realize some or all of these benefits depending on the !uality and relevance of the system architecture and design. )nternal )# delivery organizations routinely initiate SOA efforts, and some of these improperly introduce concepts to the business so it remains misunderstood. #he adoption starts meeting )# delivery needs instead of those of the business, resulting in an organization with (say) superlative laptop provisioning services, instead of one that can !uickly respond to market opportunities. <usiness leadership also becomes convinced that the organization is e*ecuting well on SOA. One of the most important benefits of SOA is its ease of reuse. #herefore accountability and funding models must ultimately evolve within the organization. A business unit needs to be encouraged to create services that other units will use. (onversely, units must be encouraged to reuse services. #his re!uires a few new governance components5

%ach business unit creating services must have an appropriate support structure in place to deliver on its service level obligations, and to support enhancing e*isting services strictly for the benefit of others. #his is typically !uite foreign to business leaders.

%ach business unit consuming services accepts the apparent risk of reusing services outside their own control, with the attendant e*ternal pro&ect dependencies, etc. An innovative funding model is needed as incentive to drive these behaviors above. <usiness units normally pay the )# Organization to assist during pro&ects, and then to operate the environment. (orporate incentives should discount these costs to service providers, and create internal revenue streams from consuming business units to the service provider. #hese streams should be less than the costs of a consumer simply building it the old fashioned way. #his is where SOA deployments can benefit from the SaaS(Software as a service) monetization architecture.

Criticisms of SOA Some criticisms of SOA depend on conflating SOA with web Services. 8or e*ample, some critics claim SOA results in the addition of .+/ layers, introducing .+/ parsing and composition. )n the absence of native or binary forms of "emote -rocedure (all ("-(), applications could run slower and re!uire more processing power, increasing costs. +ost implementations do incur these overheads, but SOA can be implemented using technologies (for e*ample, 9ava <usiness )ntegration (9<))) that do not depend on remote procedure calls or translation through .+/. At the same time, emerging open source .+/ parsing technologies (such as H#1 .+/) and various .+/ compatible binary formats promise to significantly improve SOA performance. Stateful services re!uire both the consumer and the provider to share the same consumer specific conte*t, which is either included in or referenced by messages e*changed between the provider and the consumer. #his constraint has the drawback that it could reduce the overall scalability of the service provider if the service provider needs to retain the shared conte*t for each consumer. )t also increases the coupling between a service provider and a consumer and makes switching service providers more difficult E2OF. ,ltimately, some critics feel that SOA services are still too constrained by applications they represent.

Another concern relates to the ongoing evolution of 0S Q standards and products (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 regard SOA as merely an obvious evolution of currently well deployed architectures (open interfaces, etc). )# system designs sometimes overlook the desirability of modifying systems readily. +any systems, including SOA based systems, hard code the operations, goods and services of the organization, thus restricting their online service and business agility in the global marketplace. #he ne*t step in the design process covers the definition of a Service 1elivery -latform (S1-) and its implementation. )n the S1- design phase 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.

"(tensions SOA) %eb *+,) services over the messen er) and mashups 0eb 2.3, a perceived =second generation= of web activity, primarily features the ability of visitors to contribute information for collaboration and sharing. 0eb 2.3 applications often use "%S# ful web services and commonly feature A9A. based user interfaces, utilizing web syndication,blogs, and wikis. 0hile there are no set standards for 0eb 2.3, it is characterized by building on the e*isting 0eb server architecture and using services. 0eb 2.3 can therefore be regarded as displaying some SOA characteristics. E24FE2DFEB3F Some commentators also regard mashups as 0eb 2.3 applications. #he term =<usiness +ashups= has been coined to describe web applications that combine content from more than one source into an integrated user e*perience that shares many of the characteristics of service oriented business applications (SO<As). SO<As are applications composed of services in a declarative manner. #here is ongoing debate about =the collision of 0eb 2.3, mashups, and SOA,= with some stating that 0eb 2.3 applications are a realization of SOA composite and business applications. %eb *+,

#im O?"eilly coined the term =0eb 2.3= to describe a perceived, !uickly growing set of web based applications. A topic that has e*perienced e*tensive coverage involves the relationship between 0eb 2.3 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. #he notion of comple*ity hiding and reuse, but also the concept of loosely coupling services has inspired researchers to elaborate on similarities between the two philosophies, SOA and 0eb 2.3, and their respective applications. Some argue 0eb 2.3 and SOA have significantly different elements and thus cannot be regarded Jparallel philosophiesK, whereas others consider the two concepts as complementary and regard 0eb 2.3 as the global SOA. #he philosophies of 0eb 2.3 and SOA serve different user needs and thus e*pose differences with respect to the design and also the technologies used in real world applications. Iowever, as of 2334 use cases demonstrated the potential of combining technologies and principles of both 0eb 2.3 and SOA.

)n an =)nternet of Services=, all people, machines, and goods will have access via the network infrastructure of tomorrow. #he )nternet will thus offer services for all areas of life and business, such as virtual insurance, online banking and music, and so on. #hose services will re!uire a comple* services infrastructure including service delivery platforms bringing together demand and supply. <uilding blocks for the )nternet of Services include SOA, 0eb 2.3 and semantics on the technology side7 as well as novel business models, and approaches to systematic and community based innovation.EBBF %ven though Oracle indicates that Aartner is coining a new term, Aartner analysts indicate that they call this advanced SOA and refer to it as =SOA 2.3=.EBRF +ost of the ma&or middleware vendors (e. g., "ed Iat, web +ethods, #)<(O Software, )<+, Sun +icrosystems, and Oracle) have had some form of SOA 2.3 attributes for years.EF

-i ital .ervous System SOA implementations have been described as representing a piece of the larger vision known as the 1igital >ervous System or the Sero /atency %nterprise.