Impact of soa on it industry

Service-oriented architecture
From Wikipedia, the free encyclopedia

Jump to: navigation, search

The external links in this article or section may require cleanup to comply
with Wikipedia's content policies.
Please improve this article by removing excessive or inappropriate external links. Please remove
this tag when this is done. (talk)

The introduction to this article provides insufficient context for those unfamiliar with the
subject matter.
Please help improve the introduction to meet Wikipedia's layout standards. You can discuss the issue on the
talk page.

There is no widely agreed upon definition of service-oriented architecture other than its
literal translation that it is an architecture that relies on service-orientation as its
fundamental design principle. Service-orientation describes an architecture that uses
loosely coupled services to support the requirements of business processes and users.
Resources on a network[1] in a SOA environment are made available as independent
services that can be accessed without knowledge of their underlying platform
implementation.[2] These concepts can be applied to business, software and other types of
producer/consumer systems.

Contents
[hide]

• 1 Other SOA Concepts

• 2 SOA definitions
• 3 Why SOA?
• 4 SOA principles
• 5 Service-oriented design and development
o 5.1 Service contract
• 6 SOA and web service protocols
• 7 SOA, Web 2.0, and mashups
• 8 SOA 2.0 or Advanced SOA
• 9 What are the challenges faced in SOA adoption?
• 10 Criticisms of SOA
• 11 SOA and Business Architecture
• 12 SOA and network management architecture
• 13 Jargon
 • 14 Literature
o 14.1 Books, non-technical
o 14.2 Books, technical
o 14.3 Articles/Papers, non-technical
o 14.4 Articles/Papers, technical
o 14.5 Standards
• 15 References
• 16 See also

• 17 External links

[edit] Other SOA Concepts

Architecture is not tied to a specific technology. It may be implemented using a wide
range of technologies, including REST, RPC, DCOM, CORBA, Web Services or WCF.
SOA can be implemented using one 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 the
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

SOA can also be regarded as a style of information systems architecture that enables the
creation of applications that are built by combining loosely coupled and interoperable
services[citation needed]. 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. Applications running on either platform can also
consume services running on the other as Web services, which facilitates reuse.

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 WS-
Coordination extend 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 applications or portals[citation needed].

The use of Service component architecture (SCA) to implement SOA is a current area of
research.

[edit] SOA definitions

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). 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 definition with depth which can be applied to both the technology and
business domains.

• Open Group SOA Definition (SOA-Definition)[3]

• OASIS SOA Reference Model (SOA-RM)[4]
• What Is Service-Oriented Architecture? (XML.com)
• What is Service-Oriented Architecture? (Javaworld.com)
• Webopedia definition
• TechEncyclopedia definition
• Object Management Group (OMG ) SOA Special Interest Group definition
• WhatIs.com definition
• SearchWebServices.com Numerous SOA definitions by industry experts
Though many definitions of SOA limit themselves to technology or just web services,
this is predominantly pushed by technology vendors; in 2003 they talked just of web
services, while in 2006 the talk is of events and process engines.[citation needed]

[edit] Why SOA?

The main drivers for SOA adoption are that it links computational resources and
promotes their reuse. Enterprise architects believe that SOA can help businesses respond
more quickly and cost-effectively to changing market conditions[5] . This style of
architecture promotes reuse at the macro(service) level rather than micro(objects) level.
It can also simplify interconnection to - and usage of - existing IT (legacy) assets.

SOA Practitioners Guide: Why Services-Oriented Architecture? provides a high-level

summary on SOA.

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.[citation needed]

Some 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].

[edit] SOA principles

The following guiding principles define the ground rules for development, maintenance,
and usage of the SOA[6]

• Reuse, granularity, modularity, composability, componentization, and

interoperability
• Compliance to standards (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
 • 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]

In addition, the following factors should also be taken into account when defining a SOA
implementation:

• SOA Reference Architecture SOA Practitioners Guide Part 2: SOA Reference

Architecture covers the SOA Reference Architecture, which provides a worked
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.
• 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.
• Efficient use of system resources
• Service maturity and performance
• EAI Enterprise Application Integration

[edit] Service-oriented design and development

This section does not cite any references or sources.
Please help improve this section by adding citations to reliable sources. (help, get involved!)
Unverifiable material may be challenged and removed.

This article has been tagged since June 2006.

The modelling and design methodology for SOA applications has become known by the
terms service-oriented analysis and design and SOAD [8]. SOAD is a design methodology
for developing highly-agile systems in a consumer/producer model that abstracts
implementation from process, such that a service-provider can be modified or changed
without affecting the consumer.

[edit] Service contract

