SOA Architecture and infrastructure

Submitted by:
Shweta gupta(IT3)
46

Introduction to Service Oriented Architecture

Service Oriented Architecture (SOA) is an evolution of the Component Based

Architecture4,
Interface Based Design (Object Oriented) and Distributed Systems of the 1990s,
such as DCOM5,
CORBA® 6, J2EETM 7 and the Internet in general.
SOA does not specifically mean Web Services, .NET TM, J2EE, CORBA or
ebXML. These are instead specialized SOA implementations that embody the core
aspects of a service-oriented approach to architecture.
Each of these implementations extends the basic SOA Reference Model described
in this paper.

Component based architecture

A Component Based Architecture is an architecture where the functionality of the

whole is divided into smaller functions, each encapsulated in a component.
A Distributed System is an extension of components-based architecture and refers
to components that may exist in different physical locations.
A simple example of a distributed, component-based architecture is email
architecture. Desktop clients, a DNS9 service and mail servers all interact with
each other but are often in different physical locations. This architecture also
qualifies as an implementation of SOA..

Localized definition for SOA

Several implemented architectures and infrastructures claim to be SOA. In the
absence of a formal definition and reference model, amalgamating the principle
elements of these implementations captures the main SOA concepts.
The following main concepts are consistent in all SOA implementations:
➤ Services
➤ Service descriptions (including security parameters and constraints, reusability
and
repurpose-ability)
➤ Advertising and discovery
➤ Specification of an associated data model
➤ Service contract

Main concepts of SOA

This section explores the main concepts of SOA and provides specific examples of
their implementation.

Services
A service is a contractually defined behavior that can be implemented and
provided by a component for use by another component.
Known implementations
The term “services” does not imply web services; although, web services are well
known implementations of services. Other specialized implementations include
J2EE6 and .NET7.

Service descriptions
The service description consists of the technical parameters, constraints and
policies that define
the terms to invoke the service. Each service should include a service definition in
a standardized format. This enables applications and human actors to examine the
service description and
determine issues such as, what the service does, how they may bind to it, and what
security protocols (if any) must be used with it.
The declaration may also include details about any implied process or other legal
or business
terms that occur when the service is invoked. For example, if a service consumer
invokes
a service that places a purchase order to the service provider, and the execution is
successful, it
may result in a financial responsibility to the service provider or some other legal
entity.

Advertising and discovery of services

What is advertising?
A service must communicate its service description in an accessible manner to
potential consumers.
It does so by using one of several advertising methodologies, such as Pull and
Push.
In the Pull methodology, potential service consumers request the service provider
to send them the service description. This pull methodology may be invoked as a
service itself.
In the Push methodology, the service provider, or its agent, sends the service
description to potential service consumers.

Service-oriented architectures have the following key characteristics:

 SOA services have self-describing interfaces in platform-independent XML

documents. Web Services Description Language (WSDL) is the standard
used to describe the services.
 SOA services communicate with messages formally defined via XML
Schema (also called XSD). Communication among consumers and providers
or services typically happens in heterogeneous environments, with little or
no knowledge about the provider. Messages between services can be viewed
as key business documents processed in an enterprise.
 SOA services are maintained in the enterprise by a registry that acts as a
directory listing. Applications can look up the services in the registry and
invoke the service. Universal Description, Definition, and Integration
(UDDI) is the standard used for service registry.
 Each SOA service has a quality of service (QoS) associated with it. Some of
the key QoS elements are security requirements, such as authentication and
authorization, reliable messaging, and policies regarding who can invoke
services.

Why SOA?

The reality in IT enterprises is that infrastructure is heterogeneous across operating

systems, applications, system software, and application infrastructure. Some
existing applications are used to run current business processes, so starting from
scratch to build new infrastructure isn't an option. Enterprises should quickly
respond to business changes with agility; leverage existing investments in
applications and application infrastructure to address newer business requirements;
support new channels of interactions with customers, partners, and suppliers; and
feature an architecture that supports organic business. SOA with its loosely
coupled nature allows enterprises to plug in new services or upgrade existing
services in a granular fashion to address the new business requirements, provides
the option to make the services consumable across different channels, and exposes
the existing enterprise and legacy applications as services, thereby safeguarding
existing IT infrastructure investments.

SOA infrastructure

To run and manage SOA applications, enterprises need an SOA infrastructure that
is part of the SOA platform. An SOA infrastructure must support all the relevant
standards and required runtime containers. A typical SOA infrastructure looks like
Figure 3. The following sections discuss the infrastructure's individual pieces.

Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized

image.

SOAP, WSDL, UDDI

