|
The Service Oriented Architecture
(SOA) has grown from the evolution
of computing standards that allow
for reliable communications
transports, message structures,
security and common process
invocation.
Common communications started
with the adoption of TCP/IP, which
was then built on to provide
higher-level communication stacks
from HTTP to the evolution of
messaging systems embodying JMS.
These standards provide for the
distribution of messages specific
and generalised routes, and allow
for the guaranteed delivery of
transaction critical data.
The messages being delivered over
the pervasive communications
infrastructures have been
standardised using XML as the basic
language for describing the message
content. Various grammars have been
developed to standardise the XML
into models, creating a common
mechanism for application
communications.
Standardised security models and
the use of strong encryption
algorithms with public and private
keys allow for the certification of
the data delivery, ensuring that the
data delivered is the data that
was originated and that sensitive
transactions are not intercepted
during transmission.
Data delivered in an
understandable format using reliable
communications protocols was a major
step towards solving the integration
problem. The evolution of services
(SOAP 1.1) allowed the operations of
the data to be carried out without
regard to the mechanism that was
actually being used to deliver the
service. This meant that one
application could call a service
without regard to how it was
written. The bundling of simple
granular services into more
coarse-grained services allows for
the building of complex business
processes and data.
In April 2006 The Object
Management Group's SOA Special
Interest Group adopted the following
definition for Service Oriented
Architecture. SOA is an
architectural style for a community
of providers and consumers of
services to achieve mutual value,
that; allows participants in the
communities to work together with
minimal co-dependence or technology
dependence, specifies the contracts
to which organisations, people and
technologies must adhere in order to
participate in the community,
provides for business value and
business processes to be realised by
the community and allows for a
variety of technologies to be used
to facilitate interactions within
the community. In March 2006 the
OASIS group SOA Reference Model
released its first public review
draft.
Each application to be integrated
within a SOA is associated with a
Logical Adapter that sits between
the application and the Enterprise
Service Bus (ESB). The Logical
Adapter implements semantic and
integration logic to ensure that
messages are understood both by
consumers on ESB and by the attached
system. Components will put messages
onto the ESB, and consume messages
from the ESB via the adapters,
typically messages on the ESB will
comply with a Common Data Model (CDM)
format. All the service components
exposing functionalities via this
SOA, such as general business logic
and procedures are encapsulated
within Business Process components.
Lonispace recommends a 4 step process that aids organisations in getting the most from their intended
deployments:
- 1. Architect, Design and Implement your ESB
- 2. Design and Implement your Virtual Data Model for the ESB
- 3. Design and implement your Business Processes and Orchestrations
- 4. Design and Implement your Collaboration and user interfaces
|
