Service Oriented Architectural

Services Oriented Architecture (SOA)

SOA defines a paradigm and an architecture in which a group of related software components with an autonomous nature and a high level abstraction that carry out a given business process function, and these components can communicate with each other within the same enterprise, and with other services exposed by other enterprises. SOA is not a replacement for component architecture; rather it neatly complements the component architecture. While component architectures enhance reusability at a finer grain level, SOA can enhance reusability at a coarser grained level. Therefore a given service might very well be developed using well-defined component frameworks such as EJB, CORBA or .NET Remoting.
Service-Oriented Architecture has regained significance at this time because of the emergence of new technologies that are based on open standards that allow disparate systems to communicate in a common fashion.

The principles of SOA require that the services should:

• Have behavior that is clearly defined by a published interface contract.
• Have network addressable interfaces or endpoints.
• Be dynamically discoverable and usable.
• Emphasize interoperability.
Services are offered at a business level of abstraction which renders the interface as a business interface i.e., a contract. The contract is a mechanism that allows systems to be formalized, that is a set of operations semantically in relationship behind an interface, communication policies, pre-conditions and post-conditions for the collaboration such as security context, transactional behavior, session management, etc, and invariants such as policies for interacting with.
One success factor for SOA is providing well-defined contracts with which other systems or applications can interact and significantly decreases the dependency on coding by eliminating the need to know and write to APIs.

Legacy and new applications are "wrapped" using the contracts, and they become provider of some services. The process of wrapping the legacy application into a service abstracts the complexities of individual applications and allows for what is known as "loose coupling" of services.

A SOAP application called Business Process is an orchestration of services, that is to say, it's an interaction semantically related messages between services, which process, transform and routes them to achieve a business goal. There are languages to specify the former orchestrations, such as Business Process Execution Language (BPEL) and XLANG.

An enterprise approach for SOA will seek to restate all business processes as services that communicate with each other and potentially with services outside of the enterprise. An organization will already have a number of systems already in place to support the business. These legacy systems are often disconnected from each other, or if not, then they are often tightly coupled or require manual intervention when communicating with each other. Legacy systems can be brought into SOA by providing "service wrappers" that would wrap around the system exposing the application functionality as services while allowing the existing technology to be reused. Over time, applications can be replaced or re-architected without affecting the entire enterprise so a long as the interface provided by the service wrapper remains enforced.

SOA deployment. Enterprise Service Bus (ESB)
The deployment of a SOA requires the conversion of existing systems into services. The tasks involved in achieving this can be repeated for each system and a common set of components may be needed to provide additional functionality (such as security and auditing). An Enterprise Service Bus (ESB) is a collection of servers and components that provide these functions and a set of tools to assist in the conversion of existing systems to services. All this must be achieved without conflicting with the principals of SOA.

The steps involved can be grouped into three phases:
• Exposing the existing systems as core services.
• Building business services from these core services.
• Using the business services to achieve business process modeling.

Service-Oriented Architecture and Web Services.
Web Services are not inherently service-oriented-they represent a solution to implementing a SOA strategy. Web Services provide a necessary standards-based implementation of SOA wherein services are described using WSDL and accessed via SOAP. So that interoperability across platform, organizational, and network boundaries is feasible. Web Services technologies implemented by the .NET distributed computing model can support such a strategy.
Web Services currently represent the best technology for implementing SOA. The technology stack used in web services maps onto the principles of SOA formerly explained:

• WSDL provides a description of service behavior and the interface contract.
• The HTTP protocol, while not the only protocol available, is the most widely used regardless of the technology platform. It's identified a network service of unique way using the URLs. SOAP provides a platform independent protocol for sending messages across the wire.
• UDDI provides the means to discover the service both at design time and at run time.
• XML is the technology that underpins it all. Since XML is text based, it can be read by virtually any machine on any platform giving a high degree of interoperability. WSDL, UDDI and SOAP are all XML based.

Technologies used by Web Services as support:
• Web Services are invoked using SOAP messages. SOAP, which is defined using XML, is an emerging standard for transmitting messages across the Internet. SOAP facilitates application-to-application interoperation between multiple processing points. SOAP messages contain header information about the communication channel and a body containing the business-oriented content. SOAP messages are often sent within the body of some transport protocol such as HTTP, SMTP or TCP.
• WSDL is an XML-based grammar used to define a contract provided by the Web.
• Service. It uses the XML Schema Definition (XSD) standard to describe message structure and data types, WSDL provides a means to describe the basic format of a Web Service request message or invocation and the format of a subsequent response message from the Web Service. The WSDL file gives the developer of a Web Service consuming application all of the information necessary to achieve this programmatic access to another system-that is, to invoke a Web Service.
• The WSDL gives self-description aspect to the Web Services.
• The UDDI specification provides directories and descriptions of Web Services so that interested parties can locate these services and interact with them. Specifically, the UDDI standard defines a way to provide a universal database or registry of Web Services and links to their associated WSDL files. A Web Service consumer can use a UDDI registry, whether it be a public registry, or an intranet-based private registry, to discover and reference a Web Service provider.
• There are standards and specifications that all major software vendors-including Microsoft, IBM, Oracle, BEA Systems, and many others-have agreed upon. So a Web Service endpoint running on Microsoft.NET could be invoked by another application running on, for example, J2EE, and vice versa.
Early Web Services standards provided for platform-independent messaging over the Internet using SOAP/XML. These standards alone, however, did not address the problem of transmitting messages in a secure and reliable way. Indeed, businesses do not want to send critical or sensitive data over the public Internet in a way that cannot be secured or where there are no guarantees that requests are completed.

