Service Oriented Architecture (SOA)
Service Oriented Architecture (SOA) is an evolution of distributed computing and modular programming. SOAs
build applications out of software services. Services are relatively large, inherently unassociated units of
functionality, which have no calls to each other embedded in them. They typically implement functionalities most
humans would recognize as a service, such as filling out an online application for an account, viewing an online
bank statement, or placing an online book or airline ticket order. Instead of services embedding calls to each
other in their source code, protocols are defined which describe how one or more services can talk to each other.
This architecture then relies on a business process expert to link and sequence services, in a process known as
orchestration, to meet a new or existing business system requirement.
|
The goal of SOA then is to allow fairly large chunks of functionality to be strung together to form ad-hoc applications which are built almost entirely from existing software services. The larger the chunks the fewer the interface points required to implement any given set of functionality. This is at odds with very large chunks of functionality which are not granular enough to be easily reused. Since each interface brings with it some amount of processing overhead, there is a performance consideration in choosing the granularity of services. The great promise of SOA though, is that in this world, the marginal cost of creating the nth application is zero, as all of the software required already exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application.
Service-oriented architecture
A service-oriented architecture (SOA) is a collection of services that communicate with each other, for example, passing data from one service to another or coordinating an activity between one or more services.
Companies have long sought to integrate existing systems in order to implement information technology (IT) support for business processes that cover an entire business value chain. A variety of designs can be used to this end, ranging from rigid point-to-point electronic data interchange (EDI) interactions to Web auctions. By Internet-enabling EDI-based systems, companies can make their IT systems available to internal or external customers, but the interactions are not very flexible and are without a standardized architecture.
In order to better support the connection and sharing of software functionalities, there was a need for a flexible, standardized architecture. SOA is one such architecture which unifies business processes by structuring large applications as an ad-hoc collection of smaller modules called services. These applications can be used by different groups of people both inside and outside the company. The building block services can play one or more of three roles: service provider, service broker, or service requestor. See Web services approach to a service-oriented architecture to learn more about these roles.
Requirements for a SOA
In order to efficiently use a SOA, one must meet the following requirements:
? Interoperability between different systems and programming languages
The most important basis for a simple integration between applications on different platforms is a communication
protocol, which is available for most systems and programming languages.
? Clear and unambiguous description language
To use a service offered by a provider, it is not only necessary to be able to access the provider system,
but the syntax of the service interface must also be clearly defined in a platform-independent fashion.
? Retrieval of the service
To allow a convenient integration at design time or even system run time, a search mechanism is required to
retrieve suitable services. The services should be classified as computer-accessible, hierarchical or taxonomies
based on what the services in each category do and how they can be invoked.
Web services approach to a service-oriented architecture
Web services implement a service-oriented architecture. A major focus of Web services is to make functional
building blocks accessible over standard Internet protocols that are independent from platforms and programming
languages. These services can be new applications or just wrapped around existing legacy systems to make them
network-enabled. A service can rely on another service to achieve its goals.
Each SOA building block can play one or more of three roles:
? 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 they are free, how to exploit them for other value.
The provider also has to decide what category the service should be listed in for a given broker service and
what sort of trading partner agreements are required to use the service.
? Service broker
The service broker, also known as service registry, is responsible for making the Web service interface and
implementation access information available to any potential service requestor. The implementer of the broker
decides about the scope of the broker. Public brokers are available through the Internet, while private brokers
are only accessible to a limited audience, for example, users of a company intranet. Furthermore, the amount of
the offered information has to be decided. Some brokers specialize in many listings. Others offer high levels
of trust in the listed services. Some cover a broad landscape of services and others focus within an industry.
There are also brokers that catalog other brokers. Depending on the business model, brokers can attempt to
maximize look-up requests, number of listings or accuracy of the listings. The Universal Description Discovery
and Integration (UDDI) specification defines a way to publish and discover information about Web services.
? Service requestor
The service requestor 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.
Other SOA Concepts
SOA may be implemented using a wide range of technologies, including SOAP, RPC, DCOM, CORBA, Web Services or
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 the service having foreknowledge of the calling application, and without the
application having or needing knowledge of how the service actually performs its tasks.
SOA can also be regarded as a style of information systems architecture that enables the creation of
applications that are built by combining loosely coupled and interoperable services. These services inter-operate
based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and
programming language. The interface definition hides the implementation of the language-specific service.
SOA-based systems can therefore be independent of development technologies and platforms
(such as Java, .NET etc). Services written in C# running on .NET platforms and services written in Java running
on Java EE platforms, for example, can both be consumed by a common composite application (or client).
Applications running on either platform can also consume services running on the other as Web services, which
facilitates reuse. Many COBOL legacy systems can also be wrapped by a managed environment and presented as a
software service. This has allowed the useful life of many core legacy systems to be extended indefinitely no
matter what language they were originally written in.
SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not
specify or provide a methodology or framework for documenting capabilities or services.
High-level languages such as BPEL and specifications such as WS-CDL and WS-Coordination extend the service
concept by providing a method of defining and supporting orchestration of fine grained services into more
coarse-grained business services, which in turn can be incorporated into workflows and business processes
implemented in composite applications or portals.
The use of Service component architecture (SCA) to implement SOA is a current area of research.
Why SOA?
Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing
market conditions. This style of architecture promotes reuse at the macro service level rather than micro
objects level. It can also simplify interconnection to - and usage of - existing IT (legacy) assets.
SOA Practitioners Guide: Why Services-Oriented Architecture? Provides a high-level summary on SOA.
In some respects, SOA can be considered an architectural evolution rather than a revolution and captures many of
the best practices of previous software architectures. In communications systems, for example, there has been
little development of solutions that use truly static bindings to talk to other equipment in the network. By
formally embracing a SOA approach, such systems are better positioned to stress the importance of well-defined,
highly inter-operable interfaces.
SOA principles
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA:
? Reuse, granularity, modularity, compatibility, componentization, and interoperability
? Compliance to standards (both common and industry-specific)
? Services identification and categorization, provisioning and delivery, and monitoring and tracking
The following specific architectural principles for design and service definition focus on specific themes that
influence the intrinsic behavior of a system and the style of its design:
? Service Encapsulation - A lot of existing web-services are consolidated to be used under the SOA Architecture.
Many a times, such services have not been 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 compatibility - 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
Benefits of SOA
1. Service-Oriented Architecture (SOA) as key to interoperability and flexibility requirements for its vision
of on demand business. SOA supports end-to-end integration across the enterprise and among business partners.
This provides a flexible business process model that allows customers to respond quickly to new customer
requirements, new business opportunities.
2. SOA can reduce the complexity of systems by using a common style of interaction that works with both new
and legacy code.
3. The binding from the service requester to the service provider should loosely couple the service. This means
that the service requester has no knowledge of the technical details of the provider?s implementation, such as
the programming language, deployment platform, and so forth. The service requester typically invokes operations
by way of messages -- a request message and the response -- rather than through the use of APIs or file formats.
4. Service Oriented Architecture distinguishes itself in that the consumer of certain application functionalities may
very well be another service or application. It is true that human users mostly prefer all functionality to be
aggregated together and also accessible through a single user interface. But a lot of other applications do not come
with this requirement. Thus, it is logical to have functionality organized around a set of services which may or may
not be self contained, yet even in the event that they are, can be somehow woven together in order to create a higher
level of services or functionality.
5. SOA allows an organization to effectively leverage existing assets rather than forcing them to create yet another
redundant silo for each business need. This, in turn, also makes IT more efficient, allowing for shorter cycle times
and quicker project delivery ? further helping IT align with the business.
Q: What is Service Oriented Architecture (SOA)?
A Service Oriented Architecture is essentially a collection of services. Service Oriented Architecture
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.
Q: What is SOA really and what can it do for you?
Service Oriented Architecture (SOA) is an evolution of distributed computing and modular programming. SOAs build
applications out of software services. Services are relatively large, inherently unassociated units of
functionality, which have no calls to each other embedded in them.
Q: How does SOA achieve loose coupling among interacting software agents?
It does so by employing two architectural constraints:
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.
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.
Q: What are the benefits of a SOA?
Service oriented architectures have several benefits. Three of the top ones include:
Higher ROIs on software creation: Services within SOAs are created in layers separate from their applications. This
means that, as businesses evolve, software services can be reused, adapted, or combined rather than having to be
created from scratch.
Support for multiple client types: Because SOAs are designed to interact with diverse systems, they provide support
for multiple client types. This means that a business can pick and choose the best products for an application
without having to worry about interoperability across existing services.
Better Maintainability: Because services are separated into a distinct code layer, software developers can more
easily find and fix any issues that arise.
Q: How does a SOA work?
Although a number of additional conditions can imposed to improve a SOA, there are two fundamental concepts that
every SOA requires: interfaces that are simple and ubiquitous to all software agents, and communication via
descriptive rather than instructive messages.
The reasoning behind these two concepts becomes clear when put into an example. Consider the case in which I ask
you to get me a book. Our interaction takes place at the surface, via our spoken words (in this case, a simple
and ubiquitous interface). Once I have communicated my message to you, I don't need to know what your thought
process is, whether you pick the book up yourself or have someone else get it; I am only concerned with the
overall result that the book ends up in my possession. Because the message was descriptive rather than
instructive, you can carry it out in any way that you decide. By following the two SOA principles, we achieved
the service result without having to coordinate every process defined below the surface interaction.
Q: What are some useful terms to know in reference to SOA?
Loose coupling: Loose coupling in a software context refers to the idea of dependencies; the more the
functionality of a piece of software depends on the functionality of another piece of software, the tighter
their coupling. Similarly, the less dependent they are upon each other, the more loosely coupled they are said
to be.
Descriptive message: The form that SOA messages take. Descriptive messages tell applications the result
that they would like to have happen, but not the process required to achieve that result. This allows for
interaction at a surface level without having to have compatible systems beneath that skin. Descriptive messages
contrast with instructive messages.
Instructive messages: Instructive messages don't function well in SOAs because they attempt to tell the
service provider how to execute a request. This introduces the requirements that message and provider speak the
same language fundamentally, not just at the surface interfaces.
|
