Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) solutions are the next evolutionary step in software architectures. SOA is an IT architecture in which functions are defined as independent services with well-defined, invocable interfaces. SOA will enable cost-effective integration as well as bring flexibility to business processes. In line with SOA principles, several standards have been developed and are currently emerging in IT environments. In particular, Web Services technology provides means to publish services in a UDDI registry, describing their interfaces using theWeb Service Description Language (WSDL) and exchanging requests and messages over a network using SOAP protocol. The Business Process Execution Language (BPEL) allows composition of services into complex processes as well as their execution. Although Web services technologies around UDDI, SOAP andWSDL have added a new value to the current IT environments in regards to the integration of distributed software components using web standards, they cover mainly characteristics of syntactic interoperability. With respect to a large number of services that will exist in IT environments in the inter and intra enterprise integration settings based on SOA, the problems of service discovery or selection of the best services conforming users needs, as well as resolving heterogeneity in services capabilities and interfaces will again be a lengthy and costly process. For this reason, machine processable semantics should be used for describing services in order to allow total or partial automation of tasks such as discovery, selection, composition, mediation, invocation and monitoring of services.

While Web services and SOA are usually thought to be synonymous, they are not. It should be made clear that Web services are an important tool and one implementation method for SOA, but there are other patterns that may be more appropriate for any given use-case.

In general, SOA can be thought to consist of service providers and service consumers. The providers define what the service looks like and how to invoke it through an implementation independent service interface. The consumers use this interface to construct the necessary data and invoke the service.

An optional construct is the introduction of a discovery mechanism that acts as an intermediary to which providers publish the service interface and from which consumers discover it. This is useful for enterprises with many services, but is not covered in this specification.

One of the keys to SOA is defining the correct level of granularity. This is a fairly subjective thing, but generally speaking services exposed to other systems should provide operations that correspond to business functions. This does not mean that all services are coarse grained. Finely grained component services may be used by business services, but would not be exposed to other systems.

SOA's communication capabilities may be as basic as the ability to pass data along to another service, or as complex as coordinating events between other services and the consumer of those services through some underlying connection methodology, usually Web Services.

The term “service” refers to any self-contained function capable of operating regardless of the state of other services that it may be connected to or communicates with.

Although SOA is a hot IT term these days, the actual concept of providing SOA functionality can be traced back as far as early DCOM and Object Request Brokers (ORB) that followed CORBA specifications.

Code Mobility. The ability to lookup and dynamically bind to a service means that services can be located on different servers than the ones that the consumers are hosted on. This provides the organization with the ability to build enterprise- wide solutions hosted in diverse locations both within and outside of the organization.

Better Usage of IT Talent. Because the SOA environment uses multiple layers, the organization can assign developers with specific skill sets to work within specific layers. This provides a means to deploy the most qualified people to work in specific roles without regard to the technical skills required to support development within other layers.

Enhanced Security. The existence of the SOA service layers result in the creation of additional network interfaces capable of being accessed by multiple applications. In a client-server environment, security is addressed solely at the application’s entry point, and vulnerabilities often exist in areas such as databases due to the difficulty in maintaining multiple security lists. By their very nature, services have built-in security mechanisms that allow for multi-level security at the service and the client levels.

Ease of Testing and Reduced Defects. Because services have published interfaces, unit tests can be easily written to validate performance before the services are exposed to the consumers. This provides a way to identify and correct defects before the actual application undergoes the QA testing process.

Support for Multiple Client Types. The SOA allows diverse client types top access the services using their native communication capabilities including HTML, XML, RMI, etc.

The advantage of reusing or sharing component services is considerable. It would reduce the purchase and development of
redundant systems. Currently, each application development group in the department must figure out the security and develop a log-in system for their applications. Instead, they could use a well-tested service.
If a business process changes, applications in an SOA can adapt quickly by just changing the component services that are affected.
For instance, if the state chooses a different vendor for credit card transactions, all that needs to be changed is the credit card service.
Moving toward a service-oriented architecture will allow MDH to share expensive software components, reduce the redundant development of many common components, and become more flexible and adaptable to meet the expected changes in health related information technology.

A SOAprovides the implementation patterns required to construct applications from loosely coupled services. In order to build such applications, an
implementation environment should provide the following capabilities:

Application Development: Big changes will be needed in methods, coordination, organization, and training of MDH application developers. A thorough analysis of MDH business processes is needed.
Operational Efficiency: Continue moving toward standards in our operations and tools. Further automation of desktop administration and help desk should be accomplished.
Continuity of Operations Planning: Work toward standard platforms. Supporting a redundant recovery site will be too expensive if we must replicate diverse servers and operating systems.
SOA Policies and Processes: SOA will require new security and service use policies and procedures.
Architecture Review Board: We propose that an architecture review board be created to guide the development of policies, update the architecture, and review requests for exceptions.