Service Oriented Architecture SOA v1.0

SERVICE ORIENTED
ARCHITECTURE
SOA
Enlaces interesantes:
- Wikipedia, buscar SOA, pero en inglés
- http://arquitecturaorientadaaservicios.blogspot.com/
- www.microsoft.com/soa
Service Oriented Architecture Página 2 de 48

1 http://en.wikipedia.org/wiki/Service-
oriented_architecture
In computing, service-oriented architecture (SOA) provides methods for systems

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

1.1 Contents
[hide]
1 Description
o 1.1 Overview
o 1.2 Introduction
o 1.3 Requirements
o 1.4 Principles
o 1.5 Web services approach
o 1.6 SOA and Web service protocols
o 1.7 Other SOA concepts
o 1.8 SOA definitions
o 1.9 Service contract
o 1.10 SOA and business architecture
o 1.11 SOA and network management architecture
2 Discussion
o 2.1 Benefits
o 2.2 Challenges in adopting SOA
o 2.3 Criticisms of SOA
3 Extensions
o 3.1 SOA, Web 2.0, and mashups
o 3.2 Web 2.0
4 See also
5 References
1.2 [edit] Description
1.2.1 [edit] Overview

A SOA.
Companies have long sought to integrate existing systems in order to implement

information technology (IT) support for business processes that cover all present and
prospective systems requirements needed to run the business end-to-end. A variety of
designs serve this end, ranging from rigid point-to-point electronic data interchange
(EDI) interactions to web auctions. By updating older technologies, for example by
Internet-enabling EDI-based systems, companies can make their IT systems available to
internal or external customers; but the resulting systems have not proven flexible
enough to meet business demands that require a flexible, standardized architecture to
better support the connection of various applications and the sharing of data.
SOA offers one such prospective architecture. It unifies business processes by

structuring large applications as an ad hoc collection of smaller modules called
"services". Different groups of people both inside and outside an organization can use
these applications, and new applications built from a mix of services from the global
pool exhibit greater flexibility and uniformity. 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 affiliated companies. For example: interacting with a rental-
car company's reservation system from an airline's reservation system.
Service Oriented Architecture (SOA) provides a design framework with a view to

realizing rapid and low-cost system development and to improving total system-
quality. SOA may use web services standards and web technologies and is rapidly
becoming a standard approach for enterprise information systems.
Web services face significant challenges because of particular requirements. Applying

the SOA paradigm to a real-time system presents many problems, including response
time, support of event-driven, asynchronous parallel applications, complicated human

interface support, reliability, etc. This article defines SOA and includes detailed
discussion on several issues that arise when applying SOA to industrial systems.
1.2.2 [edit] Introduction
One can define a service-oriented architecture (SOA) as a group of services that

communicate with each other. The process of communication involves either simple
data-passing or two or more services coordinating some activity. Intercommunication
implies the need for some means of connecting two or more services to each other.
SOAs build applications out of software services. Services comprise intrinsically

unassociated units of functionality that have no calls to each other embedded in them.
They typically implement functionality most humans would recognize as a service, such
as filling out an online application for an account, viewing an online bank-statement, or
placing an online booking or airline ticket order. Instead of services embedding calls to
each other in their source code, they use defined protocols that 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 often end up 100 to 1,000 times larger.[citation needed]
A software developer or software engineer associates individual SOA objects by using

orchestration. In the process of orchestration, a software engineer or process engineer
associates relatively large chunks of software functionality (services) in a non-
hierarchical arrangement (in contrast to a class hierarchy) by using a special software
tool that contains an exhaustive list of all of the services, their characteristics, and a
means to record the designer's choices that the designer can manage and the software
system can consume and use at run-time.
Underlying and enabling all of this requires metadata in sufficient detail to describe
not only the characteristics of these services, but also the data that drives them.
Programmers have made extensive use of XML in SOA to structure data that they wrap
in a nearly exhaustive description-container. Analogously, WSDL typically describe the
services themselves, while SOAP describes the communications protocols. Whether
these description languages are the best possible for the job, and whether they will
remain the favorites in the future, remains an open question. In the meantime SOA
depends on data and services that are described using some implementation of
metadata that meets the following two criteria:
1. the metadata must 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. the metadata must also come in a form that system designers can understand
and manage with a reasonable expenditure of cost and effort
SOA has the goal of allowing users to string together fairly large chunks of functionality
to form ad hoc applications that are built almost entirely from existing software
services. The larger the chunks, the fewer the interface points required to implement
any given set of functionality; however, very large chunks of functionality may not
prove sufficiently granular for easy reuse. Each interface brings with it some amount of
processing overhead, so there is a performance consideration in choosing the
granularity of services. The great promise of SOA suggests that the marginal cost of
creating the n-th application is low, as all of the software required already exists to
satisfy the requirements of other applications. Ideally, one requires only orchestration
to produce a new application.
For this to operate, no interactions must exist between the chunks specified or within
the chunks themselves. Instead, the interaction of services (all of them unassociated
peers) is specified by humans in a relatively ad hoc way with the intent driven by newly
emergent business requirements. Thus the need for services as much larger units of
functionality than traditional functions or classes, lest the sheer complexity of
thousands of such granular objects overwhelm the application designer. Programmers
develop the services themselves using traditional languages like Java, C#, C, C++ or
COBOL.
SOA services feature loose coupling, in contrast to the functions that a linker binds
together to form an executable, to a dynamically linked library or to an assembly. SOA
services also run in "safe" wrappers such as Java or .NET, and other programming
languages that manage memory allocation and reclamation, allow ad hoc and late
binding, and provide some degree of indeterminate data typing.
As of 2008, increasing numbers of third-party software companies offer 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, have also started making
significant progress in this direction.
SOA as an architecture relies on service-orientation as its fundamental design

principle[4]. In a SOA environment, users can access independent services without
knowledge of their underlying platform implementation[5].
SOA relies on services exposing their functionality via interfaces that other applications
and services can read to understand how to utilize those services.

1.2.3 [edit] Requirements
In order to efficiently use a SOA, one must[citation needed] 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.
1.2.4 [edit] Principles
The following guiding principles define the ground rules for development,
maintenance, and usage of the SOA[6]:
Reuse, granularity, modularity, composability, componentization, portability,

and interoperability
Standards compliance (both common and industry-specific)
Services identification and categorization, provisioning and delivery, and
monitoring and tracking
The following specific architectural principles for design and service definition focus
on specific themes that influence the intrinsic behaviour of a system and the style of its
design:
Service encapsulation – Many web services are consolidated to be used under

the SOA. Often such services were not planned to be under SOA.
Service loose coupling – Services maintain a relationship that minimizes
dependencies and only requires that they maintain an awareness of each other
Service contract – Services adhere to a communications agreement, as defined
collectively by one or more service description documents
Service abstraction – Beyond what is described in the service contract, services
hide logic from the outside world
Service reusability – Logic is divided into services with the intention of
promoting reuse
Service composability – Collections of services can be coordinated and
assembled to form composite services
Service autonomy – Services have control over the logic they encapsulate

Service optimization – All else equal, high-quality services are generally
considered preferable to low-quality ones
Service discoverability – Services are designed to be outwardly descriptive so
that they can be found and assessed via available discovery mechanisms[7]
Service Relevance – Functionality is presented at a granularity recognized by
the user as a meaningful service
The following references provide additional considerations for defining a SOA

implementation:
SOA Reference Architecture provides a working design of an enterprise-wide

SOA implementation with detailed architecture diagrams, component
descriptions, detailed requirements, design patterns, opinions about standards,
patterns on regulation compliance, standards templates etc.[8]
Life cycle management SOA Practitioners Guide Part 3: Introduction to Services
Lifecycle introduces the Services Lifecycle and provides a detailed process for
services management though the service lifecycle, from inception 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, one might take the following factors into account when defining a SOA
implementation:
efficient use of system resources

service maturity and performance
EAI Enterprise Application Integration
1.2.5 [edit] Web services approach
Web services can implement a service-oriented architecture. Web services make

functional building-blocks accessible over standard Internet protocols independent of
platforms and programming languages. These services can be new applications or just
wrapped around existing legacy systems to make them network-enabled.
Each SOA building block can play one or both of two roles:
1. Service provider
The service provider creates a Web service and possibly publishes its interface
and access information to the service registry. Each provider must decide which
services to expose, how to make trade-offs between security and easy
availability, how to price the services, or (if no charges apply) how to exploit
them for other value. The provider also has to decide what category the service
should be listed in for a given broker service and what sort of trading partner
agreements are required to use the service. It registers what services are

