Service Oriented

Architecture (SOA)

Presented By
SureShot Strategies Inc.
Agenda
What is a Service Oriented Architecture?
Web Services Introduction
Basic Web Services
Web Services versus other Distributed Technologies
Advanced Web Services
Anatomy of Service Oriented
Architecture
Fundamental SOA
SOA Entities
Common Principles of SOA
Web Services & SOA Principles
Service Layering
Service Delivery Strategies
SOA support in J 2EE
SOA support in .NET
SOA support in Super Platforms
SOA Adoption Roadmap & Compliance Levels
What is a Service Oriented Architecture?
The Elevator Pitch
SOA is the next phase in the evolution of designing software
systems
In the same manner in which mainframe architecture paradigm was
succeeded by client-server architecture, and client-server
architecture paradigm then evolved into n-tier distributed
architecture based on Web Technologies, the contemporary, Web
services driven SOA is succeeding the traditional distributed
architecture on a global scale
Due to its abstract nature and distributed architecture with no
reference to underlying implementation (implementation agnostic),
SOA introduces new concepts supported by select technologies that
significantly augment characteristics of traditional distributed
computing platform
Coupled with Web services platform and a set of commonly
accepted service-oriented principals, SOA has emerged an
architectural paradigm explicitly distinct from its predecessors
Web Services, a Brief
Introduction
What are Web Services?
Web services are a form of web applications that are self-contained,
self-describing and modular, and that can be published, located, and
invoked across the web using standard Internet protocols.
leverage existing HTTP infrastructure
leverage wide adoptability and flexibility of XML to define and package
messages
Standards


