- Service-oriented architecture
Service-oriented architecture (SOA) is a method for
systems developmentand integration where functionality is grouped around business processes and packaged as "interoperable" "services". SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a "loose coupling" of services with operating systems, programming languages and other technologies which underlie applications. [cite book| last=Newcomer | first=Eric | coauthors=Lomow, Greg | year=2005 | title=Understanding SOA with Web Services | publisher=Addison Wesley | id=ISBN 0-321-18086-0] SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications.cite book | last=Erl | first=Thomas | title= Service-oriented Architecture: Concepts, Technology, and Design | publisher= Prentice Hall PTR | year=2005 | location=Upper Saddle River | id=ISBN 0-13-185858-0] These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon, and evolving from older concepts of distributed computingand modular programming.
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 can be used to this end, ranging from rigid point-to-point electronic data interchange(EDI) interactions to web auctions. By updating older technologies, such as Internet-enabling EDI-based systems, companies can make their IT systems available to internal or external customers; but the resulting systems have not proven to be flexible enough to meet business demands.A flexible, standardized architecture is required to better support the connection of various applications and the sharing of data. SOA is one such architecture. It unifies business processes by structuring large applications as an ad hoc collection of smaller modules called services. These applications can be used by different groups of people both inside and outside the company, and new applications built from a mix of services from the global pool exhibit greater flexibility and uniformity. 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. Building all applications from the same pool of services makes achieving this goal much easier and more deployable to affiliate companies. An example of this might be interacting with a rental car company's reservation system even though you are doing so from an airline's reservation system.
Service Oriented Architecture (SOA) is 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 a standard approach for enterprise information systems. Web services face significant challenges because of particular requirements. There are many problems that are to be addressed when applying the SOA paradigm to a real-time system, which include response time, support of event-driven, asynchronous parallel applications, complicated human interface support, reliability, etc. This article explains what SOA is, followed by detailed discussion on several issues that arise when SOA is applied to industrial systems.
Service-oriented architecture (SOA) Definition :A service-oriented architecture can be defined as a group of services, which communicate with each other. The process of communication involves either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
SOAs build applications out of software services. Services are intrinsically unassociated units of functionality, which have no calls to each other embedded in them. They typically implement functionalities 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, protocols are defined 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, and are associated by an application designer or engineer using orchestration. In the process of orchestration, relatively large chunks of software functionality (services) are associated in a non-hierarchical arrangement (in contrast to a class hierarchy) by a software engineer, or process engineer, 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 is
metadatawhich is sufficient to describe not only the characteristics of these services, but also the data that drives them. XMLhas been used extensively 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, is an open question. What is certain is that SOA is utterly dependent on data and services that are described using some implementation of metadata which meets the following two criteria: 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. The metadata must also be in a form which system designers can understand and manage at a reasonable cost and effort.
The goal of SOA is to allow 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 be granular enough to be easily reused. 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 is that the
marginal costof creating the n-th application is zero, as all of the software required already exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application.
The key is that there are no interactions 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 to be much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. The services themselves are developed using traditional languages like Java, C#,
C++, C or COBOL.
SOA services are loosely coupled, 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.
Increasing numbers of third-party software companies are offering software services for a fee. In the future, SOA systems may consist of such third-party 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, are also making significant progress in this direction.
SOA is an architecture that relies on
service-orientationas its fundamental design principle. [ An alternative view, particularly after initial deployments, is that SOAs properly ought not dictate physical implementation, so the formal definition should not include "network." High performance SOAs may not be viable, especially if deployed to distributed nodes on a network. Separate nodes for every (or most) services could be prohibitively expensive.] In a SOA environment, independent services can be accessed without knowledge of their underlying platform implementation. [ Channabasavaiah, Holley and Tuggle, [http://www-128.ibm.com/developerworks/library/ws-migratesoa/ Migrating to a service-oriented architecture] , " IBMDeveloperWorks", 16 Dec 2003]
SOA relies on services exposing their functionality via interfaces which other applications and services read to understand how the service can be utilized.
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.
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA: [Yvonne Balzer [http://www-128.ibm.com/developerworks/webservices/library/ws-improvesoa/ Improve your SOA project plans] , "
IBM", 16 July 2004] :
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:
encapsulation- Many web-services are consolidated to be used under the SOA Architecture. Often such services have not been planned to be under SOA.
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 [Thomas Erl [http://www.serviceorientation.org/p0.asp Serviceorientation.org - About the Principles] , 2005-2006]
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. [ [http://www.soablueprint.com/whitepapers/SOAPGPart2.pdf SOA Practitioners Guide Part 2: SOA Reference Architecture] ]
*Life cycle management [http://www.soablueprint.com/whitepapers/SOAPGPart3.pdf 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
Enterprise Application Integration
Web services approach
Web services can be used to implement a service-oriented architecture. A major focus of Web services is to make functional building blocks accessible over standard Internet protocols that are independent from 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 more of two roles:
The service provider creates a
Web serviceand 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.Its registry what services are available with in it. It list all the potential service requester. The implementer of the broker decides about 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 11179Metadata Registry (MDR) standard.List all the services provided by various service providers.
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 took into the Brokers then bind with respective service then use it. They can access multiple, if the service provide multiple services.
OA and web service protocols
A SOA is commonly built using
Web services standards (e.g., 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, CORBAor REST.
Other SOA concepts
Architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including
SOAP, REST, RPC, DCOM, CORBA, Web Servicesor WCF (Microsoft's implementation of Webservice is 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.
SOA can also be regarded as a style of information systems architecture that enables the creation of applications that are built by combining
loosely coupledand interoperableservices [cite book |last=Cardoso |first=Jorge |coauthors=Sheth, Amit P. |others=Foreword by Frank Leymann |title=Semantic Web Services, Processes and Applications |series=SEMANTIC WEB AND BEYOND: Computing for Human Experience |year= 2006 |publisher=Springer |isbn=978-0-387-30239-3 |pages=xxi |chapter=Foreword |quote=The corresponding architectural style is called "service-oriented architecture": fundamentally, it describes how service requesters and service providers can be decoupled via discovery mechanisms resulting in loosely coupled systems. ... Implementing a service-oriented architecture means to deal with heterogeneity and interoperability concerns.] . 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 be independent 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. Many COBOL legacy systems can also be wrapped by a managed environment and presented as a software service. This has allowed the useful life of many core legacy systems to be extended indefinitely no matter what language they were originally written in.
SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or
frameworkfor documenting capabilities or services.
High-level languages such as
BPELand specifications such as WS-CDLand WS-Coordinationextend the service concept by providing a method of defining and supporting orchestration of fine grained services into more coarse-grained business services, which in turn can be incorporated into workflows and business processes implemented in composite applicationsor portalsFact|date=February 2007.
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 our computing environments and simplify the heterogeneous business and technological landscapes that we have been building for decades? SOA introduces another concept to help practitioners to understand their complex environments by modeling practices. These disciplines are introduced by the
Service-Oriented Modelingparadigm cite book |last=Bell |first=Michael|title=Service-Oriented Modeling: Service Analysis, Design, and Architecture|year= 2008 |publisher=Wiley & Sons|isbn=978-0-470-14111-3 |pages=3 |chapter=Introduction to Service-Oriented Modeling] , a SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented assets. Thus, the Service-Oriented 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 are the modeling pillars that will 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:
*Architectural Best-Practices Traceability
*SOA Value Proposition
*Software Assets Reuse
*SOA Integration Strategies
*Technological Abstraction and Generalization
*Architectural Components Abstraction
* cite web
url = http://www.modelingconcepts.com/pdf/SOMF_ANALYSIS_MODELING.pdf
title = Service-Oriented Modeling Framework (SOMF) Example
* cite web
url = http://www.modelingconcepts.com/pages/download.htm
title = Download SOMF Examples & Language Notation
SOA is a design for linking computational resources (principally applications and data) on demand to achieve the desired results for service consumers (which can be 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."
Open Group SOA Definition(SOA-Definition) [ [http://opengroup.org/projects/soa/doc.tpl?gdid=10632 SOA - Documents - Document details ] ]
OASIS SOA Reference Model(SOA-RM) [ [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm SOA Reference Model definition] ]
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.
A service contract needs to have the following components:
**Name - Name of the service. Should indicate in general terms what it does, but not be the only definition
**Version - The version of this service contract
**Owner - The person/team in charge of the service
***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.
**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:
**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.
**Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides.
**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:
**Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke.
**Quality of Service - Determines the allowable failure rate
**Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that?
**Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions
**Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service
**Process - Describes the process, if any, of the contracted service
OA and Business Architecture
One area where SOA has been gaining ground is in its power as a mechanism for defining business services [Steve Jones [http://www.infoq.com/minibooks/enterprise-soa Enterprise SOA Adoption Strategies] , "InfoQ", May 17, 2006, ISBN 978-1-84728-398-6] 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 [cite book |title=Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology |last=Spewak |first=Steven | author=Steven H. Spewak |coauthors=Hill, Steven C. |isbn=978-0894354366 Note that there is another edition that just lists Spewak as an author that may have better availability.] . 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, SOMA (
service-oriented modeling and architecture[http://www.amazon.com/dp/0132353741] [Bieberstein et al, Executing SOA: A Practical Guide for the Service-Oriented Architect (Paperback), IBM Press books, 978-0132353748] ) was announced by IBMas 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 [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-blueprints 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.
OA 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:
* HyPerformix IPS Performance Optimizer
HP Management Software / Mercury SOA Manager
IBM Tivoli Framework
Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing market conditions [Christopher Koch [http://www.cio.com.au/index.php/id;1350140708 A New Blueprint For The Enterprise] , "CIO Magazine", Mar 1 2005] . 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, SOA can be considered an architectural evolution rather than a revolution and captures many of the
best practices of previous software architectures. In communications systems, for example, there has been little development 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. [Bieberstein et al., Service-Oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap (The developerWorks Series) (Hardcover), IBM Press books, 2005, 978-0131870024]
Some have questioned whether SOA is just a revival of modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s)Fact|date=February 2007. 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 servicesFact|date=February 2007.
SOA is an architectural and design discipline conceived to achieve the goals of increased interoperability (information exchange, reusability, and composability), increased federation (uniting resources & apps while maintaining their individual autonomy & self-governance), and increased business & 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 & roadmap and adhere to principles of service-orientation. Arguments supporting the business and management aspects from SOA are outlined in various publications. [Martin van den berg et al. SOA for Profit, A Manager's Guide to Success with Service-Oriented Architecture (Hardcover), 978-9075414141 ]
A service is a stand-alone unit of functionality which is 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, and composability.
Challenges faced in SOA adoption
One obvious and common challenge faced is managing services
metadataFact|date=February 2007. 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.
Second biggest challenge is 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 is 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 Securityentry for more info.
As SOA and the WS-* specifications are constantly being expanded, updated and refined, there is a shortage of skilled people to work on SOA based systems, including the integration of services and construction of services infrastructure.
Interoperability is another important aspect in the SOA implementations. The WS-I organization has developed Basic Profile (BP) and Basic Security Profile (BSP) to enforce compatibility. [ [http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html WS-I Basic Profile] ] 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.
There is significant vendor hype concerning SOA that can create expectations that may not be fulfilled. Product stacks are still evolving 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. [ [http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9001155&source=NLT_ROI&nlid=44 Is There Real Business Value Behind the Hype of SOA?] , "Computerworld", June 19, 2006.] [See also:
Criticisms of SOA
Some criticisms [Tim Bray, XML co-founder - http://blogs.zdnet.com/service-oriented/?p=597] of SOA are based on the assumption that SOA is just another term for
Web Services. For example, some criticsWho|date=June 2008 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 [ [http://xml.sys-con.com/read/453082.htm Index XML documents with VTD-XML] ] [ [http://soa.sys-con.com/read/250512.htm The Performance Woe of Binary XML] ] [ [http://www.devx.com/xml/Article/36379 Manipulate XML Content the Ximple Way] ] .
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 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 Conceptwork.
Some criticsWho|date=June 2008 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 market place.
Adopting SOAs is therefore just the first (diagrammatic) step in defining a real business system. The next step in the design process is 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.
OA, Web 2.0, and mashups
Web 2.0refers 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 JavaFXuser interfaces, 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 [Dion Hinchcliffe [http://web2.wsj2.com/is_web_20_the_global_soa.htm Is Web 2.0 The Global SOA?] , "SOA Web Services Journal", 28 October 2005] [cite paper | url=http://www.alexandria.unisg.ch/Publikationen/37270| title=Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services | accessdate=2008-02-23 | author=Schroth, Christoph ; Janner, Till; | publisher=IT Professional 9 (2007), Nr. 3, p. 36-41, IEEE Computer Society | date=2007] [cite paper | url=http://www.alexandria.unisg.ch/publications/44891| title=Enterprise Mashups: Design Principles towards the Long Tail of User Need | accessdate=2008-07-08 | author=Hoyer, Volker ; Stanoesvka-Slabeva, Katarina; Janner, Till; Schroth, Christoph; | publisher=Proceedings of the 2008 IEEE International Conference on Services Computing (SCC 2008) | date=2008] .
Mashups are also considered by some to be 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), which 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. [Jason Bloomberg [http://www.zapthink.com/report.html?id=ZAPFLASH-2006320 Mashups and SOBAs: Which is the Tail and Which is the Dog?] , "Zapthink"]
Internet of Services
The term Web 2.0 has been coined by
Tim O'Reillyto describe a quickly growing set of Web based applications [cite web |url=http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html |title=What Is Web 2.0 |accessdate=2008-06-10 |publisher=Tim O'Reilly |date=2005-09-30 ] . A topic that has experienced enormous coverage recently is 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 [cite paper | url=http://www.alexandria.unisg.ch/Publikationen/37270| title=Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services | accessdate=2008-02-23 | author=Schroth, Christoph ; Janner, Till; | publisher=IT Professional 9 (2007), Nr. 3, p. 36-41, IEEE Computer Society | date=2007] .
The philosophies of Web 2.0 and SOA serve different user needs and thus expose differences with respect to the design and also the used technologies of 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. [cite paper | url=http://www.alexandria.unisg.ch/Publikationen/37270| title=Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services | accessdate=2008-02-23 | author=Schroth, Christoph ; Janner, Till; | publisher=IT Professional 9 (2007), Nr. 3, p. 36-41, IEEE Computer Society | date=2007] .
In an “Internet of Services,” all people, machines, and goods will have access to it by leveraging 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. [cite paper | url=http://csdl2.computer.org/comp/proceedings/wetice/2007/2879/00/28790003.pdf| title=Internet of Services—A SAP Research Vision| accessdate=2008-02-23 | author=Ruggaber, Rainer; | publisher= IEEE Computer Society | date=2007] .
OA 2.0 or Advanced SOA
Oracle is 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 [Paul Krill [http://www.infoworld.com/article/06/05/17/78420_HNsoa20_1.html Make way for SOA 2.0] , "InfoWorld ", May 17, 2006] .Even though Oracle indicates that Gartneris coining a new term, Gartner analysts indicate that they call this advanced SOA and it is 'whimsically' referred to as SOA 2.0. [Yefim Natis & Roy Schulte [http://www.gartner.com/DisplayDocument?ref=g_search&id=493863 Advanced SOA for Advanced Enterprise Projects] , "Gartner", July 13, 2006] 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 have criticized attaching a version number ("2.0") to an application architecture design approach, while others have stated that the "next generation" should apply to the evolution of SOA techniques from IT optimization to business development. [Joe McKendrick [http://blogs.zdnet.com/service-oriented/?p=652 Anti-SOA 2.0 petition nears 400] , "ZDNet.com", June 29, 2006]
Big ball of mud anti-pattern
Comparison of business integration software
Enterprise application integration
Enterprise Messaging System
Enterprise Integration Patterns
Enterprise service bus
Java Business Integration
Microsoft Connected Services Framework
Oracle SOA Suite
Software as a service
Public key infrastructure
Representational State Transfer
SAP Enterprise Services Architecture
Semantic service oriented architecture- contain ISO standards
Service component architecture
Service-oriented analysis and design
Search oriented architecturecomplementary pattern
Service-oriented architecture implementation framework
Sun Java CAPS
Business Intelligence 2.0(BI 2.0)
Data as a service
* SOA for the Business Developer: Concepts, BPEL, and SCA -- ISBN 978-158347-065-7
* Frank Leymann, Dimka Karastoyanova (Eds.) et al.: "Service Oriented Architecture – Overview of Technologies and Standards". Special Topic Issue Journal "it - Information Technology". [http://www.atypon-link.com/OLD/toc/itit/50/2 Vol. 50 (2008)Heft 2]
* Janner, Till ; Cañas Vaz, Miguel Angel ; Hierro, Juan J. ; Lizcano, David ; Reyes , Marcos ; Schroth, Christoph ; Soriano, Javier ; Hoyer, Volker: Enterprise Mashup: Putting a face on next generation global SOA. The 8th International Conference on Web Information Systems Engineering (WISE 2007). Nancy, France, 2007.- URL http://www.alexandria.unisg.ch/Publikationen/41338
* Schroth, Christoph ; Christ, Oliver: Brave New Web: Emerging Design Principles and Technologies as Enablers of a Global SOA. In: Proceedings of the 2007 IEEE International Conference on Services Computing (SCC 2007) : IEEE Computer Society, 2007.- 2007 IEEE International Conference on Services Computing (SCC 2007).- Salt Lake City, Utah, USA, S. 8.- URL http://www.alexandria.unisg.ch/Publikationen/37038
Wikimedia Foundation. 2010.