available within it, and lists all the potential service recipients. The
implementer of the broker then decides the scope of the broker. Public brokers
are available through the Internet, while private brokers are only accessible to
a limited audience, for example, users of a company intranet. Furthermore, the
amount of the offered information has to be decided. Some brokers specialize
in many listings. Others offer high levels of trust in the listed services. Some
cover a broad landscape of services and others focus within an industry. There
are also brokers that catalog other brokers. Depending on the business model,
brokers can attempt to maximize look-up requests, number of listings or
accuracy of the listings. The Universal Description Discovery and Integration
(UDDI) specification defines a way to publish and discover information about
Web services. Other service broker technologies include for example ebXML
(Electronic Business using eXtensible Markup Language) and those based on
the ISO/IEC 11179 Metadata Registry (MDR) standard.
2. Service requester
The service requester or Web service client locates entries in the broker
registry using various find operations and then binds to the service provider in
order to invoke one of its Web services. Which service the service-requesters
need, they have to take it into the Brokers, then bind it with respective service
and then use it. They can access multiple services, if the service provide
multiple services.
1.2.6 [edit] SOA and Web service protocols
This section does not cite any references or sources. Please help improve this
article by adding citations to reliable sources. Unverifiable material may be
challenged and removed. (June 2006)
Implementors commonly build SOAs using Web services standards (for example, using
SOAP) that have gained[when?] broad industry acceptance. These standards (also
referred to as Web Service specifications) also provide greater interoperability and
some protection from lock-in to proprietary vendor software. One can, however,
implement SOA using any service-based technology, such as Jini, CORBA or REST.
1.2.7 [edit] Other SOA concepts
Architectures can operate independently of specific technologies[3]. Designers can

implement SOA using a wide range of technologies, including SOAP, REST, RPC, DCOM,
CORBA, Web Services or WCF (Microsoft's implementation of Webservice forms a part
of WCF). SOA can be implemented using one or more of these protocols and, for
example, might use a file-system mechanism to communicate data conforming to a
defined interface-specification between processes conforming to the SOA concept. The
key is independent services with defined interfaces that can be called to perform their
tasks in a standard way, without a service having foreknowledge of the calling

application, and without the application having or needing knowledge of how the
service actually performs its tasks.
Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice
Hall, 2005
SOA Meta Model, The Linthicum Group, 2007
Service-Oriented Modeling Framework (SOMF) Version 2.0
One can also regard SOA as a style of information systems architecture that enables
the creation of applications that are built by combining loosely coupled and
interoperable services[9]. These services inter-operate based on a formal definition (or
contract, e. g., WSDL) that is independent of the underlying platform and programming
language. The interface definition hides the implementation of the language-specific
service. SOA-based systems can therefore function independently of development
technologies and platforms (such as Java, .NET etc). Services written in C# running on
.NET platforms and services written in Java running on Java EE platforms, for example,
can both be consumed by a common composite application (or client). Applications
running on either platform can also consume services running on the other as Web
services that facilitates reuse. Managed environments can also wrap COBOL legacy
systems and present them as software services. This has extended the useful life of
many core legacy systems indefinitely, no matter what language they originally used.

SOA can support integration and consolidation activities within complex enterprise
systems, but SOA does not specify or provide a methodology or framework for
documenting capabilities or services.
High-level languages such as BPEL and specifications such as WS-CDL and 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 architects can in turn incorporate into workflows and business
processes implemented in composite applications or portals[citation needed].
The use of Service Component Architecture (SCA) to implement SOA is a current area
of research.
How can a SOA address interoperability and reusability challenges of computing

environments and simplify the heterogeneous business and technological landscapes
built over decades? SOA introduces another concept to help practitioners to
understand their complex environments by modeling practices. These disciplines are
introduced by the service-oriented modeling paradigm[2], a SOA framework that
identifies the various disciplines that guide SOA practitioners to conceptualize, analyze,
design, and architect their service-oriented assets. Thus, the 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 modeling pillars enable practitioners to craft an effective
project plan and to identify the milestones of a service-oriented initiative — either a
small project, a large-scale business, or a technological venture. SOMF also provides a
common language, a modeling notation to address one of the major intrinsic
collaboration requirements of our times: alignment between business and IT
organizations. This crucial vocabulary, if employed, can also illustrate the following
SOA principles:
Business Traceability
Architectural Best-Practices Traceability
Technological Traceability
SOA Value Proposition
Software Assets Reuse
SOA Integration Strategies
Technological Abstraction and Generalization
Architectural Components Abstraction
"Service-Oriented Modeling Framework (SOMF) Example".

http://www.modelingconcepts.com/pdf/SOMF_ANALYSIS_MODELING.pdf.
"Download SOMF Examples & Language Notation".
http://www.modelingconcepts.com/pages/download.htm.

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

OASIS SOA Reference Model (SOA-RM)[11]
In addition, SOA is an approach to architecture, whereby business services are the key
organizing principles that drive the design of IT to be aligned with business needs.
1.2.9 [edit] Service contract
A service contract needs[citation needed] to have the following components:
Header
o Name – Name of the service. Should indicate in general terms what it
does, but not be the only definition
o Version – The version of this service contract
o Owner – The person/team in charge of the service
o RACI
 Responsible – The role/person/team responsible for the
deliverables of this contract/service. All versions of the contract
 Accountable – Ultimate Decision Maker in terms of this
contract/service
 Consulted – Who must be consulted before action is taken on
this contract/service. This is two-way communication. These
people have an impact on the decision or the execution of that
decision.
 Informed – Who must be informed that a decision or action is
being taken. This is a one-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
some external clients, each with different invocation means and
interfaces. 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
1.2.10 [edit] SOA and business architecture
SOA has gained ground as a mechanism for defining business services[12] and operating
models (e. g., Business-Agile Enterprise) and thus provide a structure for IT to deliver
against the actual business requirements and adapt in a similar way to the business.
The purpose of using SOA as a business mapping tool is to ensure that the services
created properly represent the business view and are not just what technologists think
the business services should be. At the heart of SOA planning is the process of defining
architectures for the use of information in support of the business, and the plan for

implementing those architectures[13]. Enterprise Business Architecture should always
represent the highest and most dominant architecture. Every service should be
created with the intent to bring value to the business in some way and must be
traceable back to the business architecture.
Within this area, IBM announced SOMA (service-oriented modeling and

architecture[14]) as the first publicly announced SOA-related methodology in 2004.
Since then, efforts have been made to move towards greater standardization and the
involvement of business objectives, particularly within the OASIS standards group and
specifically the SOA Adoption Blueprints group. All of these approaches take a
fundamentally structured approach to SOA, focusing more on the Services and
Architecture elements and leaving implementation to the more technically focused
standards. Another pertinent example is SAP Enterprise Services Architecture, which is
focused on a strict governance process and the use of semantics to improve the
usefulness of services in business process innovation.
1.2.11 [edit] SOA and network management architecture
The principles of SOA are currently being applied to the field of network management.
Examples of service-oriented network management architectures are TS 188 001 NGN
Management OSS Architecture from ETSI, and M.3060 Principles for the Management
Of Next Generation Networks recommendation from the ITU-T.
Tools for managing SOA infrastructure include:
HP Management Software / Mercury SOA Manager

HyPerformix IPS Performance Optimizer
IBM Tivoli Framework
1.3 [edit] Discussion
1.3.1 [edit] Benefits
Enterprise architects believe that SOA can help businesses respond more quickly and
cost-effectively to changing market conditions[15]. This style of architecture promotes
reuse at the macro (service) level rather than micro (classes) level. It can also simplify
interconnection to – and usage of – existing IT (legacy) assets.
In some respects, one can regard SOA as an architectural evolution rather than as a
revolution. It captures many of the best practices of previous software architectures.
In communications systems, for example, little development has taken place of
solutions that use truly static bindings to talk to other equipment in the network. By

formally embracing a SOA approach, such systems are better positioned to stress the
importance of well-defined, highly inter-operable interfaces[16].
Some[who?] have questioned whether SOA is just a revival of modular programming

(1970s), event-oriented design (1980s) or interface/component-based design
(1990s)[citation needed]. SOA promotes the goal of separating users (consumers) from the
service implementations. Services can therefore be run on various distributed
platforms and be accessed across networks. This can also maximize reuse of
services[citation needed].
SOA is an architectural and design discipline conceived to achieve the goals of