HTTP/FTP/SMTP
XML
SOAP
WSDL
UDDI
Transport
XML Schema for all Definitions
Message Envelope
Service Description
Service Registry
Web Services combine the best aspects of component-based
development and the Web. Like components, Web Services
represent black-box functionality that can be reused without
worrying about how the service is implemented.
Unlike current component technologies, Web Services are not
accessed via object-model-specific protocols, such as DCOM,
RMI, or IIOP. Instead, Web Services are accessed via ubiquitous
Web protocols (ex: HTTP) and data formats (ex: XML).
Web services are Extensible Markup Language (XML)
applications mapped to programs, objects, or databases or to
comprehensive business functions.
Using an XML document created in the form of a message, a
program sends a request to a Web service across the network,
and, optionally, receives a reply, also in the form of an XML
document.
Basics of Web Services
A Web service can be developed on any computer platform and
in any development environment, as long as it can communicate
with other web services using these common protocols.
Web services standards define the format of the message,
specify the interface to which a message is sent, describe
conventions for mapping the contents of the message into and
out of the programs implementing the service, and define
mechanisms to publish and to discover Web services interfaces.
Web services are not a specific technology, but rather a group of
established and emerging communication protocols. Following
are the basic characteristics of the Web Services framework:
An abstract (vendor-neutral) existence defined by standards organizations
and implemented by (proprietary) technology platforms
Core building blocks that include Web services, service descriptions, and
messages
A communications agreement centered around service descriptions based
on WSDL
A messaging framework comprised of SOAP technology and concepts
A service description registration and discovery architecture realized
through UDDI
A well-defined architecture that supports messaging patterns (Request-
Response, Fire-and-Forget, Publish-Subscribe .. )
A messaging framework comprised of SOAP technology and concepts
Basics of Web Services Framework
Java, C++, VB,
CORBA ORB
Windows MTS
Mid-1990s
CORBA/COM
e.g. IIOP/DCOM
VB, C++,
Database
Stored Procedure
Early 1990s
Client/Server
e.g. OCI
1980s
TP Monitor
Cobol, C
CICS,
Tuxedo
e.g ATMI
Java, VB,
C++, Python
J2EE Container
Windows
XML/SOAP
Early 2000s
Web Services
Java
J2EE Container
(EJB)
RMI
Late-1990s
J2EE
Client Server Message Protocol
Basics of Web Services
Web Services versus other Distributed
Technologies
CORBA
Basic wire protocol is GIOP, or General Inter-ORB protocol
TCP/IP specialization of GIOP is called IIOP for Internet Inter-ORB protocol.
IIOP maps the basic GIOP protocol to TCP/IP
DCOM
Wire protocol is ORPC (Object Remote Procedure Call). ORPC is very DCE
RPC-like wire protocol with certain extensions
Java RMI (Remote Method Invocation)
Wire protocol is JRMP (Java Remote Method Protocol)
Web Services
Wire protocol is SOAP (Simple Object Access Protocol).
Unlike other wire protocols, SOAP is built upon open technologies, rather
than vendor-specific technologies.
SOAP works out-of-the-box in a wide range of user locations that enable
HTTP standard port 80.
Only negative in the case of SOAP is overhead due to XML processing.
However, SOAP interoperability mitigates XML processing if you consider the
other protocol conversions one must undertake to connect to disparate
computer architectures.
Basics of Web Services
Web Services versus other Distributed
Technologies (Cont ..)
Object Oriented Programming (OOP) based distributed
technologies such as DCOM and RMI arent intended to link
disparate systems and cant communicate with one another.
CORBA & Web Services are both interface technologies.
CORBA is also capable of linking heterogeneous systems just
like Web Services. But CORBA mandates that the underlying
applications be object oriented. This is because only OO
environments can be CORBA compliant.
Web Services, on the other hand, do not enforce this
requirement. Underlying implementations in the case of Web
Services could be OOP or with procedural or simple scripting
languages (such as Perl or PHP), and can communicate with
other web services endpoints whether the are object oriented or
not.
Basics of Web Services
Web Services versus other Distributed
Technologies (Cont ..)
Web services, unlike other technologies, is not tightly coupled.
With technologies such as CORBA, DCOM, and RMI, the
programs at each endpoint must have substantial knowledge of
one another. For example, if there is a change in the name of
remote program or its methods, the invoking program must be
modified accordingly. Loosely coupled web services, on the other
hand, do not depend on intimate knowledge of the endpoint
implementations.
Basics of Web Services
Web Services versus other Distributed
Technologies (Cont ..)
Basic Web services framework is established by the first-
generation standards such as WSDL, SOAP, and UDDI.
However, the basic web service framework falls short at building
enterprise level software systems. Following are few of the
umpteenth challenges lie in building enterprise level software
systems:
Transactional Integrity: Basic first-generation web services framework
does not address agreement on a standardized way to manage complex
transactions using web services when they involve multiple disparate
systems with different transaction semantics.
Security & Single Signon: Security is one of the missing piece in the basic
first-generation web services framework. Building enterprise level software
systems require that we develop trust mechanisms that span organizational
boundaries and operate with disparate technologies. Standards for
authentications, authorization, encryption, and non-repudiation are not
addressed in the basic first-generation web services framework. Single
Signon is another example of missing piece in order for distributed
autonomous services to seamlessly communicate with one another.
Advanced Web Services
Orchestration and Choreography: One of the premise of web services is
that well be able to create adhoc and agile multi-party business processes
by stringing together relevant services. In order for this to happen, there is a
need for standards that can coordinate or orchestrate complex transactions
and choreograph multi-party business processes. Basic first-generation web
services framework does not address these capabilities.
Reliable Asynchronous Message Handling: Systems that are both reliable
and capable of handling high traffic loads require a robust asynchronous
messaging system. The problem with unreliable systems is that messages
are sometimes lost due to errors, bottlenecks, or outages etc. The solution to
this problem is a system that queues and saves messages until delivery to
have occurred. Again, basic first-generation web services standards do not
address this capability.
Contracts and Negotiations: A successful web-services strategy must
include plans for more than just technology. Before business partners can be
linked via web services, there has to be agreement as to the terms and
conditions of their relation. Basic first-generation web services standards do
not address these capabilities.
and so on ...
Advanced Web Services (Cont ..)
Basic Web services standards have been evolved to address all
of these shortcomings in order to build enterprise level software
systems. Advanced Web services standards are called WS-*
extensions. The term WS-* has been coined for advanced Web
Services standards as majority of the second-generation Web
services specifications have been prefixed with WS-. Following
are few of the second-generation standards:
Advanced Web Services (Cont ..)
WS-* Standards
WS-BPEL (also known as BPEL4WS)
WS-Discovery
WS-Addressing
WS-Trust
WS-Security
WS-SecureConversation
WS-Policy
WS-PolicyAttachment
SAML
XACML/XrML
WS-CDL
WS-Coordination
WS-Topics
WS-Eventing
WS-ReliableMessaging
WS-Federation
WS-Policy
and so on
Anatomy of Service Oriented
Architecture
Term service oriented is an established and generic theory. It
has existed for some time and has been used to address variety
of problems. It basically represents a distinct approach for
separating concerns whereby logic required to solve a large
problem is better constructed, carried out, and managed if it is
decomposed into a collection of smaller, related pieces. Each of
these pieces addresses a concern or a specific part of the
problem.
When coupled with architecture, service-orientation takes on a
technical connotation. SOA represents software discipline in
which automation logic is decomposed into smaller, distinct units
of logic. Collectively these units comprise a larger piece of
business automation logic. These autonomous units of logic are
known as services.
In addition to services, the basic SOA model comprises of two
other elements namely: processes, and organizations.
Monolithic stovepipe applications are dissolved in favor of self-
contained business services, which perform specific business
functions.
Fundamental SOA
The main characteristics of business services is that they provide
value for the business. Additionally, these services must be
coarse-grained as requests for invocation of fine-grained services
can lead to network chatter and as a result clogging of the
network.
Business processes orchestrate the execution of these business
services to fulfill required business functionality such as order
processing or claims processing. Business processes are
usually associated with operational objectives and business
goals such as insurance claims processing etc. Processes have
defined triggering (initiation) mechanism for each of new process
instance (for example, on arrival of an insurance claim).
Organization owns all of the SOA artifacts such as services and
processes. It governs their creation, usage, access, and
maintenance.
Although not part of the basic SOA, an extended SOA model
incorporates the enterprise semantic data model to the SOA
definition.
Fundamental SOA (Cont..)
The enterprise level semantic data model defines the standard
business objects for a given enterprise (such as insurance
policies and claims). This effectively creates ontology of the
enterprise data by defining common concepts describing
functioning of the enterprise. This, in turn, leads to the creating of
interoperable semantic interface definitions called semantic
SOA.
SOA prescribes an approach for modeling business automation
logic called services. This approach has resulted in a set of
commonly accepted principles applied to each unit of logic that
constitutes a service within SOA.
Generally there is a misconception that an application that
uses Web service is service-oriented. This is not true and is a
myth. One needs to go through the whole rigor of applying a set
of commonly accepted SOA principles to the Web services
components (Web services, descriptions, operations, and
messages). Once these SOA principles are applied, the basic
Web service components are shaped in support of service-
orientation.
Fundamental SOA (Cont..)
Even though there are some SOA principles which require
special attention (at the time of analysis & design phases) while
building service-oriented solutions using Web services as the
underlying technology platform, Web services in general do
provide a framework for automatically enforcing majority of the
SOA principles.
The underlying synergy of the marriage between SOA and the
Web services technology platform makes Web services
technology platform as the ideal choice for building SOA based
enterprise solutions.
Fundamental SOA (Cont..)
The find, bind, and execute paradigm as depicted in the next slide
allows consumer of a service to ask a third-party registry for the service
that matches its criteria. If registry has such a service, it gives the
consumer a contract and endpoint address for the service. SOA
primarily consists of the following entities configured together to support
the find, bind, and execute paradigm.
Service Consumer: This entity is an applications, service, or some other type of
software module that requires a service. This entity initiates the locating of the service
registry, binding to the service over a transport, and executing the service function.
The service consumer executes the service by sending it a request formatted
according to the contract.
Service Provider: This entity is the service, the network-addressable entity that
accepts and executes requests from consumers.
Service Registry: This entity is a network-based directory that contains available
services. It accepts and stores contracts from service providers and provides those
contracts to interested service consumers.
Service Contract: A contract is a specification of the way a consumer of a service
will interact with the provider of the service. The contract may also specify quality of
service (QoS) levels. QoS levels are specifications for the non-functional aspects of
the service. For instance, a quality of service attribute is the amount of time it takes to
execute a service operation.
SOA Entities
Service Consumer
5. Develop application and bind to
service
2. Publish
3. Find
6. Request Service
Service Provider
1. Develop service, document
interface
Service Registry
Service providers deploy and publish services by registering them
with the Service broker
Service consumers find services by searching the Service
broker's registry of published services
Service consumers bind to the Service provider and consume the
available services
4. List of Service
Providers & Descriptions
7. Deliver Service
SOA Entities (Cont..)
WSDL
Web Service
(J2EE,
.NET,C/C++,
Legacy )
Web Service
Client
(J2EE, .NET )
Points to
description
Describes
Service
Finds
Service
Invokes with
XML Messages
Web Services Technologies
SOAP
UDDI
Registry
Points to
service
SOA Entities (Cont..)
The service description can be implemented by a number of service
providers, each offering various choices of qualities of service (QoS)
based on technical requirements in the areas of availability,
performance, scalability, and security etc.
The collections of services with various levels of granularity can be
combined and choreographed to produce new composite services that
not only introduce new levels of reuse but also allow the dynamic
reconfiguration of business systems.
SOA Entities (Cont ..)
Services are reusable: Regardless of whether immediate reuse
opportunities exist, services are designed with broad applicability
in mind. The published interface must be universal.
Services are loosely coupled: Services must be designed to
interact without the need for tight, cross-service dependencies
Services abstract underlying implementation: The only part of
a service that is visible to the outside world is what is exposed
via the service contract. Underlying logic is invisible and
irrelevant to the service requestors
Services are composable: Services may compose other
services. This promotes reusability
Services are autonomous: The logic governed by a service
resides within an explicit boundary. The service has total control
within this boundary and is not dependent on other services for it
to execute its governance.
Services are stateless: Services should not be required to
manage state information, as that can impede their ability to be
loosely coupled. Services should be designed to maximize
statelessness even if that means deferring state management
elsewhere.
Common Principles of SOA
Services are discoverable: Services should allow their descriptions to
be discovered and understood by humans and service requestors that
may be able to make use of their logic.