WSDL, UDDI, and SOAP are the fundamental pieces of the SOA infrastructure.
WSDL is used to describe the service; UDDI, to register and look up the services;
and SOAP, as a transport layer to send messages between service consumer and
service provider. While SOAP is the default mechanism for Web services,
alternative technologies accomplish other types of bindings for a service. A
consumer can search for a service in the UDDI registry, get the WSDL for the
service that has the description, and invoke the service using SOAP.
WS-I Basic Profile

WS-I Basic Profile, provided by the Web services Interoperability Organization, is

turning into another core piece required for service testing and interoperability.
Service providers can use the Basic Profile test suites to test a service's
interoperability across different platforms and technologies.

J2EE and .Net

Though the J2EE and .Net platforms are the dominant development platforms for
SOA applications, SOA is not by any means limited to these platforms. Platforms
such as J2EE not only provide the framework for developers to naturally
participate in the SOA, but also, by their inherent nature, bring a mature and
proven infrastructure for scalability, reliability, availability, and performance to the
SOA world. Newer specifications such as Java API for XML Binding (JAXB),
used for mapping XML documents to Java classes, Java API for XML Registry
(JAXR), used for interacting with the UDDI registries in a standard manner, and
Java API for XML-based Remote Procedure Call (XML-RPC), used for invoking
remote services in J2EE 1.4 facilitate the development and deployment of Web
services that are portable across standard J2EE containers, while simultaneously
interoperating with services across other platforms such as .Net.

Quality of services

Existing mission-critical systems in enterprises address advanced requirements

such as security, reliability, and transactions. As enterprises start adopting service
architecture as a vehicle for developing and deploying applications, basic Web
services specifications like WSDL, SOAP, and UDDI aren't going to fulfill these
advanced requirements. As mentioned previously, these requirements are also
known as quality of services. Numerous specifications related to QoS are being
worked out in standards bodies like the World Wide Web Consortium (W3C) and
the Organization for the Advancement of Structured Information Standards
(OASIS). Sections below discuss some of the QoS artifacts and related standards.

Security
The Web Services Security specification addresses message security. This
specification focuses on credential exchange, message integrity, and message
confidentiality. The attractive thing about this specification is it leverages existing
security standards, such as Security Assertion Markup Language (SAML), and
allows the usage of these standards to secure Web services messages. Web
Services Security is an ongoing OASIS effort.

Reliability
In a typical SOA environment, several documents are exchanged between service
consumers and service providers. Delivery of messages with characteristics like
once-and-only-once delivery, at-most-once delivery, duplicate message
elimination, guaranteed message delivery, and acknowledgment become important
in mission-critical systems using service architecture. WS-Reliability and WS-
ReliableMessaging are two standards that address the issues of reliable messaging.
Both these standards are now part of OASIS.

Policy
Service providers sometimes require service consumers to communicate with
certain policies. As an example, a service provider may require a Kerberos security
token for accessing the service. These requirements are defined as policy
assertions. A policy may consist of multiple assertions. WS-Policy standardizes
how policies are to be communicated between service consumers and service
providers.

Orchestration
As enterprises embark on service architecture, services can be used to integrate
silos of data, applications, and components. Integrating applications means that the
process requirements, such as asynchronous communication, parallel processing,
data transformation, and compensation, must be standardized. BPEL4WS or
WSBPEL (Web Services Business Process Execution Language) is an OASIS
specification that addresses service orchestration, where business processes are
created using a set of discrete services. WSBPEL is now part of OASIS.

Management
As the number of services and business processes exposed as services grow in the
enterprise, a management infrastructure that lets the system administrators manage
the services running in a heterogeneous environment becomes important. Web
Services for Distributed Management (WSDM) will specify that any service
implemented according to WSDM will be manageable by a WSDM-compliant
management solution.

Benefits of SOA
While the SOA concept is fundamentally not new, SOA differs from existing
distributed technologies in that most vendors accept it and have an application or
platform suite that enables SOA. SOA, with a ubiquitous set of standards, brings
better reusability of existing assets or investments in the enterprise and lets you
create applications that can be built on top of new and existing applications. SOA
enables changes to applications while keeping clients or service consumers isolated
from evolutionary changes that happen in the service implementation. SOA
enables upgrading individual services or services consumers; it is not necessary to
completely rewrite an application or keep an existing system that no longer
addresses the new business requirements. Finally, SOA provides enterprises better
flexibility in building applications and business processes in an agile manner by
leveraging existing application infrastructure to compose new services.

Bibliography:

Wikipedia.org

Ebook soa architecture and infrastructure

Submitted to :

Sunil jangir

Lecturer