increased interoperability (information exchange, reusability, and composability),
increased federation (uniting resources and applications while maintaining their
individual autonomy and self-governance), and increased business and technology
domain alignment.
Service-Oriented Architecture (SOA) is an architectural approach (or style) for

constructing complex software-intensive systems from a set of universally
interconnected and interdependent building blocks, called services.
SOA realizes its business and IT benefits through utilizing an analysis and design
methodology when creating services that ensures they are consistent with the
architectural vision and roadmap, and adhere to principles of service-orientation.
Arguments supporting the business and management aspects from SOA are outlined in
various publications[17].
A service comprises a stand-alone unit of functionality available only via a formally

defined interface. Services can be some kind of "nano-enterprises" that are easy to
produce and improve. Also services can be "mega-corporations" that are constructed
as coordinated work of sub-ordinate services.
Services generally adhere to the following principles of service-orientation:
abstraction
autonomy
composability
discoverability
formal contract
loose coupling
reusability
statelessness
A mature rollout of SOA effectively defines the API of the organization.
Implementation of services should be treated as separate projects from the larger

project for three reasons:

It promotes the concept to the business that services can be delivered quickly
and independently from the larger and slower-moving projects common in the
organization. The business starts understanding systems and simplified user
interfaces calling on services. This advocates agility.
It promotes the decoupling of services from its consuming project. This
encourages good design where the service is designed without knowing who its
consumers are.
Documentation and test artifacts of the service are not embedded within the
detail of the larger project. This is important when the service needs to be
reused later.
An indirect benefit of SOA is dramatically simplified testing. Services are autonomous,

stateless, with fully documented interfaces, and separate from the cross-cutting
concerns of the implementation. The industry has never been exposed to this
circumstance before.
If appropriate test data is defined in the organization, 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. The service can be
tested as a 'black box' using existing stubs corresponding to the services it calls. Test
environments can be constructed where the primitive and out-of-scope services are
stubs, while the remainder 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. Testing 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. Managing
data state of idempotent services is the only complexity.
Examples may prove useful to aid in documenting a service to the level where it
becomes useful. The documentation of some API's within the Java Community Process
are good examples. As these are exhaustive, staff would typically use only important
subsets. The 'ossjsa.pdf' file within JSR-89 is an example for such a file. JSR-89 Spec
Dowmload
1.3.2 [edit] Challenges in adopting SOA
One obvious and common challenge faced involves managing services metadata[citation
needed]
. SOA-based environments can include many services that 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 issues across teams, and hence SOA
Governance comes into picture.

Another challenge involves the lack of testing in SOA space. There are no sophisticated
tools that provide testability of all headless services (including message and database
services along with web services) in a typical architecture. Lack of horizontal trust
requires that both producers and consumers test services on a continuous basis. SOA's
main goal is to deliver Agility to Businesses. Therefore it is important to invest in a
testing framework (build or buy) that would provide you with the visibility required to
find the culprit in your architecture in no time. The Business Agility requires from SOA
services to be controlled by the business goals and directives as defined in the Business
Motivation Model (BMM)[18].
Another challenge relates to providing appropriate levels of security. Security models

built into an application may no longer suffice 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 information.
As SOA and the WS-* specifications practitioners constantly expand, update and refine
their output, there is a shortage of skilled people to work on SOA-based systems,
including the integration of services and construction of services infrastructure.
Interoperability becomes an important aspect of SOA implementations. The WS-I

organization has developed Basic Profile (BP) and Basic Security Profile (BSP) to
enforce compatibility[19]. Testing tools have been designed by WS-I to help assess
whether web services are conformant with WS-I profile guidelines. Additionally,
another charter has been established to work on the Reliable Secure Profile.
Significant vendor hype exists concerning SOA; this can create expectations that may
not be fulfilled. Product stacks continue to evolve as early adopters test the
development and runtime products with real-world problems. SOA does not guarantee
reduced IT costs, improved systems agility or faster time-to-market. Successful SOA
implementations may realize some or all of these benefits depending on the quality
and relevance of the system architecture and design[20] [21].
SOA efforts are routinely initiated by internal IT delivery organizations, and some of
these improperly introduce concepts to the business so it remains misunderstood. The
adoption starts meeting IT delivery needs instead of those of the business, so the
result is an organization with superlative laptop provisioning services, instead of one
that can quickly respond to market opportunities. Business Leadership also becomes
convinced that the organization is executing on SOA well.
As one of the most important benefits of SOA is its ease of reuse. Therefore
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.
Conversely, units must be encouraged to reuse services. This requires a few new
governance components:

Each business unit creating services must have an appropriate support
structure in place to deliver on its service level obligations, and to support
enhancing existing services strictly for the benefit of others. This is typically
quite foreign to business leaders.
Each business unit consuming services accepts the apparent risk of reusing
services outside their own control, with the attendant external project
dependancies, etc.
An innovative funding model is needed as incentive to drive these behaviors
above. Business units normally pay the IT Organization to assist during projects,
and then to operate the environment. Corporate incentives should discount
these costs to service providers, and create internal revenue streams from
consuming business units to the service provider. These streams should be less
than the costs of a consumer simply building it the old-fashioned way. ----
1.3.3 [edit] Criticisms of SOA
Some criticisms[22] of SOA depend on the assumption that SOA is just another term for
Web Services. For example, some critics[who?] claim SOA results in the addition of XML
layers, introducing XML parsing and composition. In the absence of native or binary
forms of Remote Procedure Call (RPC), applications could run slower and require more
processing power, increasing costs. Most implementations do incur these overheads,
but SOA can be implemented using technologies (for example, Java Business
Integration (JBI)) that 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[23][24][25].
Stateful services require both the consumer and the provider to share the same
consumer-specific context, which is either included in or referenced by messages
exchanged between the provider and the consumer. This constraint has the drawback
that it could reduce the overall scalability of the service provider because it might need
to remember the shared context for each consumer. It also increases the coupling
between a service provider and a consumer and makes switching service providers
more difficult.
Another concern is that WS-* standards and products are still evolving (e. g.,
transaction, security), and SOA can thus introduce new risks unless properly managed
and estimated with additional budget and contingency for additional Proof of Concept
work.
Some critics[who?] feel SOA is merely an obvious evolution of currently well-deployed

architectures (open interfaces, etc).
A SOA being an architecture is the first stage of representing the system components
that interconnect for the benefit of the business. At this level a SOA is just an evolution

of an existing architecture and business functions. SOAs are normally associated with
interconnecting back-end transactional systems that are accessed via web services.
The real issue with any IT "architecture" is how one defines the information
management model and operations around it that deal with information privacy,
reflect the business' 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 that is normally omitted from IT system design. Many
systems, including SOAs, hard-code the operations, goods and services of the
organization, thus restricting their online service and business agility in the global
marketplace.
Adopting SOAs is therefore just the first step in defining a real business system. The
next step in the design process covers the definition of a Service Delivery Platform
(SDP) and its implementation. It is in the SDP design phase where one defines the
business information models, identity management, products, content, devices, and
the end user service characteristics, as well as how agile the system is so that it can
deal with the evolution of the business and its customers.
1.4 [edit] Extensions
1.4.1 [edit] SOA, Web 2.0, and mashups
Web 2.0 refers to a "second generation" of Web sites, primarily distinguished by the
ability of visitors to contribute information for collaboration and sharing. Web 2.0
applications use Web services and may include AJAX, Flash, or JavaFX user interfaces,
Web syndication, blogs, and wikis. While there are no set standards for Web 2.0, it is
characterized by building on the existing Web server architecture and using services.
Web 2.0 can therefore be regarded as displaying some SOA characteristics[26][27][28].
Some commentators[who?] also regard mashups as Web 2.0 applications. The term
Enterprise mashups has been coined to describe Web applications that combine
content from more than one source into an integrated experience that share many of
the characteristics of service-oriented business applications (SOBAs). SOBAs are
applications composed of services in a declarative manner. There is ongoing debate
about "the collision of Web 2.0, mashups, and SOA," with some stating that Web 2.0
applications are a realization of SOA composite and business applications[29].
1.4.2 [edit] Web 2.0
Tim O'Reilly coined the term Web 2.0 to describe a perceived, quickly growing set of
Web-based applications[30]. A topic that has experienced extensive coverage involves