All of these SOA principles relate to, support, or are affected by others.

Service reusability: When a service encapsulates logic that is useful
to more than one service requestor, it can be considered reusable.
This concept is supported by a number of complementary principles:
Service autonomy establishes an execution environment that facilitates reuse
because the service has independence and self-governance. The less
dependencies a service has, the broader the applicability of its reusable
functionality.
Service statelessness supports reuse because it maximizes the availability of a
service and typically promotes a generic service design that defers activity specific
processing outside of the service logic boundaries.
Service discoverability promotes reuse, as it allows requestors to search for an
discover reusable services.
Service loose coupling establishes an inherent independence that frees a service
from immediate ties to others. This makes it a great deal easier to realize
reusability.
Common Principles of SOA (Cont ..)
Service loose coupling: Loose coupling is a state that supports a
level of independence between services. This concept is supported by
a number of complementary principles:
Service reusability is supported through loose coupling because services are freed
from tight dependencies on others. This increases their availability for reuse.
Service composition is enabled by the loose coupling of services, especially when
services are dynamically composed.
Service statelessness is directly supported through the loosely coupled
communications framework.
Service autonomy is made possible through this principle, as it is the nature of
loose coupling that minimizes cross-service dependencies.
Service abstraction is what enables loose coupling between services, as the
contract is the only piece of information required for services to interact with each
other.
Service abstraction: This allows services to encapsulate potentially
complex processing logic and exposing that logic through a generic
and descriptive interface:
Service loose coupling is directly implemented through the application of service
abstraction principle as mentioned before.
Common Principles of SOA (Cont ..)
Service composability: Designing services that they support
composition by others is fundamental to building service-oriented
solutions. This concept is supported by a number of complementary
principles:
Service loose coupling establishes a communications framework that supports the
concept of dynamic service composition. This mainly because services are freed
from many dependencies, they are more available to be reused via composition.
Service statelessness supports service composability. It enables harmonious
composition execution.
Service autonomy held by composition members strengthens the overall
composition.
Service autonomy: This principle applies to a services underlying
logic:
Service reusability is more easily achieved when service offering reusable logic
has self-governance over its own logic.
Service composability is also supported through service autonomy. A service
composition consisting of autonomous services is much more robust and
collectively independent.