A service contract needs 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 the person/team is 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 web service protocols

This section does not cite any references or sources.
Please help improve this section by adding citations to reliable sources. (help, get involved!)
Unverifiable material may be challenged and removed.

This article has been tagged since June 2006.

SOA may be built on 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.

Service-oriented architecture is often defined as services exposed using the Web Services
Protocol Stack[citation needed] . The base level of web services standards relevant to SOA
includes the following:

• XML - a markup language for describing data in message payloads in a document

format
• HTTP (or HTTPS) - request/response protocol between clients and servers used to
transfer or convey information
• SOAP - a protocol for exchanging XML-based messages over a computer
network, normally using HTTP
• XACML - a markup language for expressing access control rules and policies.
• Web Services Description Language (WSDL) - XML-based service description
that describes the public interface, protocol bindings and message formats
required to interact with a web service
• Universal Description, Discovery, and Integration (UDDI) - An XML-based
registry to publish service descriptions (WSDL) and allow their discovery
Note, however, that a system does not necessarily need to use any or all of these
standards to be "service-oriented." For example, some service oriented systems have been
implemented using Corba, Jini and REST.

[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, Silverlight or JavaFX user
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[9].

Mashups are also regarded by some 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), 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 realisation of
SOA composite and business applications. [10]

[edit] SOA 2.0 or Advanced SOA

Amid much negative reaction, 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[11] . 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.[12] Most of the pure-play
middleware vendors (e.g., webMethods and TIBCO) have had SOA 2.0 attributes for
years. SOA 2.0 can therefore be regarded as "more marketing noise than anything else"[13]
and product evangelism rather than a new "way of doing things".

However, other industry commentators have criticized attaching a version number 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[14] .

[edit] What are the challenges faced in SOA adoption?

This section does not cite any references or sources.
Please help improve this section by adding citations to reliable sources. (help, get involved!)
Unverifiable material may be challenged and removed.

This article has been tagged since June 2006.

One obvious and common challenge faced is 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.

Another challenge is providing appropriate levels of security. Security model 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 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. 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 realise some or all of these benefits depending on the quality and
relevance of the system architecture and design[15] . See also: WS-MetadataExchange
OWL-S Abrobit Roy

[edit] Criticisms of SOA

Some criticisms of SOA are based on the assumption that SOA is just another term for
Web Services. For example, some critics 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.
However, there are emerging and open-source XML parsing technolgies, such as VTD-
XML, and various XML-compatible binary formats (http://vtd-
xml.sf.net/persistence.html) that promise to significantly improve the SOA performance.

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 Concept
work.

An informal survey by Network Computing placed SOA as the most despised buzzword
(November 2006).

Some critics 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 organisation 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.

[edit] SOA and Business Architecture

One area where SOA has been gaining ground is in its power as a mechanism for
defining business services and operating models 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 (Enterprise Architecture Planning by Steven
Spewak and Steven Hill). 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 Modelling and Architecture) was announced
by IBM as the first 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 on the Services and Architecture elements and leaving
implementation to the more technically focused standards.

