I liked the approach presented in this IBM article
Service-oriented modeling and architecture 09 Nov 2004
Here are the layers proposed:
Layer 1: Operational systems layer. This consists of existing custom built applications, otherwise called legacy systems, including existing CRM and ERP packaged applications, and older
object-oriented system implementations, as well as business
intelligence applications. The composite layered architecture of an SOA
can leverage existing systems and integrate them using service-oriented
integration techniques.
Layer 2: Enterprise components layer.
This is the layer of enterprise components that are responsible for
realizing functionality and maintaining the QoS of the exposed
services. These special components are a managed, governed set of
enterprise assets that are funded at the enterprise or the business
unit level. As enterprise-scale assets, they are responsible for
ensuring conformance to SLAs through the application of architectural
best practices. This layer typically uses container-based technologies
such as application servers to implement the components, workload
management, high-availability, and load balancing.
Layer 3: Services layer. The services the business chooses to fund and expose reside in this layer. They can be discovered
or be statically bound and then invoked, or possibly, choreographed
into a composite service. This service exposure layer also provides for
the mechanism to take enterprise scale components, business unit
specific components, and in some cases, project-specific components,
and externalizes a subset of their interfaces in the form of service
descriptions. Thus, the enterprise components provide service
realization at runtime using the functionality provided by their
interfaces. The interfaces get exported out as service descriptions in
this layer, where they are exposed for use. They can exist in isolation
or as a composite service.
Level 4: Business process composition or choreography layer.
Compositions and choreographies of services exposed in Layer 3 are
defined in this layer. Services are bundled into a flow through
orchestration or choreography, and thus act together as a single
application. These applications support specific use cases and business
processes. Here, visual flow composition tools, such as IBM® WebSphere®
Business Integration Modeler or Websphere Application Developer
Integration Edition, can be used for the design of application flow.
Layer 5: Access or presentation layer.
Although this layer is usually out of scope for discussions around a
SOA, it is gradually becoming more relevant. I depict it here because
there is an increasing convergence of standards, such as Web Services
for Remote Portlets Version 2.0 and other technologies, that seek to
leverage Web services at the application interface or presentation
level. You can think of it as a future layer that you need to take into
account for future solutions. It is also important to note that SOA
decouples the user interface from the components, and that you
ultimately need to provide an end-to-end solution from an access
channel to a service or composition of services.
Level 6: Integration (ESB).
This layer enables the integration of services through the introduction
of a reliable set of capabilities, such as intelligent routing,
protocol mediation, and other transformation mechanisms, often
described as the ESB (see Resources).
Web Services Description Language (WSDL) specifies a binding, which
implies a location where the service is provided. On the other hand, an
ESB provides a location independent mechanism for integration.
Level 7: QoS.
This layer provides the capabilities required to monitor, manage, and
maintain QoS such as security, performance, and availability. This is a
background process through sense-and-respond mechanisms and tools that
monitor the health of SOA applications, including the all important
standards implementations of WS-Management and other relevant protocols
and standards that implement quality of service for a SOA.
Recent Comments