Common Principles of SOA (Cont ..)
Service statelessness is best implemented by a service that can execute
independently.
Service loose coupling is a primary enabler of service autonomy.
Service statelessness: This principle is indirectly supported by:
Service loose coupling establishes a communication paradigm that is fully realized
through messaging. Messaging, in turn, supports service statelessness, as the state
information is carried and persisted by the messages that pass through the
services.
Service composability benefits from stateless composition members, as they
reduce dependencies.
Service reuse becomes more of a reality for stateless services, as availability of the
service to multiple requestors is increased and the absence of activity-specific
process logic promotes a generic service design.
Service discoverability: This principle is tied closely to the following
principles:
Service abstraction extent of a services discoverability is typically be associated
with the quality or descriptiveness of its service contract.
Service reusability is what requestors are looking for when searching for services
and it is what makes a service potentially useful once it has been discovered.
Common Principles of SOA (Cont ..)
Services are reusable: Web services are not automatically reusable
Services are loosely coupled: Web services are naturally loosely
coupled through the use of service descriptions
Services abstract underlying implementation: Web services are
automatically emulate the black box model within the Web services
communications framework, hiding all the details of their underlying
logic
Services are composable: Web services are naturally composable.
The extent to which a service can be composed, though, generally is
determined by the service design and the reusability of represented
logic
Services are autonomous: Autonomy is not automatically provided by
Web services framework
Services are stateless: Statelessness is a preferred condition for Web
services and is strongly supported by many WS-* specifications and
the document-style SOAP messaging model
Services are discoverability: Web services framework does provide
basic discoverability mechanism using UDDI directory.
Web Services & SOA Principles
It turns out that mostly all of the SOA principles except for Reusability
& Autonomy are not supported by Web Services framework. This
underlines the synergy of the marriage between SOA and the Web
services technology platform and gives a good indication as to why
Web services have been so successful in realizing SOA. Principles
such as reusability & autonomy which are not automatically provided
by Web services, they need special attention while building service
oriented solutions. Concepts such as service layering in conjunction
with service modeling and design provide detail guidelines to this
regard.
Web Services & SOA Principles
(Cont ..)
There are three layers of abstraction defined at the services layer level:
Application service layer: This layer establishes the ground level foundation that
exists to express technology-specific functionality. Their purpose is to provide
reusable functions related to processing data within new or legacy application
environments.
Wrapper services
Utility services
Business service layer: While application services are responsible for representing
technology and application logic, the business service layer introduces a service
concerned solely with representing business logic.
Entity centric business service
Orchestration service layer: This layer assumes the role of the process part. This
layer introduces a parent level of abstraction that alleviates the need for other
services to manage interaction details required to ensure that service operations are
executed in a specific sequence.
Service Layering
There are primarily three strategies as far as transitioning toward a
standardized SOA while helping an IT organization to fulfill immediate
project-specific requirements. These strategies are based on an
organizations priorities to establish the correct balance between the
delivery of long-tem migration goals with versus fulfillment of short-
term requirements:
Top-down: This approach requires that SOA be adopted by the enterprise as a
whole and requires a lot of preliminary work such as definitions of the enterprise-
wide business processes, semantics, and so on.

