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 SOA provides 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.
more from Wikipedia http://en.wikipedia.org/wiki/Service-oriented_architecture
more from Youtube www.youtube.com/watch?v=sbd_1G8Kqjs