Hi,

Any one Explain.

Thanks,
Sundar Raja

A service-oriented architecture is essentially a collection of services. These 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. For more on DCOM and CORBA, see Prior service-oriented architectures (new window).
Services

If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. See Service (new window).
Connections

The technology of Web services (new window) is the most likely connection technology of service-oriented architectures. Web services essentially use XML (new window) to create a robust connection.

The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. How those connections are defined is explained in Web Services explained (new window). A service provider can also be a service consumer.

Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services' underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.
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.

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

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.
As in Figure 1's example, an enterprise employing SOA could create a supply chain composite application using a set of existing applications that expose the functionality via standard interfaces.

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

Figure 1. Supply chain application. Click on thumbnail to view full-sized image.
Service architecture

To implement SOA, enterprises need a service architecture, an example of which is shown in Figure 2.

Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.
In Figure 2, several service consumers can invoke services by sending messages. These messages are typically transformed and routed by a service bus to an appropriate service implementation. This service architecture can provide a business rules engine that allows business rules to be incorporated in a service or across services. The service architecture also provides a service management infrastructure that manages services and activities like auditing, billing, and logging. In addition, the architecture offers enterprises the flexibility of having agile business processes, better addresses the regulatory requirements like Sarbanes Oxley (SOX), and changes individual services without affecting other services.

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

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.

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

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.

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

Other QoS attributes such as coordination between partners and transactions involving multiple services are being addressed in the WS-Coordination and WS-Transaction specifications, respectively, which are OASIS efforts as well.
SOA is not Web services

There seems to be general confusion about the relationship between SOA and Web services. In an April 2003 Gartner report, Yefim V. Natis makes the distinction as follows: "Web services are about technology specifications, whereas SOA is a software design principle. Notably, Web services' WSDL is an SOA-suitable interface definition standard: this is where Web services and SOA fundamentally connect." Fundamentally, SOA is an architectural pattern, while Web services are services implemented using a set of standards; Web services is one of the ways you can implement SOA. The benefit of implementing SOA with Web services is that you achieve a platform-neutral approach to accessing services and better interoperability as more and more vendors support more and more Web services specifications.
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.

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

A system for linking resources on demand. In an SOA, resources are made available to other participants in the network as independent services that are accessed in a standardized way. This provides for more flexible loose coupling of resources than in traditional systems architectures. RFID Anywhere's Service Oriented Architecture enables easy integration into the existing infrastructure including feeds into multiple existing applications and interfaces with system and network management software. With its support for distributed configurations and edge processing, RFID Anywhere allows multiple locations to collect RFID data whether or not the rest of the enterprise is available to receive it.

__________________
Shaalini.S
Be the Best of Whatever you are...

SOA is based on the following:

A service provider who provides the service

A service consumer who uses the service

A service registry

A service contract

Service publication and dynamic service lookup

The three basic functions of this architecture are:

Register

Find

Bind

What is a Service?

A service is an implementation of a well-defined, self-contained, independent business functionality that accepts one or more requests and returns one or more responses through a well-defined, standard interface.

The following are the basic properties of a service:

The interface contract to the service is platform-independent.

A service can be dynamically located and invoked.

A service is self-contained.

There should be loose coupling between the service consumer and its provider.

A service should focus on business functions and not the technology.

SOA Concepts

In order to have a proper understanding of this technology, the following key concepts need to be understood.

Service Provider

The service provider is the network-addressable entity that accepts and executes requests from consumers. The service provider publishes its contract in a service registry for dynamic access by the service consumers.

Service Consumer

The service consumer is an application that requires a service. It is the entity that initiates the locating of the service in the registry, binding to the service over a transport, and executing the service function.



Service Contract

A contract is a specification of the way a consumer of a service will interact with the provider of the service. It specifies the format of the request and response from the service.

Service Proxy

The service provider provides a service proxy to the service consumer. The service consumer executes the request by calling an API function on the proxy. The service proxy finds a contract and a reference to the service provider in the registry. It then formats the request message and executes the request on behalf of the service consumer.

Service Lease

The registry grants the service consumer a service lease that specifies the duration for which the service is valid. When the lease expires, the service consumer must request a fresh lease from the registry. It reduces the coupling between the service consumer and the service provider.

Message

Messages are the means of communication between service producers and consumers. These are typically constructed using XML documents that conform to XML schema.

Service Description

This consists of the parameters, constraints, and the policies that define how to invoke the service in a standardized format.

Advertising and Discovery

Advertising refers to the ability of a service to communicate its description to the service consumers. This can be of the following types:

Pull

Push

In the pull methodology, the service consumers request the providers to send them the service description. In the push methodology, however, the service provider sends the service description to the service consumer.

Service Registry

The relationship between a service provider and its consumer is dynamic and is established at runtime by a binding mechanism in a network based repository known as the service registry. The service provider registers a service with the service registry that contains all the available services that are published by the service provider.

The benefits of the service registry include:

Scalability

Decoupling

Hot updates

Dynamic service lookup



Benefits of SOA

The benefits of the SOA approach are:

Platform independence

Simplified Integration

Reduced Risk

Decoupling between service providers and service consumers

Incremental development, deployment, and maintenance

Location transparency

Simplified application maintenance and lower maintenance costs



Conclusion

Service Oriented Architecture (SOA) is the best scalable solution to reduce complexities in the software industry today, but it has yet to have a standardized business model. The industry experts feel that once this is achieved, it promises to be a solution for many businesses for the years to come.



For Further Reading

Please refer to the following links for more information on Service Oriented Architecture.

ONDotnet.com -- Service-Oriented Architecture Explained