the relationship between Web 2.0 and Service-Oriented Architectures (SOAs). SOA is
considered as the philosophy of encapsulating application logic in services with a
uniformly defined interface and making these publicly available via discovery
mechanisms. The notion of complexity-hiding and reuse, but also the concept of
loosely coupling services has inspired researchers to elaborate on similarities between
the two philosophies, SOA and Web 2.0, and their respective applications. Some argue
Web 2.0 and SOA have significantly different elements and thus can not be regarded
“parallel philosophies”, whereas others consider the two concepts as complementary
and regard Web 2.0 as the global SOA[31].
The philosophies of Web 2.0 and SOA serve different user needs and thus expose
differences with respect to the design and also the technologies used in real-world
applications. However, very recently, numerous novel use-cases demonstrate the great
potential of combining technologies and principles of both Web 2.0 and SOA [32].
In an "Internet of Services", all people, machines, and goods will have access via the
network infrastructure of tomorrow. The Internet will thus offer services for all areas
of life and business, such as virtual insurance, online banking and music, and so on.
Those services will require a complex services infrastructure including Service delivery
platforms bringing together demand and supply. Building blocks for the Internet of
Services are SOA, Web 2.0 and semantics on the technology side as well as novel
business models, and approaches to systematic and community based innovation [33].
Even though Oracle indicates that Gartner is coining a new term, Gartner analysts
indicate that they call this advanced SOA and "whimsically" refer to it as SOA 2.0[34].
Most of the major middleware vendors (e. g., webMethods, TIBCO Software, IBM, Sun
Microsystems, and Oracle) have had some form of SOA 2.0 attributes for years.
However, some other industry commentators[who?] have criticized attaching a version

number ("2.0") to an application-architecture design-approach, while others[who?] have
stated that the "next generation" should apply to the evolution of SOA techniques
from IT optimization to business development[35].
1.5 [edit] See also
Big ball of mud anti-pattern Wikimedia Commons has media

Business-Agile Enterprise related to: Service-oriented
Business-driven development architecture
Business Intelligence 2.0 (BI 2.0)
Comparison of business integration
Public key infrastructure
software
Representational State Transfer
Digital signature
SAP Enterprise Services

Enterprise application integration Architecture
Enterprise Integration Patterns Search oriented architecture
Enterprise Messaging System complementary pattern
Enterprise service bus Semantic service oriented
Event-driven programming architecture – contain ISO
Integration Objects standards
Java Business Integration Service bureau
Microsoft Connected Services Service component architecture
Framework Service layer
Open ESB Service-oriented analysis and
Oracle SOA Suite design
Service-oriented architecture
implementation framework
Service-oriented modeling
SOA Governance
Software as a service
Software as a service Integration
Sun Java CAPS
Web Oriented Architecture
1.6 [edit]

2 http://es.wikipedia.org/wiki/Arquitectura_orientada_
a_servicios
2.1 Arquitectura orientada a servicios
Saltar a navegación, búsqueda
La Arquitectura Orientada a Servicios (en inglés Service Oriented Architecture), es un

concepto de arquitectura de software que define la utilización de servicios para dar
soporte a los requisitos del negocio.
Permite la creación de sistemas altamente escalables que reflejan el negocio de la

organización, a su vez brinda una forma estándar de exposición e invocación de
servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la
interacción entre diferentes sistemas propios o de terceros.
SOA define las siguientes capas de software:
Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o

tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
De exposición de funcionalidades - Donde las funcionalidades de la capa
aplicativas son expuestas en forma de servicios (servicios web);
De integración de servicios - Facilitan el intercambio de datos entre elementos
de la capa aplicativa orientada a procesos empresariales internos o en
colaboración;
De composición de procesos - Que define el proceso en términos del negocio y
sus necesidades, y que varía en función del negocio;
De entrega - donde los servicios son desplegados a los usuarios finales.
SOA proporciona una metodología y un marco de trabajo para documentar las

capacidades de negocio y puede dar soporte a las actividades de integración y
consolidación.

2.2 Contenido
[ocultar]
1 Definiciones SOA
2 Diseño y desarrollo de SOA
3 Lenguajes de alto nivel
4 Diferencias con otras arquitecturas
5 Beneficios
6 Literatura
7 Enlaces externos
2.3 Definiciones SOA [editar]
Término Definición / Comentario
Servicio Una función sin estado (Existen servicios asíncronos en los que una
solicitud a un servicio crea, por ejemplo, un archivo, y en una segunda
solicitud se obtiene ese archivo), auto-contenida, que acepta una(s)
llamada(s) y devuelve una(s) respuesta(s) mediante una interfaz bien
definida. Los servicios pueden también ejecutar unidades discretas de
trabajo como serían editar y procesar una transacción. Los servicios no
dependen del estado de otras funciones o procesos. La tecnología
concreta utilizada para prestar el servicio no es parte de esta definición.
Orquestación Secuenciar los servicios y proveer la lógica adicional para procesar

datos. No incluye la presentación de los datos. Coordinación.
Sin estado No mantiene ni depende de condición pre-existente alguna. En una SOA

los servicios no son dependientes de la condición de ningún otro
servicio. Reciben en la llamada toda la información que necesitan para
dar una respuesta. Debido a que los servicios son "sin estado", pueden
ser secuenciados (orquestados) en numerosas secuencias (algunas
veces llamadas tuberías o pipelines) para realizar la lógica del negocio.
Proveedor La función que brinda un servicio en respuesta a una llamada o petición

desde un consumidor.

Consumidor La función que consume el resultado del servicio provisto por un
proveedor.
2.4 Diseño y desarrollo de SOA [editar]
La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y

diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco
de trabajo para el desarrollo de software como un marco de trabajo de
implementación. Para que un proyecto SOA tenga éxito los desarrolladores de
software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes
que son orquestados por clientes o middleware para implementar los procesos de
negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este
modelo en términos de planificación, herramientas e infraestructura.
Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están

hablando de un juego de servicios residentes en Internet o en una intranet, usando
servicios web. Existen diversos estándares relacionados a los servicios web. Incluyen
los siguientes:
XML
HTTP
SOAP
WSDL
UDDI
Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita
utilizar estos estándares para ser "orientado a servicios" pero es altamente
recomendable su uso.
En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros
participantes en la red como servicios independientes a los que tienen acceso de un
modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de
Servicios Web (empleando SOAP y WSDL) en su implementación, no obstante se puede
implementar SOA utilizando cualquier tecnología basada en servicios.
2.5 Lenguajes de alto nivel [editar]
Los lenguajes de alto nivel como BPEL o WS-coordinación llevan el concepto de servicio
un paso adelante al proporcionar métodos de definición y soporte para flujos de
trabajo y procesos de negocio.

2.6 Diferencias con otras arquitecturas [editar]
Al contrario de las arquitecturas orientado a objetos, las SOAs están formadas por
servicios de aplicación débilmente acoplados y altamente interoperables. Para
comunicarse entre sí, estos servicios se basan en una definición formal independiente
de la plataforma subyacente y del lenguaje de programación (p.ej., WSDL). La
definición de la interfaz encapsula (oculta) las particularidades de una implementación,
lo que la hace independiente del fabricante, del lenguaje de programación o de la
tecnología de desarrollo (como Plataforma Java o Microsoft.NET). Con esta
arquitectura, se pretende que los componentes software desarrollados sean muy
reusables, ya que la interfaz se define siguiendo un estándar; así, un servicio C Sharp
podría ser usado por una aplicación Java.
2.7 Beneficios [editar]
Los beneficios que puede obtener una organización que adopte SOA son:
Mejora en los tiempos de realización de cambios en procesos.

Facilidad para evolucionar a modelos de negocios basados en tercerización.
Facilidad para abordar modelos de negocios basados en colaboración con otros
entes (socios, proveedores).
Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el
proceso de negocio
Facilidad para la integración de tecnologías disímiles

3 http://www.service-architecture.com/web-
services/articles/service-
oriented_architecture_soa_definition.html
A service-oriented architecture is essentially a collection of services. These services

communicate with each other. The communication can involve 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.
Service-oriented architectures are not a new thing. The first service-oriented

architecture for many people in the past was with the use DCOM or Object Request
Brokers (ORBs) based on the CORBA specification. For more on DCOM and CORBA, see
Prior service-oriented architectures (new window).
3.1 Services
If a service-oriented architecture is to be effective, we need a clear understanding of

