Soa
Soa
Introduction:
Service oriented architecture provides set of principles and methodologies which are used to develop or to design the software in form of interoperable services. Usually soa implemented in the phases of system development and integration Soa can also be defined as software that changes frequently should be decoupled from software that changes infrequently. When it is applied to the information management of an enterprise, it is called SOA. Evolution of soa is due to distributed computing based on request and reply design for an synchronous and asynchronous applications . An application's business logic or individual functions are modularized and presented as services for consumer/client applications In recent times, more and more organizations are implementing IT systems across different departments. The challenge is to find a solution that is extendible, flexible and fits well with the existing legacy systems. Replacing legacy systems to cope with the new architecture is not only costly but also introduces risk of malfunctioning. In this context, the traditional software architectures proves ineffective in providing the right level of cost effective and extendible Information systems across the organization boundaries. Service Oriented Architecture (S0A) provides a relatively cheap and more costeffective solution addressing these problems and challenges. In soa the service interface is independent of the implementation by this Application developer 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.
Need of soa:
One important factor in implementing a new model of Software Architecture is the everchanging business model. Modern day business constantly needs to adapt to new customer bases. The ability to quickly adapt to the new customer base and new business partners is the key to success. Sharing IT systems with other organizations is a new trend in the business. For example, businesses like online auctions are opening their systems to third party organization in an effort to better reach their customer base. In this context, Service Oriented Architecture offers benefit and cost-effectiveness to the business. The process of adapting to the changing business model is not an easy task. There are many legacy systems, which are difficult to make available to the new business partners. These legacy systems might need to change to support the new business functions and integrate to the newly developed IT systems or integrate to the IT systems of its partners'. The complexity of the whole thing is what makes it a constant challenge to organizations. Services are defined as a set of well-defined interfaces, which are generic in nature. Services also define a schema for the input to be supplied to the Service by its consumer. The inherent nature of SOA is that Services work with an extendible Schema and thereby can cope with various different types of entities that the Service is dealing with
Implementation of soa:
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, 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.
Objectives 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 should be able to operate in a separate life- cycle. Loose Coupling: The Service Consumer Component must 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 must be invokable either locally or remotely. At the architecture level, we dont really care how the interface is invoked.
Communication Protocol: A Service must be invokable by variety of protocol. The choice of protocol must 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.
SOA IS NOT WEB SERVICES 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
Service Oriented Loosely coupled Event driven Aligned with life cycle support processes They offer business services across the platforms Authentication and authorization at every level