The WS-I Basic Profile addresses this need. The WS-I Basic Profile is published by the Web Services Interoperability (WS-I) organization (www.ws-i.org) which works to establish standard specifications to promote Web Services interoperability across platforms, applications, and programming languages.

The WS-I Basic Profile includes what are known as the WS-Specifications, three of which are implemented in the Web Services Enhancements (WSE) which is a .NET class library for building Web Services using the WS-Specifications. WSE implements:
1. WS-Security: a specification for secure Web Service communication using common security technologies (SSL or TLS), including digital signing and encryption.
2. WS-Policy: a specification for Web Services to document, for example, their security requirements using meta-data that augments the WSDL file.
3. WS-Messaging: a specification that defines other means beyond SOAP over HTTP, such as TCP, for communication between Web Service endpoints.
The key benefit of WSE is that it allows the quick implementation of these specifications and relieves the developer from having to code the low-level XML details that would otherwise be required to implement them.

Service oriented architectures have these characteristics:
• Services have strong software contracts.
• Services are encapsulated.
• Messages are documents.
• Services share a message bus.
• Services are loosely coupled.
• Services have a life cycle.
• Systems of services are assembled at runtime.
• Services can be discovered.
• Systems of services can grow into systems of systems.


Services Have Strong Software Contracts
A strong software contract defines the role that the service plays. Services are a realization of software design-by-contract. A service's contract describes what messages a service will receive, what messages a service will send, and what error signals a service will send when things go wrong. In service oriented architecture contracts, hidden state invariants tend to be less important. High-level descriptions of any side effects-- especially changes in exposed internal state--take center stage. The software contract serves as a design guide, test plan, and programmer's interface. Share the service's software contract with people when they ask you what the service does. Use the software contract to help your managers decide which services to build first, to address some immediate needs of your business.
WSDL files include a very precise description of a service's programming interface in a computer-readable format. However, WSDL files are separate from code (so they won't be found) and hard on the eyes (so important details will be missed).

Services Are Encapsulated
Services are encapsulated. A service only exposes the behaviors in its contract. Nothing outside the service can observe internal state and state transitions. How a service fulfills the contract remains hidden. No interesting service can achieve ideal encapsulation; even a service on dedicated hardware will still share limited bandwidth on a network. The best way to handle these details is to add them to the contract; if something that matters to the rest of the system is not in the contract, then the service's contract is incomplete. Fixing bugs in your contract is much easier than fixing encapsulation. Observing and enforcing encapsulation helps prevent creeping complexity growth, a maintenance nightmare.
The goals of encapsulation line up well with the original promise of object oriented programming: keep responsibility localized and defined.
Message Contents Are Atomic Documents
Part of service oriented architecture is document oriented architecture. The contents of the messages that flow in the system are well-defined data structures--like documents. Sending a message effectively makes a copy of a data structure. Once sent, the message can not generally be pulled back and changed. Message data structures need to be complete and compact, and have consistent rules for how to maintain referential integrity. You can easily and directly reference one part of this document data structure from another, but referencing something outside of the structure means extra work with foreign keys.

Services Share a Message Bus
Services communicate with each other by sending messages over a shared message bus. SOA uses messages to avoid the coupling that comes from services sharing a call stack; if the called service fails silently, the calling service has to wait for it to return. Services use messages in three main styles: request/reply, commands, and events. In request/reply, one service sends a request to another, and dedicates resources, usually a thread, to waiting for the reply. This style leads to coupling almost as tight as when sharing a call stack. One service can send another service a command: a fire-and-forget instruction to do something. The command style leads to modest coupling; the commanding service expects some other service to fulfill the command eventually, but does not dedicate any resources to make sure. A service can simply publish events--notifications that something of interest has happened--without depending on any service to receive the message. Event-based systems of services are very loosely coupled, and can scale up to the limit of the message bus. Monitoring the message bus provides great insight into how well the system works, and creates a reassuring picture for your manager.

Services Are Loosely Coupled
Ideally, services only interact by fulfilling their contracts over the message bus. Loose coupling between services makes replacing one service with another possible. When your manager asks what will be involved in integrating a replacement service, you will have a
Services Have Independent Life Cycles
Each service has its own life and life cycle independent of other services. Individual services may be stopped, restarted, and replaced without stopping the whole system. Batching services like end-of-day processes can start, process all pending messages, and stop. A service can join a wireless network briefly, when a connection is available, and then disconnect later without causing harm. You can even replace an obsolete service with a new version without downtime. The feature you want is the ability to stop one service and start another to replace it, without stopping the whole system.

Orchestrators Assemble Services into Systems at Runtime
Orchestrators are special services that gather and assemble services into larger systems at runtime. Some orchestrators match contracts to orchestration instructions to registered services. Orchestrators often start the services they need. Assembling a service this way is a lot like using Simulink blocks; you choose the parts, connect them to a message bus, and sometimes stimulate the system with an initial message. BPEL holds a lot of promise for orchestrating large systems.

Orchestrators Can Discover other Services Dynamically
Services generally register themselves with a service locator. An orchestrator can then use the service locator to find the services it needs dynamically, at runtime. Universal Description, Discovery, and Integration (UDDI) gives us the main support for discovering and binding to web services at run time.

Systems of Services Grow into Systems of Systems
A system composed of services can be a service in its own right. The more that messages are treated like events (instead of requests), the better your system can scale up. Scaling up this way can be the technology jewel in a business plan. To make sure that your system of services can be a service in its own right, make sure the larger system has all of the features that a service should have. The larger system should have a strong service contract, be encapsulated, use atomic messages to communicate, be decoupled from other services, have an independent life cycle, and be discoverable. If all of that is true, a larger-scale orchestrator can use your system as service to assemble something bigger.