the term service. A service is a function that is well-defined, self-contained, and does
not depend on the context or state of other services. See Service (new window).
3.2 Connections
The technology of Web services (new window) is the most likely connection technology of
service-oriented architectures. Web services essentially use XML (new window) to create a
robust connection.
The following figure illustrates a basic service-oriented architecture. It shows a service

consumer at the right sending a service request message to a service provider at the
left. The service provider returns a response message to the service consumer. The
request and subsequent response connections are defined in some way that is
understandable to both the service consumer and service provider. How those
connections are defined is explained in Web Services explained (new window). A service
provider can also be a service consumer.

4 http://webservices.xml.com/pub/a/ws/2003/09/30/soa
.html
"Things should be made as simple as possible, but no simpler." -- Albert Einstein
4.1.1 Introduction
Einstein made that famous statement many decades ago, and it's still relevant today
for building superior software systems. Unfortunately, as anyone who has been in the
IT industry for long can point out, far too many software systems have failed Einstein's
test. Some are made too simple to carry out the duties they are supposed to perform.
Others are made too complex, and the costs of building and maintaining them have
rocketed, not to mention the nearly impossible tasks of integrating different systems
together. It seems that reaching the right level of simplicity is more like a dream than
reality. Where have we gone wrong?
4.1.2 Loose Coupling

entials
cations with XML-RPC, SOAP, UDDI & WSDL
ari Search this book on Safari:
nts only
We don't have to look far to find the problems. As we build more and more software
systems, we see similar situations and patterns appearing. Naturally, we want to reuse
the functionality of existing systems rather than building them from scratch. A real
dependency is a state of affairs in which one system depends on the functionality
provided by another. If the world only contained real dependencies, Einstein's test
would have been satisfied long time ago. The problem is that we also create artificial
dependencies along with real dependencies.
If you travel overseas on business, you know that you must bring power adapters along
with you or your life will be miserable. The real dependency is that you need power;
the artificial dependency is that your plug must fit into the local outlet. Looking at all
the varying sizes and shapes of those plugs from different countries, you would notice
that some of them are small and compact while many others are big and bulky.
The lesson here is that we cannot remove artificial dependencies, but we can reduce
them. If the artificial dependencies among systems have been reduced, ideally, to their
minimum, we have achieved loose coupling. In that sense, Einstein was just talking
about was loose coupling. We might rework his famous principle thus: "Artificial

dependencies should be reduced to the minimum but real dependencies should not be
altered."
4.1.3 SOA Defined and Explained
Now we are able to define a Service Oriented Architecture (SOA). SOA is an

architectural style whose goal is to achieve loose coupling among interacting software
agents. A service is a unit of work done by a service provider to achieve desired end
results for a service consumer. Both provider and consumer are roles played by
software agents on behalf of their owners.
This sounds a bit too abstract, but SOA is actually everywhere. Let's look at an example
of SOA which is likely to be found in your living room. Take a CD for instance. If you
want to play it, you put your CD into a CD player and the player plays it for you. The CD
player offers a CD playing service. Which is nice because you can replace one CD player
with another. You can play the same CD on a portable player or on your expensive
stereo. They both offer the same CD playing service, but the quality of service is
different.
The idea of SOA departs significantly from that of object oriented programming, which
strongly suggests that you should bind data and its processing together. So, in object
oriented programming style, every CD would come with its own player and they are
not supposed to be separated. This sounds odd, but it's the way we have built many
software systems.
The results of a service are usually the change of state for the consumer but can also
be a change of state for the provider or for both. After listening to the music played by
your CD player, your mood has changed, say, from "depressed" to "happy". If you want
an example that involves the change of states for both, dining out in a restaurant is a
good one.
The reason that we want someone else to do the work for us is that they are experts.
Consuming a service is usually cheaper and more effective than doing the work
ourselves. Most of us are smart enough to realize that we are not smart enough to be
expert in everything. The same rule applies to building software systems. We call it
"separation of concerns", and it is regarded as a principle of software engineering.
How does SOA achieve loose coupling among interacting software agents? It does so
by employing two architectural constraints:
1. A small set of simple and ubiquitous interfaces to all participating software

agents. Only generic semantics are encoded at the interfaces. The interfaces
should be universally available for all providers and consumers.
2. Descriptive messages constrained by an extensible schema delivered through
the interfaces. No, or only minimal, system behavior is prescribed by messages.

A schema limits the vocabulary and structure of messages. An extensible
schema allows new versions of services to be introduced without breaking
existing services.
As illustrated in the power adapter example, interfacing is fundamentally important. If

interfaces do not work, systems do not work. Interfacing is also expensive and error-
prone for distributed applications. An interface needs to prescribe system behavior,
and this is very difficult to implement correctly across different platforms and
languages. Remote interfaces are also the slowest part of most distributed
applications. Instead of building new interfaces for each application, it makes sense to
reuse a few generic ones for all applications.
Since we have only a few generic interfaces available, we must express application-
specific semantics in messages. We can send any kind of message over our interfaces,
but there are a few rules to follow before we can say that an architecture is service
oriented.
First, the messages must be descriptive, rather than instructive, because the service
provider is responsible for solving the problem. This is like going to a restaurant: you
tell your waiter what you would like to order and your preferences but you don't tell
their cook how to cook your dish step by step.
Second, service providers will be unable to understand your request if your messages
are not written in a format, structure, and vocabulary that is understood by all parties.
Limiting the vocabulary and structure of messages is a necessity for any efficient
communication. The more restricted a message is, the easier it is to understand the
message, although it comes at the expense of reduced extensibility.
Third, extensibility is vitally important. It is not difficult to understand why. The world
is an ever-changing place and so is any environment in which a software system lives.
Those changes demand corresponding changes in the software system, service
consumers, providers, and the messages they exchange. If messages are not
extensible, consumers and providers will be locked into one particular version of a
service. Despite the importance of extensibility, it has been traditionally overlooked. At
best, it was regarded simply as a good practice rather than something fundamental.
Restriction and extensibility are deeply entwined. You need both, and increasing one
comes at the expense of reducing the other. The trick is to have a right balance.
Fourth, an SOA must have a mechanism that enables a consumer to discover a service
provider under the context of a service sought by the consumer. The mechanism can
be really flexible, and it does not have to be a centralized registry.

4.1.4 Additional Constraints
There are a number of additional constraints one can apply on SOA in order to improve
its scalability, performance and, reliability.
4.1.4.1 Stateless Service
Each message that a consumer sends to a provider must contain all necessary
information for the provider to process it. This constraint makes a service provider
more scalable because the provider does not have to store state information between
requests. This is effectively "service in mass production" since each request can be
treated as generic. It is also claimed that this constraint improves visibility because any
monitoring software can inspect one single request and figure out its intention. There
are no intermediate states to worry about, so recovery from partial failure is also
relatively easy. This makes a service more reliable.
4.1.4.2 Stateful Service
Stateful service is difficult to avoid in a number of situations. One situation is to

establish a session between a consumer and a provider. A session is typically
established for efficiency reasons. For example, sending a security certificate with each
request is a serious burden for both any consumer and provider. It is much quicker to
replace the certificate with a token shared just between the consumer and provider.
Another situation is to provide customized service.
Stateful services require both the consumer and the provider to share the same
consumer-specific context, which is either included in or referenced by messages
exchanged between the provider and the consumer. The drawback of this constraint is
that it may reduce the overall scalability of the service provider because it may need to
remember the shared context for each consumer. It also increases the coupling
between a service provider and a consumer and makes switching service providers
more difficult.
4.1.4.3 Idempotent Request
Duplicate requests received by a software agent have the same effects as a unique
request. This constraint allows providers and consumers to improve the overall service
reliability by simply repeating the request if faults are encountered.

4.1.5 Deriving Web Services from SOA
Everyone knows roughly what a "web service" is, but there is no universally accepted
definition. The definition of web service has always been under hot debate within the
W3C Web Services Architecture Working Group. Despite the difficulty of defining web
services, it is generally accepted that a web service is a SOA with at least the following
additional constraints:
1. Interfaces must be based on Internet protocols such as HTTP, FTP, and SMTP.
2. Except for binary data attachment, messages must be in XML.
There are two main styles of Web services: SOAP web services and REST web services.
4.1.5.1 SOAP Web services
A SOAP web service introduces the following constraints:
1. Except for binary data attachment, messages must be carried by SOAP.

