service orentation documentation

1
1. SERVICE-ORIENTATION
Service-orientation is a design paradigm to build computer software in the form of
services. Like other design paradigms (e.g. object-orientation), service-orientation provides a
governing approach to automate business logic as distributed systems. What distinguishes
service-orientation is its set of design principles to ensure the manner in which it carries out the
separation of concerns in the software. A service-oriented architecture (SOA) is governed by
these principles. Applying service-orientation results in units of software partitioned into
operational capabilities, each designed to solve an individual concern. These units qualify as
services.
Service-orientation has received a lot of attention since 2005 due to the benefits it
promises. These include increased return on investment, organisational agility and
interoperability as well as a better alignment between business and IT. It builds heavily on earlier
design paradigms and enhances them with standardisation, loose coupling and business
involvement.

2
2. SERVICE-ORIENTED ARCHITECTURE
Service-oriented architecture (SOA) is a software design and software architecture
design pattern based on structured collections of discrete software modules, known as services
that collectively provide the complete functionality of a large software application. The purpose
of SOA is to allow easy cooperation of a large number of computers that are connected over a
network. Every computer can run an arbitrary number of programs - called services in this
context - that are built in a way that they can exchange information with any other service within
the reach of the network without human interaction and without the need to make changes to the
underlying program itself.
In a large network of computers SOA has the same role and duties as the traditional
operating system on a single computer. Consequently SOA is designed in analogy to traditional
multi-tasking operating systems like Windows, UNIX, zOS etc.
Figure 2.1: Layer interaction in service-oriented Architecture

3
3. TYPES OF SOA
Four common SOA types have emerged in order to improve physical design.
Documenting architecture types encourages services that are more standardized, interoperable
and composable. This also assists in understanding interdependencies among services.
This is the physical design of an individual service that encompasses all the resources
used by a service. This would normally include databases, software components, legacy systems,
identity stores, XML schemas and any backing stores, e.g. shared directories. It is also beneficial
to include any service agents employed by the service, as any change in these service agents
would affect the message processing capabilities of the service.
The (standardized service contract) design principle, keeps service contracts independent
from their implementation. The service contract needs to be documented to formalize the
required processing resources by the individual service capabilities. Although it is beneficial to
document details about the service architecture, the service abstraction design principle dictates
that any internal details about the service are invisible to its consumers so that they do not
develop any unstated couplings. The service architecture serves as a point of reference for
evolving the service or gauging the impact of any change in the service.

4
4. THE EVOLUTION OF SOA
Service Orientation (SO) is the natural evolution of current development models. The,
80s saw object-oriented models; then came the component-based development model in the 90s;
and now we have service orientation (SO). Service orientation retains the benefits of component-
based development (self-description, encapsulation, dynamic discovery and loading), but there is
a shift in paradigm from remotely invoking methods on objects, to one of passing messages
between services. Schemas describe not only the structure of messages, but also behavioral
contracts to define acceptable message exchange patterns and policies to define service
semantics. This promotes interoperability, and thus provides adaptability benefits, as messages
can be sent from one service to another without consideration of how the service handling those
messages has been implemented.
Figure 4.1: Simple SOAP-based communications between Web Services
Service orientation provides an evolutionary approach to building distributed software
that facilitates loosely coupled integration and resilience to change. With the advent of the WS-*
Web Services, architecture has made service-oriented software development feasible by virtue of
mainstream development tools support and broad industry interoperability. Although most
frequently implemented using industry standard Web services, service orientation is independent
of technology and its architectural patterns and can be used to connect with legacy systems as
well.

5
5. DIFFERENCE BETWEEN OO AND SO
It is quite difficult to think in terms of services. Though services are implemented with
the help of Object oriented languages, we should always remember some basic points while
designing the services.
Table 5.1: OO and SO
Object Orientation(OO) Service Orientation(SO)
Assume homogeneous platform and execution
environment
Assume heterogeneous platform and execution
environment
Share classes, not schemas Share schemas, not classes
Assume cheap, transparent communication Assume variable cost, explicit communication
Are linked: Object identity and lifetime
maintained by infrastructure
Are autonomous: Security and failure isolation
are a must
Typically require deployment of both client
and server in sync
Ease “continuous deployment” of client and
server separately
Are easy to talk about and become a natural
path for customers to follow
Builds on ideas from component software,
distributed objects, and MOM
Customers have 20+ years of experience and
great intuition about what “object oriented is”
Builds on ideas from component software,
distributed objects, and MOM