Top-down SOA approach usually starts with building a business model of the
enterprise, defining both processes and semantics, and then mapping this model
onto business services. This approach to SOA design allows for better alignment of
business and application perspectives. Subsequently, it becomes easier to trace the
application perspective back to the business perspective, thus simplifying
implementation of required changes in the business functionality. This design
approach also facilitates separation of the business servicesfairly stable
processing unitsfrom business processesfast changing elements of a business
model. The changed elements are usually expressed in changes of business rules,
governing execution of the business processes, and sequence of service
invocations.
Service Delivery Strategies
Bottom-up: The bottom-up approach can originate on the departmental and group
level, starting by exposing existing applications as services and building on those
services.

The bottom-up SOA design approach usually starts from defining integration services,
based on the functionality of existing applications and their integration requirements,
which lets us service-enable existing applications and create an integration layer.
Although the resulting system looks like an SOA implementation, it usually suffers from
multiple drawbacks. Services created using this approach are usually tied not to
enterprise-wide functionality, but to the existing applications, which can create a tight
coupling between the application portfolio and business services that might complicate
changes in the application portfolio. Because of significant duplication of functionality
in applications, this approach can create a significant amount of services with the
same or similar functionality.
Middle Rendezvous: Considering the significant investment that is required for the
top-down design approach, the other option is to combine it with the bottom-up SOA
design. In this case some of the integration services can be designed and
implemented simultaneously with the defining of the enterprise business model and
business services. In theory this approach can speed up SOA implementationby the
time business services are designed, some of the integration services will already be
in place for the business services to usebut implementation of the integration
services has to follow a well-defined process.