2. The description of a service must be in WSDL.
A SOAP web service is the most common and marketed form of web service in the
industry. Some people simply collapse "web service" into SOAP and WSDL services.
SOAP provides "a message construct that can be exchanged over a variety of
underlying protocols" according to the SOAP 1.2 Primer. In other words, SOAP acts like
an envelope that carries its contents. One advantage of SOAP is that it allows rich
message exchange patterns ranging from traditional request-and-response to
broadcasting and sophisticated message correlations. There are two flavors of SOAP
web services, SOAP RPC and document-centric SOAP web service. SOAP RPC web
services are not SOA; document-centric SOAP web services are SOA.
4.1.5.2 SOAP RPC Web Services
A SOAP RPC web service breaks the second constraint required by an SOA. A SOAP RPC
Web service encodes RPC (remote procedure calls) in SOAP messages. In other words,
SOAP RPC "tunnels" new application-specific RPC interfaces though an underlying
generic interface. Effectively, it prescribes both system behaviors and application
semantics. Because system behaviors are very difficult to prescribe in a distributed
environment, applications created with SOAP RPC are not interoperable by nature.
Many real life implementations have confirmed this.
Faced with this difficulty, both WS-I basic profile and SOAP 1.2 have made the support
of RPC optional. RPC also tends to be instructive rather than descriptive, which is
against the spirit of SOA. Ironically, SOAP was originally designed just for RPC. It won't
be long before someone claims that "SOAP" actually stands for "SOA Protocol".

4.1.5.3 REST Web Services
The term REST was first introduced by Roy Fielding to describe the web architecture. A
REST web service is an SOA based on the concept of "resource". A resource is anything
that has a URI. A resource may have zero or more representations. Usually, people say
that a resource does not exist if no representation is available for that resource. A REST
web service requires the following additional constraints:
1. Interfaces are limited to HTTP. The following semantics are defined:

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

5 http://tecnologia.infobaeprofesional.com/notas/46399
-Que-es-SOA-la-arquitectura-orientada-a-
servicios.html?cookie
5.1 ¿Qué es SOA, la arquitectura orientada a servicios?
D. Marsili, de Sybase, explica los alcances de esta tendencia cuya adopción crece en las
áreas de tecnología de la información de las grandes empresas
La urgencia de datos, la exactitud y la seguridad a partir de un final de un proceso de

negocio al otro son ahora un mandato de negocio. Las organizaciones que pueden
hacer esto tienen una distintiva ventaja competitiva.
Pero la integración por la integración no es el objetivo exclusivo. El objetivo final de

contar con un sistema unificado, significa para las compañías estar preparadas para
cambiar sus focos y recursos desde el mantenimiento de las aplicaciones separadas al
desarrollo de procesos de negocios de punta a punta basados en el servicio al cliente.
Asimismo, la flexibilidad de un sistema unificado hace esto posible para cambiar

aquellos procesos en una respuesta rápida a los cambios en las necesidades de los
negocios.
La arquitectura orientada a servicios (SOA) no se trata de software o de un lenguaje

de programación, SOA es un marco de trabajo conceptual que permite a las
organizaciones unir los objetivos de negocio con la infraestructura de TI integrando los
datos y la lógica de negocio de sus sistemas separados.
Desarrollada a finales de los ´90, SOA establece un marco de trabajo para servicios de
red – o tareas comunes de negocios – para identificar el uno al otro y comunicarlo.
La necesidad de tal marco se deriva de la evolución del software de negocio. En los

comienzos, los desarrollos de aplicaciones de negocio se concentraban en necesidades
específicas: contabilidad, compras, nómina de sueldos, transporte. Cada aplicación fue
desarrollada sin consideración de otros sistemas en la empresa y como comunicarse
con ellos. Porque las aplicaciones eran auto suficientes, la información común a toda la

empresa (como por ejemplo: la dirección del cliente) y funciones específicas de
negocios (como por ejemplo: buscar un nombre) aparecían en todas partes y requerían
un código complejo para, todos o muchos de los sistemas independientes.
Por consiguiente, los diversos sistemas de TI de la mayoría de las empresas hoy no

pueden acceder o procesar los datos desde el uno al otro. Un simple proceso de
negocio (como una venta para un pedido a un depósito enviado a una cuenta por
cobrar) que tomaría segundos si los sistemas se podrían comunicar, ahora puede
tomar semanas.
¿Qué puede hacer una empresa? Debería tener inversiones masivas en hardware,
software y perfiles de individuos involucrados en la ejecución de cada una de las
aplicaciones separadas? Con SOA, una empresa puede mantener sus inversiones en los
sistemas legacy y la gente necesaria para mantenerlos. Esto evita continuos y costosos
proyectos "de integración", como las mejoras a cualquier aplicación son transparentes
a todas las otras. La información de negocio es siempre "hasta el último minuto",
permitiendo mejores decisiones de negocio y mejorar las relaciones entre clientes y
partners.
A menudo, SOA es una solución prometedora para los problemas de integración. El

desafío es cómo llegar ahí.
Cómo crear un ambiente SOA
El desarrollo de un ambiente SOA involucra un número de pasos. El primer paso es

asegurar que todo el software nuevo que se instale sea compatible con SOA. El
segundo paso es identificar las funciones dentro de los sistemas legacy que desean
integrar y publicarlas como servicios. Por supuesto, esto no es tan fácil como suena. El
desarrollo de estos servicios puede requerir de perfiles que no existen en la empresa. Y
las herramientas necesarias para examinar los desarrollos y las etapas de despliegue
pueden venir de diferentes proveedores, cada uno con su propia instalación,
entrenamiento y temas de comunicación.
El Desarrollo de Aplicaciones Orientadas a Servicios (SODA) está diseñado para vencer

muchos de los problemas de lenguajes de software inherentes en los sistemas legacy.
SODA permite reutilizar aplicaciones existentes y proveer un camino para construir
nuevas, basadas en estándares, con interfases flexibles.
Esta adopción habilita un alto nivel de abstracción tecnológica. Es decir, SODA

encapsula y abstrae tecnologías tales como bases de datos, J2EE, .NET y CORBA de
modo que los desarrolladores no afronten la complejidad técnica de la interacción con
aplicaciones heterogéneas y sistemas de infraestructura. SODA así reduce
significativamente el esfuerzo requerido para traducir nuevos desafíos de negocios
dentro de aplicaciones funcionales

6 http://www.mastermagazine.info/articulo/3391.php
Conceptos básicos de la Arquitectura Orientada a Servicios

De acuerdo a analistas de la industria, los conceptos básicos de la Arquitectura
Orientada a Servicios (SOA) se establecieron desde hace 20 años. Por tanto, ¿qué
ofrece de nuevo?, ¿por qué esta tecnología tiene tanto éxito mientras otras fallan?
Durante esta serie de cinco capítulos, BEA Systems, líder mundial en infraestructura de
aplicaciones y pionero del SOA, responderá todo lo que usted quiere saber sobre ésta,
en apoyo a la gira mundial del dev2dev days 2004 en 23 ciudades del mundo,
incluyendo México.
¿Cuáles son los elementos del SOA más importantes para su éxito?
Como primer punto se encuentra la flexibilidad. SOA es la primera arquitectura de
Tecnologías de Información (TI) que asume lo que los negocios han sabido desde hace
mucho tiempo. Se trata esencialmente de un set de servicios sueltos, donde cada uno
es relativamente económico para construirlo o reemplazarlo si es necesario. Al ser
independientes, el poder unirlos permite a SOA adaptar cambios, cuestión imposible
para arquitecturas tradicionales.
En la Arquitectura Orientada a Servicios, se puede reemplazar un servicio sin tener que
preocuparse por la tecnología fundamental; la interfase es lo que importa, y está
definida en un estándar universal en servicios Web y XML. Esto es flexibilidad a través
de la interoperabilidad. También es la habilidad de asegurar los activos existentes,
aplicaciones y bases de datos legales y hacerlos parte de las soluciones empresariales
extendiéndolos al SOA en vez de reemplazarlos. El resultado en la red es la habilidad
de evolucionar rápida y eficientemente, en otras palabras, adaptarse “orgánicamente”
de acuerdo a la demanda del negocio. Esto es realmente nuevo.
En segundo lugar está la relevancia para el negocio. SOA es TI expresada a un nivel que
tiene un significado importante para la colaboración del negocio y profesionales del
área. Sus servicios actuales pueden coordinar unidades de trabajo muy cercanas a las
actividades del negocio; piense, por ejemplo, en un servicio llamado “Actualización de
órdenes de trabajo”. Éstos son inmediatamente relevantes para los analistas de la
empresa que participan en la creación y definición de nuevos procesos permitiendo el
“Servicio Dirigido Empresarial”.
Desde que los servicios web sustituyen la mayoría de las tecnologías fundamentales,
muy poca tecnología de habla es requerida. Los negocios y las TI se enfocan en la
lógica del negocio y la comunicación; finalmente comparten el lenguaje de servicios.
Esto también es relativamente nuevo y tendrá implicaciones en la entrega de servicios
TI.
¿Cuáles son las principales barreras a vencer para obtener el éxito de SOA?
SOA es un nuevo horizonte para las TI. Como cualquier gran cambio, las principales
barreras son organizacionales, no técnicas. A continuación ejemplificaremos algunas:
· Administración: Servicios compartidos es lo principal para utilizar SOA. La habilidad
para ensamblar rápidamente aplicaciones o procesos está basada en la disponibilidad

