Service-Oriented Architecture (SOA) SOA is a software architecture in which reusable services are deployed into application servers and

then consumed by clients in different applications or business processes. Service-oriented architecture (SOA) is an approach for loosely coupled, protocol independent, standards-based distributed computing where software resources available on the network are considered as Services. It's an architectural style of building software applications that promotes loose coupling between components so that we can reuse them.

It is a new way of building applications with the following characteristics: Services are software components that have published contracts/interfaces; these contracts are platform, language, and operating-system-independent. XML and the Simple Object Access Protocol (SOAP) are the enabling technologies for SOA, since they're platform-independent standards. Consumers can dynamically discover services. Services are interoperable.

Service Directory

Finds Register

Service Consumer

Invokes Service

The basic building block of SOA is the service. A service is a self-contained software module that performs a predetermined task. Services are software components that don't require developers to use a specific underlying technology. SOA promotes application assembly because services can be reused by numerous consumers. Moreover, creating applications that leverage these different technologies has historically been a daunting task. SOA provides a clear solution to these application integration issues by allowing systems to expose their functionality via standardized, interoperable interfaces. Using SOA offers several key advantages. One can Adapt applications to changing technologies. Easily integrate applications with other systems. Leverage existing investments in legacy applications. Quickly and easily create a business process from existing services.

Different Layers for Service-Oriented Applications

Application Services Services Data capture Services Search Services

Reporting Services

Infrastructure Presentation Layer Security Session Facade Layer Logging Service Locator Business Layer Data Layer Error Handling

Workflow services

Presentation Layer This represents the client view of the application. JSPs to be used to represent the client view of the application. JSPs form the view component of the MVC architecture. Client can be presented different views of the same content. Every client request is secured and sent to the application deployed on the J2EE complaint application server. Action servlets of Struts framework acts as central controller for all such requests and forwards the request to Session Facade layer. Session Facade Layer Session facade layer helps in reducing Traffic over the net. This layer provides all middle ware services like Transaction, security and resource pooling. This layer forwards the request to business layer .EJB component is used to represent this layer. Business Layer Every business rule is written in this layer. Business rule is selected based on the incoming request and data required to process the request is fetched using data layer.

Data Layer Logic to access data is embedded in this layer. This layer is represented by Data Access Objects (DAO). DAO fetches or saves or deletes data in DB2 database using appropriate drivers. Application Services Proposed application architecture incorporates all application related services like data capture, search, work flow and reporting. Infrastructure services Architecture incorporates all essential infrastructure services like security, logging, error handling and service locator. Stakeholders need to access the application using proper authorization and authentication. One-way encryption is used to store passwords. Log4J/Server logs are configured for all logging requirements. All system level and application level errors are handled. Service locator provides the service of locating resources like EJB and data source.

Features of SOA Technology Independence: The Consumer of a Service component is completely independent of the technology of the Provider component and vice-versa. Life-cycle Independence: Each of the Provider and Consumer Service components will be able to operate in a separate life- cycle. Loose Coupling: The Service Consumer Component will define its specification independent of the Service Provider Component. The responsibility of aligning the two specifications is up to the Assembler component, which bridges the gap between two worlds. Invokable interfaces: The Service interfaces will be invokable either locally or remotely. At the architecture level, we dont really care how the interface is invoked. Communication Protocol: A Service will be invokable by variety of protocol. The choice of protocol will not restrict the behaviour of the Service. Binding to a specific protocol must take place at run-time/deployment-time, and not at the design or development time.

Interoperability is the most important principle of SOA. This can be realized through the use of web services, which allows different distributed web services to run on a variety of

software platforms and hardware architectures. The Java programming language represents the ideal platform for developing portable and interoperable web services. Interoperability and portability start with the standard specifications themselves. TheJ2EE 1.4 and Java WSDP 1.5 platforms include the technologies that support SOAP, WSDL, UDDI, and ebXML. This core set of specifications which are used to describe, publish, enable discovery, and invoke web services are based on XML and XML Schema. The J2EE1.4 and Java WSDP 1.5 platforms ensure that applications are portable across J2EE implementations and also that web services are interoperable. The Enterprise Service Bus (ESB) is an important part of an SOA infrastructure, since it provides a standards-based messaging layer with capabilities for services virtualization. ESB is the backbone of SOA that acts as a message broker providing a message queuing system using industry standard specifications for messaging such as SOAP, or JMS (Java Message Service).

ESB Architecture