[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 the recently published M.3060 Principles
for the Management Of Next Generation Networks recommendation from the ITU-T
SOA.

Tools for managing SOA infrastructure include:

• Symantec APM
• HyPerformix IPS Performance Optimizer
• HP Management Software / Mercury SOA Manager
• IBM Tivoli Framework
• Tidal Software Intersperse

[edit] Jargon
This section does not cite any references or sources.
Please help improve this section by adding citations to reliable sources. (help, get involved!)
Unverifiable material may be challenged and removed.

This article has been tagged since June 2006.

SOA is an architectural style rather than a product. Several vendors offer products which
can form the basis of, or enable, SOA--particularly Enterprise Service Bus (ESB)
products. ESBs provide infrastructure that can be purchased, implemented and leveraged
for SOA-based systems[citation needed]. SOA relies heavily on metadata design and
management. Metadata design and management products are also critical to
implementing SOA architectures. See the list of SOA related products for an overview
and ideas.
[edit] Literature
[edit] Books, non-technical

• Allen, Paul (2006). Service Orientation, winning strategies and best practices.
Cambridge, UK: Cambridge University Press. ISBN 0521843367.
• Bloomberg, Jason; Ronald Schmelzer (2006). Service Orient or Be Doomed! How
Service Orientation Will Change Your Business. Hoboken, New Yersey: WILEY.
ISBN 0-13-187002-5.
[edit] Books, technical

• Barry, Douglas K. (2003). Web Services and Service-Oriented Architectures: The

Savvy Manager's Guide. San Francisco: Morgan Kaufmann Publishers. ISBN 1-
55860-906-7.
• Bieberstein, Norbert; Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah
(2006). Service-Oriented Architecture Compass - Business Value, Planning and
Enterprise Roadmap. Upper Saddle River: Pearson. ISBN 0-13-187002-5.
• Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and
Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0.
• Erl, Thomas (2004). Service-Oriented Architecture: A Field Guide to Integrating
XML and Web Services. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-
142898-5.
• Hurwitz, Judith; Robin Bloor, Carol Baroudi, Marcia Kaufman (2006). Service
Oriented Architecture for Dummies. Hoboken: Wiley. ISBN 0-470-05435-2.
• Krafzig, Dirk; Karl Banke, Dirk Slama (2004). Enterprise SOA Service Oriented
Architecture Best Practices. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-
146575-9.
• Linthicum, David (2003). Next Generation Application Integration: From Simple
Information to Web Services. New York: Addison-Wesley Professional. ISBN
978-0201844566.
• Marks, Eric; Mark Werrell (2003). Executive’s Guide to Web Services. Hoboken:
John Wiley & Sons. ISBN 978-0471768944.
• Marks, Eric; Michael Bell (2006). -Service Oriented Architecture: A Planning
and Implementation Guide for Business and Technology. Hoboken: John Wiley &
Sons. ISBN 978-0471768944.
• Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services.
Addison Wesley. ISBN 0-321-18086-0.
• Pulier, Eric; Hugh Taylor (2005). Understanding Enterprise SOA. Greenwich:
Manning Publications. ISBN 1-932394-59-1.
[edit] Articles/Papers, non-technical

• Coenen, Alcedo (2006). SOA agility in practice (PDF). Via Nova Architectura.
• Jones, Steve (2005). Toward an acceptable definition of service (PDF). IEEE
Software.
[edit] Articles/Papers, technical

• Mittal, Kunal (2006). Requirements process for SOA projects, Part 1 of 3:

Capturing requirements for an SOA application - Initial requirements to build out
your SOA (HTML). IBM Developerworks.
• Shan, Tony; Hua, Winnie (2006). A Service-Oriented Solution Framework for
Internet Banking (PDF). International Journal of Web Services Research, Vol. 3,
Issue 1, pp 29-48.
• Shan, Tony; Hua, Winnie (2006). Solution Architecture for N-Tier Applications
(PDF). In Proc. of the 3rd IEEE International Conference on Services Computing
(SCC 2006), pp. 349-356.
• Wada, Hiroshi; Suzuki, Junichi (2006). A Model-Driven Development
Framework for Non-Functional Aspects in Service Oriented Grids (PDF). In Proc.
of 2nd IEEE International Conference on Autonomic and Autonomous Systems
(ICAS 2006).
• Wada, Hiroshi; Suzuki, Junichi (2006). A Service-Oriented Design Framework
for Secure Network Applications (PDF). In Proc. of the 30th IEEE International
Conference on Computer Software and Applications Conference (COMPSAC
2006).
• Wada, Hiroshi; Suzuki, Junichi (2006). Modeling Non-Functional Aspects in
Service Oriented Architecture (PDF). In Proc. of the 2006 IEEE International
Conference on Service Computing.
• Bieber, Guy (2000). Programming Service Oriented Programming (HTML).
Motorola.
[edit] Standards

• SOA Reference Model Technical Committee, OASIS (2006). A Reference Model

for Service Oriented Architecture. (PDF). OASIS.

[edit] References
1. ^ 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
deployed to distributed nodes on a network, and separate nodes for every (or
most) services could be prohibitively expensive.
2. ^ Channabasavaiah, Holley and Tuggle, Migrating to a service-oriented
architecture, IBM DeveloperWorks, 16 Dec 2003
3. ^ http://opengroup.org/projects/soa/doc.tpl?gdid=10632
4. ^ SOA Reference Model definition
5. ^ Christopher Koch A New Blueprint For The Enterprise, CIO Magazine, Mar 1
2005
6. ^ Yvonne Balzer Improve your SOA project plans, IBM, 16 July 2004
7. ^ Thomas Erl Serviceorientation.org - About the Principles, 2005-2006
8. ^ Zimmermann, Krogdahl and Gee, Elements of Service-Oriented Analysis and
Design, IBM DeveloperWorks, 02 Jun 2004
 9. ^ Dion Hinchcliffe Is Web 2.0 The Global SOA?, SOA Web Services Journal, 28
October 2005
10. ^ Jason Bloomberg Mashups and SOBAs: Which is the Tail and Which is the
Dog?, Zapthink
11. ^ Paul Krill Make way for SOA 2.0, InfoWorld , May 17, 2006
12. ^ Yefim Natis & Roy Schulte Advanced SOA for Advanced Enterprise Projects,
Gartner, July 13, 2006
13. ^ Sandra Rogers Patience Grasshopper…It’s a Learning Process, Business Trends
Quarterly, Q4, 2006
14. ^ Joe McKendrick Anti-SOA 2.0 petition nears 400, ZDNet.com, June 29, 2006
15. ^ Is There Real Business Value Behind the Hype of SOA?, Computerworld, June
19, 2006

[edit] See also

• Big ball of mud anti-pattern
• Business-driven development
• Comparison of business integration software
• Enterprise application integration
• Enterprise Messaging System
• Enterprise Integration Patterns
• Enterprise service bus
• Java Business Integration
• Microsoft Connected Services Framework
• Representational State Transfer
• Semantic service oriented architecture
• Service component architecture
• Service-oriented analysis and design
• Search oriented architecture complementary pattern
• Service-Oriented Architecture Implementation Framework
• Service Oriented Infrastructure
• SOA Governance

[edit] External links

• BPM & SOA Journal
• OASIS: Reference Model for Service Oriented Architecture
• SOA RQ
• The "Internet of Services": The Global SOA
• SOA Practitioners' Guide
• SOA Implementation Using Offshore partner
• What is a SOA service?
• UML Profile and Feature Model: Modeling Non-Functional Aspects in Service
Oriented Architecture
• What Is SOA? - An Introduction to Service-Oriented Computing
 • SOA Principles - An Introduction to the Service-Orientation Design Paradigm
• Advanced SOA Delivers an Advanced Enterprise
• SOA News

WHAT IS SOA??

Amidst all the SOA-related activity that is currently underway, there still remains a
significant amount of confusion as to what exactly constitutes a service-oriented
architecture. Some qualify an SOA project by the fact that Web services technologies are
being used, while others classify SOA as a Web-centric variation of object-oriented

design. by Thomas Erl What has become more clear than the actual meaning
of SOA is the strategic vision that has emerged around it. This vision is comprised of a
set of goals and benefits that most stakeholders fully expect to see realized when they
support and commit to SOA initiatives. However, because the "SOA" acronym has been
used to brand products, technologies, and even projects without a clear understanding of
its meaning, many of these expectations have been and will continue to remain
unfulfilled. For example, the common (and dangerous) assumption that a solution is
service-oriented solely because it uses Web services has led to much disappointment.
There is, in fact, a wealth of information out there that communicates the meaning of
SOA in detail. The only problem is that this information is fragmented - distributed
across marketing literature, technology specifications, media reports, and independent
research efforts. While there is no one recognized definition of SOA, there is a baseline
of concepts and principles that exists among all of the organizations, platforms, and
initiatives that have influenced and continue to shape the SOA movement. For any IT
professional, project team, or organization interested in moving ahead with SOA, this
baseline perspective is extremely important to understand because it reflects a current,
industry-level, and vendor-agnostic representation of what SOA is in the real world.
I recently completed the manuscript for my third SOA book as part of the Prentice Hall
Service-Oriented Computing Series from Thomas Erl. Although this book (entitled SOA:
Principles of Service Design) is dedicated to exploring the service-orientation design
paradigm and service design techniques, it begins with some introductory chapters that
leverage years of on-going industry research as part of my involvement in projects for
SOA Systems Inc. This research has been synthesized to establish the aforementioned
baseline perspective of SOA, and to further broaden the discussion to encompass the
service-orientation design paradigm and service-oriented computing as a whole.

The book manuscript (including the content on this site) was subjected to a rigorous
technical review involving over 60 reviewers from different vendors, organizations, and
professions across North America, Europe, and Asia. The book ended up being formally
endorsed by members of major SOA vendors, including IBM, Microsoft, Oracle, BEA,
Sun, SAP, HP, and Intel.
 With permission from Prentice Hall, I was able to publish some of the book’s
introductory content on a modest network of Web sites (in exchange for posting book
cover images on Web page footers). The primary reason these sites exist is to provide
convenient on-line reference content for readers of the book series. It also helps us avoid
publishing redundant content in the books, so that each title remains focused on its
specialized subject matter.

WhatIsSOA.com essentially acts as the starting point for these sites by establishing some
fundamental terminology and providing specific coverage of the strategic goals and
benefits that collectively represent the modern-day vision of SOA and service-oriented
computing. The last set of pages provide further supplementary content that addresses
implementation technologies, processes, and other deliverables that are common in real
world SOA projects.

Although this site positions SOA within the service-oriented computing platform, it only
hints at what it means for solution logic to be considered "service-oriented." That
particular topic deserves a study of its own, which is why I published
www.SOAPrinciples.com, a separate Web site dedicated to an exploration of service-
orientation.

Note that this site and SOAPrinciples.com are further supplemented with two additional
sites: www.SOAMethodology.com provides a generic set of processes for service
delivery, analysis, and design, and www.SOAGlossary.com is a master glossary
established in support of the series books. If you’d like to be notified of changes to these
sites and other events related to this book series and the associated SOA Magazine, send
a blank e-mail to: notify@soasystems.com

Services (Part I) The key to getting the most out of SOA lies within the
Services (Part II) knowledge of how to create "truly" service-oriented solution
The Service- logic. That knowledge has been documented as part of the
Orientation service-orientation design paradigm. As with object-orientation, by
Design Paradigm service-orientation represents a distinct approach to designing Thomas Erl
Origins and Iluences solution logic in support of a very specific set of goals.
of Service-Orientation This site introduces the design principles that comprise the service-orientation
(Part I) design paradigm and further explores various aspects and effects of applying
Origins and Influences service-orientation in the real world. Becoming proficient with the concepts
of Service-Orientation and principles of service-orientation equips you with an understanding of what
(Part II) is and is not considered "service-oriented" within the world of solution design.
This understanding leads to a clear comprehension of how to shape solution
Service-Orientation logic specifically in support of the strategic goals and benefits associated with
Design Principles SOA and service-oriented computing.
Standardized Service Furthermore, this comprehension provides you with a great deal of clarity
 Contracts when surveying the current SOA marketplace. It allows you to see past the
Service Loose (sometimes questionable) "SOA" branding used to market products and
Coupling professional services, and enables you to assess which of the available
Service Abstraction technologies, features, and resources are truly compatible with your business
Service Reusability requirements and with how you plan to position SOA and build service-
Service Autonomy oriented solutions within your organization.
Service Statelessness The criteria for this type of assessment no longer is whether something claims
Service to provide SOA support, but whether its actual features will help you realize
Discoverability the desired level of service-orientation within your solution designs. With such
Service Composability a clear perspective, you may discover that some of the most suitable products
Service-Orientation and technologies for building service-oriented solutions may not be branded
and Interoperability with "SOA" at all.
The content on this site originated from an introductory chapter I wrote for my
Effects of Service- third SOA book for the Prentice Hall Service-Oriented Computing Series from
Orientation on the Thomas Erl. This book, entitled SOA: Principles of Service Design, essentially
Enterprise provides an in-depth exploration of the service-orientation design paradigm,
Service-Orientation and has a separate chapter dedicated to each of its eight design principles. The
and the Concept of purpose of this site is to supply introductory content about service-orientation
"Application" for on-line reference purposes for readers of this book series. Publishing select
Service-Orientation content on-line helps us avoid having to add redundant content within the
and the Concept of individual series titles.
"Integration" The manuscript for SOA: Principles of Service Design (including the content
The Service on this site) underwent a thorough technical review involving over 60
Composition reviewers from different vendors, organizations, and professions across North
America, Europe, and Asia. The book has been formally endorsed by members
Service-Orientation of major SOA vendors, including IBM, Microsoft, Oracle, BEA, and Intel.
in the Real World If you haven’t already, I would recommend you visit www.WhatIsSOA.com
Life Before prior to reading through the pages on this site. Many of the terms and concepts
Service-Orientation referenced here are introduced at WhatIsSOA.com, along with descriptions of
(Part I) the individual strategic goals and benefits of SOA and service-oriented
Life Before computing. Having an appreciation of the overall SOA vision provides you
Service-Orientation with a strategic context when learning about service-orientation. As explained
(Part II) in Chapter 16 of SOA: Principles of Service Design, there are concrete links
The Need for that exist between applying each of the service-orientation design principles
Service-Orientation and realizing the goals and benefits of service-oriented computing.
(Part I) Note that this site and WhatIsSOA.com are further supplemented with two
The Need for additional sites: www.SOAMethodology.com provides a generic set of
Service-Orientation processes for service delivery, analysis, and design, and
(Part II) www.SOAGlossary.com is a master glossary established in support of the
Challenges Introduced series books. If you’d like to be notified of changes to these sites and other
by Service-Orientation events related to this book series and the associated SOA Magazine, send a
(Part I) blank e-mail to: notify@soasystems.com
Challenges Introduced
by Service-Orientation
(Part II)
Additional
 Considerations

Additional Resources
Web Sites
Book Series
Training
Consulting

Home SOA Books SOA Magazine What is SOA? SOA Copyright © 2006-2007 SOA
Methodology SOA Glossary Legal Systems Inc.