de algunos servicios que pueden ser compartidos. Hacer esto, por definición, requiere
administración.
· Desarrollo Cultural: Al utilizar SOA se requiere un cambio significativo en el estilo de
programar. Muchos desarrolladores utilizan equipos diferentes para resolver
problemas de manera independiente para cada aplicación. En SOA necesitarán escribir
aplicaciones para ser re-utilizadas en mente, usando códigos existentes, a los cuales se
podrá tener acceso constantemente.
¿Cómo se distingue actualmente SOA de anteriores estándares de integración y

conectividad tales como CORBA?
CORBA era mucho más ambicioso, tecnológicamente hablando, que SOA, y requería
una tremenda habilidad de conocimientos en su implementación. Ésta es rara de
encontrar, lo cual contribuyó a no entender el significado del estándar. SOA, en
contaste, es sencillo y está basado en estándares universales, lo cual asegura que las
habilidades para construir aplicaciones sean muy accesibles.
En la Arquitectura Orientada a Servicios, la distribución de los beneficios permite un
desarrollo óptimo de funciones como la “Actualización de órdenes de trabajo”. Con
CORBA, la distribución de los beneficios eran aplicaciones con diferentes propiedades y
métodos. Con SOA habrá menor control y poder, pero es más fácil de manejar.
Técnicamente no será muy poderoso pero es muy inteligente en el rol de las
organizaciones y personas que buscan el éxito en las TI.
¿Qué rol juega Java en el éxito potencial del SOA?

Java es muy importante para un estándar de servicios. Las habilidades y herramientas
que proporciona su comunidad garantiza calidad para construir en SOA. Así es como
mutuamente contribuyen al éxito, ya que Java es una manera más para implementar
servicios.

7 http://arquitecturaorientadaaservicios.blogspot.com/2
006/06/soa-y-los-servicios-web-i.html
7.1.1 SOA y los Servicios Web (I)
En la actualidad el concepto de SOA ha resurgido, gracias al auge y madurez de una

nueva tecnología: los Servicios Web.
Los Servicios Web se han convertido en el estandarte de SOA, ya que esta tecnología
posee un conjunto de características que permiten cubrir todos los principios de la
orientación a servicios, no como otras posibles tecnologías de implementación como
colas de mensajes o CORBA.
Centrándonos en los Servicios Web, podemos decir que con ellos se pueden generar
dos tipos de Arquitecturas Orientadas a Servicios:
Arquitectura Orientada a Servicios Tradicional.

Arquitectura Orientada a Servicios de segunda generación.
En el presente artículo describiré la primera de ellas.
La SOA Tradicional es aquella que utiliza los principios y tecnologías básicos de los
Servicios Web. Esto significa utilizar SOAP como lenguaje de intercambio, WSDL como
lenguaje para la descripción de los servicios y UDDI para la publicación o registro de los
mismos. En el dibujo que se muestra a continuación, se puede ver la estructura básica
de funcionamiento de una SOA tradicional.
En el gráfico anterior, se puede observar la existencia de tres roles claramente

diferenciados:
Cliente del servicio: Es el que solicita la ejecución del servicio web, y por lo
tanto el que lo consume.
Proveedor del servicio: Es el encargado de implementar el servicio web y
ofrecerlo a los clientes.

Registro del servicio: Es un repositorio donde se almacenan las descripciones
de los servicios, para que así los clientes puedan buscar el servicio web que
mejor se adapte a sus necesidades.
La secuencia de ejecución es la siguiente:
1. El proveedor del servicio da de alta el servicio web en el registro. Para realizar esto,
el proveedor almacena en el registro el documento de descripción de este.
2. El solicitante del servicio busca en el registro un servicio web que pueda adaptarse a
sus necesidades.
3. Una vez seleccionado el servicio, el solicitante lo invoca mediante el envío de un

mensaje SOAP, en el cual se indica la acción a realizar y los datos de entrada.
4. El servicio web recibe la petición y ejecuta la funcionalidad. Para finalizar envía un

mensaje SOAP al solicitante con los resultados obtenidos.
Por lo tanto, una SOA tradicional estará compuesta por un conjunto de servicios que
reciben y envían mensajes SOAP en base a una descripción WSDL. Este tipo de
arquitecturas hoy en día es muy utilizado, pero no es el más óptimo debido a que no
porpociona una serie de características esenciales a la hora de crear una Arquitectura
profesional. Estas características son:
Seguridad
Transaccionabilidad
Garantía de entrega
Orquestación
Coreografía
Direccionamiento
etc...
Estas características las ofrecen las SOA de segunda generación, que serán el tema
central de otro artículo.
Este artículo se centra en el segundo tipo de Arquitecturas Orientadas a Servicios, que

yo he denominado SOA de segunda generación.
Es el tipo utilizado actualmente, porque está basado en el SOA tradicional, añadiendo

lo necesario para cubrir sus carencias. Es decir, proporciona los elementos necesarios
para cumplir con todos los principios de la orientación a objetos.
El esquema básico de una SOA de segunda generación es el mostrado en el siguiente

gráfico:

Como se puede observar, una SOA de segunda generación está formada por un
conjunto de Funciones y por la Calidad del Servicio.
La Funciones están formadas por:
Transporte: Mecanismo utilizado para trasladar las peticiones desde el cliente,

hasta el proveedor del servicio, y viceversa.
Protocolo de comunicación: Es el sistema de comunicación entre el cliente y el
proveedor de servicios.
Descripción del servicio: Es un esquema utilizado para describir qué servicio es,
como se le puede invocar, y cuales son los datos necesarios para realizar su
invocación.
Servicio: Es la implementación del servicio.
Proceso de negocio: Es una colección de servicios, invocados en una
determinada secuencia, con un conjunto particular de reglas para satisfaces un
requisito de negocio.
Registro de servicios: Es un repositorio de servicios y datos, usado por los
proveedores de servicio y publicar los servicios, y para los clientes, donde
buscarlos.
La calidad del servicio por:
Política: Son un conjunto de reglas bajo las cuales, un proveedor de servicio

hace que el servicio esté disponible para los clientes (WS-Policy).
Seguridad: Son un conjunto de reglas que podrían ser aplicadas en la
identificación, autorización y control de acceso a los servicios, por parte del
cliente (WS-Security).
Transacción: Conjunto de atributos que podrían ser aplicados sobre un grupo
de servicios para devolver un conjunto de datos consistentes (WS-Transaction,
WS-Coordination).
Gestión: Conjunto de atributos que podrían ser aplicados para gestionar los
servicios proporcionados (WS-Manageability).

Es decir, las SOA de segunda generación se basan en ampliar su funcionalidad
mediante el uso de los estándares WS, que proporcionan funcionalidades como
gestión de transacciones, seguridad, etc..

006/05/elementos-esenciales-de-una.html
8.1.1 Elementos esenciales de una Arquitectura Orientada a

Servicios
En las Arquitecturas Orientadas a Servicios, el elemento básico es el servicio. Pero

únicamente con este concepto, no podríamos diseñar una arquitectura SOA.
Cuatro son los elementos esenciales necesarios para la construcción de una

Arquitectura Orientada a Servicios:
1. Operación: Es la unidad de trabajo o procesamiento en una arquitectura SOA.