6
6. OTHER SOA CONCEPTS
Architectures can operate independently of specific technologies. Designers can
implement SOA using a wide range of technologies, including:
 SOAP, RPC
 REST
 DCOM
 CORBA
 Web services
 DDS
 Java RMI
 WCF (Microsoft's implementation of web services now forms a part of WCF)
 Apache Thrift
Implementations can use 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.
Many implementers of SOA have begun to adopt an evolution of SOA concepts into a
more advanced architecture called SOA 2.0.
Figure 6.1: Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama

7
7. MERITS AND DEMERITS OF SOA
Some enterprise architects believe that SOA can help businesses respond more quickly
and more cost-effectively to changing market conditions. 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.
With SOA, the idea is that an organization can look at a problem holistically. A business
has more overall control. Theoretically there would not be a mass of developers using whatever
tool sets might please them. But rather there would be a coding to a standard that is set within the
business.
They can also develop enterprise-wide SOA that encapsulates a business-oriented
infrastructure. SOA has also been illustrated as a highway system providing efficiency for car
drivers. The point being that if everyone had a car, but there was no highway anywhere, things
would be limited and disorganized, in any attempt to get anywhere quickly or efficiently. IBM
Vice President of Web Services Michael Liebow says that SOA "builds highways".
In some respects, SOA could be regarded 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 of solutions that use truly static
bindings to talk to other equipment in the network has taken place. By formally embracing a
SOA approach, such systems can position themselves to stress the importance of well-defined,
highly inter-operable interfaces.
Some have questioned whether SOA simply revives concepts like modular programming
(1970s), event-oriented design (1980s), or interface/component-based design (1990s). 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.

8
8. CONCLUSION
Service-orientation design principles have another role in that they collectively define
service orientation as a design paradigm. Ultimately, it is best to view design patterns as
providing support for the realization of design principles and their associated goals.
Services are unassociated, loosely coupled units of functionality that have no calls to
each other embedded in them. Each service implements one action, such as filling out an online
application for an account, or viewing an online bank statement, or placing an online booking or
airline ticket order. Rather than services embedding calls to each other in their source code, they
use defined protocols that describe how services pass and parse messages using description
metadata.

9
9. REFERENCES
1. Thomas Erl (2008)."SOA Principles of Service Design". Prentice Hall. ISBN 0-13-
234482-3.
2. Erl et al, (2009)."SOA Design Patterns". Prentice Hall. ISBN 0-13-613516-1.
3. Erl, Thomas. "What Is SOA? - Introduction".
4. Erl, Thomas. About the Principles. Serviceorientation.org, 2005–06.
5. Microsoft Windows Communication Foundation team (2012 [last update]). "Principles of
Service Oriented Design".msdn.microsoft.com. Retrieved September 3, 2012.
6. Tony Shan, "Building a Service-Oriented eBanking Platform", scc, pp.237-244, First
IEEE International Conference on Services Computing (SCC'04), 2004.
7. SOA Practitioners Guide Part 2: SOA Reference Architecture.
8. Bieberstein et al., Service-Oriented Architecture (SOA) Compass: Business Value,
Planning, and Enterprise Roadmap (The developerWorks Series) (Hardcover), IBM Press
books, 2005, 978-0131870024.
9. Hoyer, Volker ; Stanoesvka-Slabeva, Katarina; Janner, Till; Schroth, Christoph;
(2008). Enterprise Mashups: Design Principles towards the Long Tail of User Need.

service orentation documentation

Recommended

More Related Content

What's hot (20)

Similar to service orentation documentation (20)

Recently uploaded (20)

service orentation documentation