The meet-in-the-middle approach can see faster results than using the top-down
approach, and it is better aligned with long-term goals and values than the bottom-up
design. Now let's look at implementation.
Service Delivery Strategies


Different Operating Systems


EJB Container Web Container


Java Runtime


J2EE Class Libraries


JAX-RPC Runtime


Stateless EJBs Servlets


Service-Oriented Solutions
SOA support in J2EE
Belongs
to J2EE
Platform


Windows Operating System


WSE ASP.NET


Common language Runtime (CLR)


.NET Class Libraries


Assemblies


Service-Oriented Solutions
SOA support in .NET
Belongs to
.NET
Framework
SAP NetWeaver & Oracle Fusion
SOA Support in Super Platforms
SAP NetWeaver
SAP Portal
SAP Collaboration
SAP BI
SAP
KM (Part of Portal)
SAP Mobile Interfaces
SAP Master Data Management
SAP Integration
Server
SAP BPM System
SAP J2EE App
Server
SAP Data Connectors
SAP ABAP App
Server

UI




Information



Integration


Business and
System
Services,
App Server

Data
Plumbing
Level 1: Initial Services (Developer Sponsorship)
Scope: R&D experimentation, Pilot projects, Portal, Custom integrations, Small
number of services
Success Factors: Developers learn service development skills such as Web
services standards, & Legacy Integration.
Selected Standards & Technology: XML, XSLT, WSDL, SOAP, Java, .NET
Level 2: Architected Services (CIO Sponsorship)
Scope: Multiple integrated applications
Business Benefits: IT cost reduction and control
Success Factors: Architecture group provides leadership SOA Competency
Center by providing support for heterogeneity and distributed systems, Reliable
Messaging, Mediation, Ease of deployment, Database integration, Versioning,
Internal Security, Performance management.
Selected Standards & Technology: UDDI, WS-ReliableMessaging, WS-
Policy, WS-Addressing, XQuery, WS-Security, SAML
SOA Adoption Roadmap &
Compliance Levels
Level 3: Business & Collaborative Services (Business Unit
Sponsorship)
Scope: Business processes across business unit, enterprise or cross
enterprise
Business Benefits: Business responsiveness
Success Factors: IT Partnership with Business Partnership across
Organizations through Reuse, Ease of modification, Availability, Business
process rules, Event-driven processes, Composite applications.
Selected Standards & Technology: WS-BPEL, WS-CDL
Level 4: Measured Services (CFO Sponsorship)
Scope: Business unit or enterprise, Cross-enterprise
Business Benefits: Business transformation from reactive to real-time, Meet
business performance metrics
Success Factors: On-going business process evaluation and response
through Business Activity Monitoring, Event Stream Processing, Complex
Event Processing, Event-driven dashboards and alerts.
Selected Standards & Technology: WS-Eventing, BAM
SOA Adoption Roadmap &
Compliance Levels (Cont ..)
Level 5: Optimized Services (CEO Sponsorship)
Scope: Business unit or enterprise, Cross-enterprise
Business Benefits: Business optimization react and respond automatically
Success Factors: Continuous improvement culture through event-driven
automation for optimization
Selected Standards & Technology: Amalgamation of Event Driven
Architecture (EDA) with SOA.
SOA Adoption Roadmap &
Compliance Levels (Cont ..)
Q & A