SOA Introduction
Abstracted From Wikipedia, the free encyclopedia

 

In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, nodes on a network[1] make resources available to other participants in the network as independent services that the participants access in a standardized way. Most definitions of SOA identify the use of Web services (i.e., using SOAP or REST) in its implementation. However, one can implement SOA using any service-based technology.

Unlike traditional point-to-point architectures, SOAs comprise loosely coupled, highly interoperable services. These services interoperate based on a formal definition (or contract) which is independent from the underlying platform and programming language (e.g., WSDL). The interface definition encapsulates (hides) the vendor and language-specific implementation. A SOA is independent of development technology (such as Java and .NET). The software components become very reusable because the interface is standards-compliant and is independent from the underlying implementation of the service logic. So, for example, a C# (C Sharp) service could be used by a Java application and vice versa.

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-Coordination extend the service concept further by providing a method of defining and supporting orchestration of fine grained services into coarser grained business services, which in turn can be incorporated into workflows and business processes implemented in composite applications or portals.

Contents

[hide]

[edit]

SOA definitions

In March 2006 the OASIS group SOA Reference Model released its first public review draft. This defines the basic principles of SOA that apply at all levels of a service architecture, from business vision through to technical and infrastructure implementation. This is a good start in understanding SOA. The glossary contains a comprehensive definition of terms.

Term Definition / Comment
Service-Oriented Architecture A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
service The means by which the needs of a consumer are brought together with the capabilities of a provider
orchestration Sequencing services and providing additional logic to process data. Does not include data representation.
choreography Broadly, a choreography defines how a party interacts with other external parties, for example in terms of the order of message exchange, or the path of navigation through a service. The party, from whose perspective the choreography is viewed, may either be the client (which could be an orchestration), meaning the choreography defines the conversation with a service, or the deployed service itself, in which multiple clients may be involved.
stateless Not depending on any pre-existing condition. In a SOA, services should not depend on the condition of any other service. They receive all information needed to provide a response from the request. Given the statelessness of services, service consumers can sequence (orchestrate) them into numerous flows (sometimes referred to as pipelines) to perform application logic.
provider The function that performs a service in response to a request from a consumer.
consumer The function that consumes the result of a service supplied by a provider.
directory Service oriented architecture relies on the ability to identify services and their capabilities. Therefore, a SOA depends on a directory that describes the services available in its domain.
binding The relationship between a service provider and consumer is dynamic; it is established at runtime by a binding mechanism.
[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. Within this area, the first SOA method was announced in 2004 Service-oriented Modeling and Architecture (SOMA). Since then the work has moved towards greater standardisation, particularly within the OASIS standards group particularly the SOA Adoption Blueprints group, recently this has included the contribution of an open methodology for Service Architecture which focuses on the business service as part of the process. 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. One example of a Service-Oriented network management architecture is the recently published M.3060 Principles for the Management Of Next Generation Networks recommendation from the ITU-T.

[edit]

SOA design and development

The modeling and design methodology for SOA applications has become known by the terms service-oriented analysis and design and SODA. The SOA functions as much as a software development framework as it does as a delivery framework. In order for a SOA environment to operate successfully, software developers need to orient themselves to its mindset of creating common services which clients or middleware then orchestrate to implement processes. Development of systems using the SOA requires a commitment to this model in terms of planning, tools, and infrastructure.

When most people speak of a service-oriented architecture, they speak of a set of services residing on the Internet or an intranet using "Web services." A set of standards exists which generally feature in all discussions of Web services. These standards include the following:

Note, however, that a SOA does not necessarily need to use any or all of these standards to become "service-oriented."

In general, SOA is behind the scenes, not visible to the users. SOA is fronted by a client UI, and end users only see the Client UI. In other words, there is no SOA without clients using it. As such, SOA is an enabling technology, behind the scenes, waiting to be used. See Client/SOA for a discussion of one such architecture.

[edit]

Why SOA?

Enterprise architects believe that SOAs help businesses respond more quickly and cost-effectively to the changing market conditions they may face by promoting reuse and interconnection of existing IT assets rather than more time consuming and costly reinvention.

In some respects, SOA can be considered an evolution in architecture, not a revolution. It captures many of best practices or actual use of the architectures that came before it. To talk in terms of a service-oriented architecture provides a good framework from which to build the dynamic solutions required today. In communications systems, for example, there has been little deployment in recent years of solutions that use truly static bindings to talk to other equipment in the network, but by formally embracing a SOA approach, solutions are better positioned to stress the importance of well-defined, highly interoperable interfaces. This should greatly decrease integration costs and allow for much more dynamic solutions to be deployed.

[edit]

What are the challenges faced in SOA Adoption?

One obvious challenge faced is managing services metadata. 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. Many vendors are working on offerings to address this particular challenge with a sectorial point of view.

Another challenge is providing appropriate levels of security. Applications which consume services, particularly those external to company firewalls, are more visible to external parties than traditional monolithic proprietary applications. The flexibility and reach of SOA can compromise security; the WS-Security suite of specifications is being developed to provide appropriate security.

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.

[edit]

Products

SOA is not a product, although several vendors offer products which can form the basis of a SOA. See the list of SOA related products for an overview.

[edit]

See also

[edit]

Footnotes

  • ↑  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. See, for example, IBM System z9 for an alternative to distributed nodes.
[edit]

Literature

  • Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and Design, Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0.
  • Pulier, Eric; Hugh Taylor (2005). Understanding Enterprise SOA, Greenwich: Manning Publications. ISBN 1-93239-459-1.
  • 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.
  • 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.
  • 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.
[edit]

External links


Articles