Jump to content

Service-oriented architecture: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Line 79: Line 79:
* [[Cordys]]: Business Collaboration Platform
* [[Cordys]]: Business Collaboration Platform
* [[Eclipse (software)|Eclipse]]: [http://www.eclipse.org]
* [[Eclipse (software)|Eclipse]]: [http://www.eclipse.org]
* [[Fiorano]]: [http://www.fiorano.com/products/fesb/fioranosoa.htm]
* [[Fiorano Software Inc.]]: [http://www.fiorano.com/products/fesb/fioranosoa.htm]
* [[Fujitsu]]: [http://www.fujitsu.com/global/services/software/interstage/products/soa/]
* [[Fujitsu]]: [http://www.fujitsu.com/global/services/software/interstage/products/soa/]
* [[Forum Systems]]: [http://www.forumsys.com/]
* [[Forum Systems]]: [http://www.forumsys.com/]

Revision as of 10:06, 17 January 2006

In computing, the term Service-Oriented Architecture (SOA) expresses a software architectural concept that defines the use of services to support the requirements of software users. In a 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. The OASIS SOA Reference Model Technical Committee is working on defining SOA independent of any specific technologies.

Unlike traditional point-to-point architectures, SOAs comprise loosely coupled, highly interoperable application services. These services interoperate based on a formal definition independent of 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 defined in a standards-compliant manner. So, for example, a C# (C Sharp) service could be used by a Java application.


SOA provides a methodology and framework for documenting enterprise capabilities and can support integration and consolidation activities.

High-level languages such as BPEL or WS-Coordination take the service concept one step further by providing a method of defining and supporting workflows and business processes.

SOA definitions

Term Definition / Comment
service (Ideally) a self-contained, stateless business function that accepts one or more requests and returns one or more responses through a well-defined, standard interface. Services can also perform discrete units of work such as editing and processing a transaction. Services should not depend on the state of other functions or processes. The technology used to provide the service, such as a programming language, does not form part of this definition.
orchestration Sequencing services and providing additional logic to process data. Does not include data presentation.
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.
discovery 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.

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. This work is currently mainly being led by the OASIS standards group, particularly the SOA Adoption Blueprints group. 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 there is already an SOA Methodology which has been contributed to the SOA Adoption Blueprints group. This approach to SOA takes a fundamentally structured approach to SOA, focusing on the Services and Architecture elements and leaving implementation to the more technically focused standards.

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.

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 of existing IT assets rather than more time consuming and costly reinvention.

The recently published book Service-Oriented Architecture Compass - Business Value, Planning and Enterprise Roadmap provides arguments supporting the justification of introducing SOA at an enterprise ISBN 0-13-187002-5

Products

SOA is not a product, although several vendors offer products which can form the basis of a SOA. Examples of such products include (alphabetical by vendor): A set of components which can be invoked, and whose interface descriptions can be published and discovered (W3C).

See also

Infosys

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.

Literature

  • Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah Service-Oriented Architecture Compass Pearson, Upper Saddle River 2006 ISBN 0-13-187002-5