2. Servicio: Es un contenedor de lógica. Estará compuesto por un conjunto de
operaciones, las cuales las ofrecerá a sus usuarios.
3. Mensaje: Para poder ejecutar una determinada operación, es necesario un
conjunto de datos de entrada. A su vez, una vez ejecutada la operación, esta
devolverá un resultado. Los mensajes son los encargados de encapsular esos
datos de entrada y de salida.
4. Proceso de negocio: Son un conjunto de operaciones ejecutadas en una
determinada secuencia (intercambiando mensajes entre ellas) con el objetivo
de realizar una determinada tarea.
Por lo tanto, una aplicación SOA estará formada por un conjunto de procesos de
negocio. A su vez esos procesos de negocio estarán compuestos por aquellos que
servicios que proporcionan las operaciones que se necesitan ejecutar para que el

proceso de negocio llegue a buen término. Por último para ejecutar esas operaciones
es necesario el envío de los datos necesarios mediante los correspondientes mensajes.

006/05/12-pasos-para-migrar-un-entorno-soa.html
9.1.1 12 pasos para migrar a un entorno SOA
En la gran mayoría de los casos, el desarrollo de una Arquitectura Orientada a

Servicios, suele ser la solución adoptada a la horas de migrar aplicaciones antiguas a
nuevos entornos.
Esto se debe a que una arquitectura SOA, aporta ventajas como escalabilidad,
flexibilidad, reutilización, etc... (ya sabeis que opino yo de esto. Es verdad siempre y
cuando se haya destinado un gran esfuerzo [tiempo+ dinero] a desarrollar esa
arquitectura SOA).
Para realizar una migración, es necesario diseñar un plan de ejecución. Pues bien,
David S. Linthicum, gurú en el campo de SOA, ha definido en este documento los 12
pasos que deberían seguirse para realizar una migración con plenas garantías de éxito.
Es un documento muy recomendable, puesto que nos puede proporcionar una visión
global de la complejidad a la hora de migrar a SOA. Ahora bien, no penseis que el
documento va a solucionar vuestros problemas y dudas trascendentales, puesto que
en él se indican cuales son los pasos en un plan de migración, pero no se centra en las
técnicas y herramientas para acometer ese plan.

10 http://arquitecturaorientadaaservicios.blogspot.com/
2006/06/principios-de-la-orientacin-servicios.html
Un problema con el que nos podemos encontrar a la hora de construir una aplicación
SOA es si la aplicación construida realmente es una aplicación "SOA Compliant". Para
comprobar si una aplicación lo es, la mejor forma de hacerlo es chequeando que la
aplicación cumpla con los Principios de la Orientación a Servicios.
No existe una definición estándar de cuales son los Principios de la Orientación a

Servicios, por lo tanto, lo único que se puede proporcionar es un conjunto de
Principios que estén muy asociados con la Orientación a Servicios. Estos Principios
según Thomas Erl son:
Los Servicios deben ser reusables: Todo servicio debe ser diseñado y
construido pensando en su reutilización dentro de la misma aplicación, dentro
del dominio de aplicaciones de la empresa o incluso dentro del dominio público
para su uso masivo.
Los Servicios deben proporcionar un contrato formal: Todo servicio

desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del
servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada
de cada una de las funcionalidades y los datos de salida. De esta manera, todo
consumidor del servicio, accederá a este mediante el contrato, logrando así la
indepencia entre el consumidor y la implementación del propio servicio. En el
caso de los Servicios Web, esto se logrará medienta la definición de interfaces
con WSDL.
Los Servicios deben tener bajo acoplamiento: Es decir, que los servicios tienen
que ser independientes los unos de los otros. Para lograr ese bajo
acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un
servicio, se accederá a él a través del contrato, logrando así la independencia
entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo
acoplamiento, entonces los servicios podrán ser totalmente reutilizables.
Los Servicios deben permitir la composición: Todo servicio debe ser construido
de tal manera que pueda ser utilizado para construir servicios genéricos de más
alto nivel, el cual estará compuesto de servicios de más bajo nivel. En el caso de
los Servicios Web, esto se logrará mediante el uso de los protocolos para
orquestación (WS-BPEL) y coreografía (WS-CDL).
Los Servicios deben de ser autónomos: Todo Servicio debe tener su propio
entorno de ejecución. De esta manera el servicio es totalmente independiente
y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista
de la plataforma de ejecución.

Los Servicios no deben tener estado: Un servicio no debe guardar ningún tipo
de información. Esto es así porque una aplicación está formada por un conjunto
de servicios, lo que implica que si un servicio almacena algún tipo de
información, se pueden producir problemas de inconsistencia de datos. La
solución, es que un servicio sólo contenga lógica, y que toda información esté
almacenada en algún sistema de información sea del tipo que sea.
Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser
descubierto de alguna forma para que pueda ser utilizado, consiguiendo así
evitar la creación accidental de servicios que proporcionen las mismas
funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará
publicando los interfaces de los servicios en registros UDDI.
Cuando se desarrollan aplicaciones SOA es muy útil y necesario tener en cuenta

siempre estos principios, ya que nos van a dar las pautas necesarias para tomar ciertas
decisiones de diseño complejas.
Como se habrá podido observar, una característica muy importante de los Principios
de la Orientación a Servicios, es que todos ellos se inter-relacionan. El siguiente
gráfico muestra la inter-relación de los diferentes principios:
Como se puede observar en el gráfico, el objetivo de la Orientación a Servicios es

obtener software totalmente reutilizable a través de un conjunto de técnicas y
principios como los descritos anteriormente.

Service Oriented Architecture SOA v1.0

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Service Oriented Architecture SOA v1.0

Uploaded by

Copyright:

Available Formats

SERVICE ORIENTED

Service Oriented Architecture Página 2 de 48

In computing, service-oriented architecture (SOA) provides methods for systems

Service Oriented Architecture Página 3 de 48

1.2 [edit] Description

1.2.1 [edit] Overview

Service Oriented Architecture Página 4 de 48

Companies have long sought to integrate existing systems in order to implement

SOA offers one such prospective architecture. It unifies business processes by

Service Oriented Architecture (SOA) provides a design framework with a view to

Web services face significant challenges because of particular requirements. Applying

Service Oriented Architecture Página 5 de 48

1.2.2 [edit] Introduction

One can define a service-oriented architecture (SOA) as a group of services that

SOAs build applications out of software services. Services comprise intrinsically

Relative to typical practices of earlier attempts to promote software reuse via

A software developer or software engineer associates individual SOA objects by using

Service Oriented Architecture Página 6 de 48

As of 2008, increasing numbers of third-party software companies offer software

SOA as an architecture relies on service-orientation as its fundamental design

Service Oriented Architecture Página 7 de 48

Interoperability between different systems and programming languages

1.2.4 [edit] Principles

Reuse, granularity, modularity, composability, componentization, portability,

Service encapsulation – Many web services are consolidated to be used under

Service Oriented Architecture Página 8 de 48

The following references provide additional considerations for defining a SOA

SOA Reference Architecture provides a working design of an enterprise-wide

efficient use of system resources

1.2.5 [edit] Web services approach

Web services can implement a service-oriented architecture. Web services make

Service Oriented Architecture Página 9 de 48

1.2.6 [edit] SOA and Web service protocols

1.2.7 [edit] Other SOA concepts

Architectures can operate independently of specific technologies[3]. Designers can

Service Oriented Architecture Página 10 de 48

SOA Meta Model, The Linthicum Group, 2007

Service-Oriented Modeling Framework (SOMF) Version 2.0

Service Oriented Architecture Página 11 de 48

How can a SOA address interoperability and reusability challenges of computing

"Service-Oriented Modeling Framework (SOMF) Example".

Service Oriented Architecture Página 12 de 48

Open Group SOA Definition (SOA-Definition)[10]

1.2.9 [edit] Service contract

A service contract needs[citation needed] to have the following components:

Service Oriented Architecture Página 13 de 48

1.2.10 [edit] SOA and business architecture

Service Oriented Architecture Página 14 de 48

Within this area, IBM announced SOMA (service-oriented modeling and

1.2.11 [edit] SOA and network management architecture

Tools for managing SOA infrastructure include:

HP Management Software / Mercury SOA Manager

1.3 [edit] Discussion

1.3.1 [edit] Benefits

Service Oriented Architecture Página 15 de 48

Some[who?] have questioned whether SOA is just a revival of modular programming

SOA is an architectural and design discipline conceived to achieve the goals of

Service-Oriented Architecture (SOA) is an architectural approach (or style) for

A service comprises a stand-alone unit of functionality available only via a formally

Services generally adhere to the following principles of service-orientation:

A mature rollout of SOA effectively defines the API of the organization.

Implementation of services should be treated as separate projects from the larger

Service Oriented Architecture Página 16 de 48