Service-oriented architecture implementation framework

Service-oriented architectures (SOA) are based on the notion of software services, which are high-level software components that include web services. Implementation of an SOA requires tools as well as run-time infrastructure software. This is collectively referred to as a service-oriented architecture implementation framework or (SOAIF). The SOAIF envisions a comprehensive framework that provides all the technology that an enterprise might need to build and run an SOA. An SOAIF includes both design-time and run-time capabilities as well as all the software functionality an enterprise needs to build and operate an SOA, including service-oriented:

* tools,
* management,
* integration,
* modeling,
* security,
* processes.

As vendors race to provide possible solutions, three different approaches are emerging to integrating disparate, heterogeneous information and systems in the enterprise. These implementation frameworks should meet the requirements for loosely coupled, coarse grained, asynchronous Services.

__TOC__

Efficiency

Most packaged enterprise applications perform well in streamlining processes related to standard tasks. However, the performance rapidly deteriorates while automating and streamlining customized processes that encompass multiple enterprise applications. The process is difficult, time-consuming, and expensive to implement and maintain.

The SOAIF infrastructure addresses this issue by allowing the definition of any process in any network topology, spanning multiple enterprise boundaries. This is accomplished via a peer-to-peer messaging infrastructure with distributed security mechanisms that allow efficient data exchanges for easy implementation, while enabling each enterprise to enforce its own security policies. This allows an SOAIF to increase operational efficiency across the entire value chain.

Application integration

Existing packaged application integration solutions are complex and require significant implementation effort, often including extensive manual coding for deployment purposes. An SOAIF provides native support for runtime deployment of services across the network and dramatically reduces the overall costs of application integration and deployment by automating these time-consuming processes. It also allows extension of integration across business boundaries.

Application development and deployment

In the traditional software development process, translating requirements into working distributed systems is both time-consuming and difficult, requiring several stages of manual development and deployment. This complex, error-prone task can be effectively streamlined using a higher-level, component-based SOAIF. The SOAIF incorporates tools that let processes that are developed, using standards such as Business Process Execution Language (BPEL), to be easily translated into distributed, high-level services, which are easier to develop, manipulate, and debug. These services are easily composed into implementation-level data flows without the user or developer having to track complex middleware concepts, such as topics or queues. Further, the implementation-level services can run on any machine across the network by virtue of the built-in dynamic deployment support SOAIF provides. The combination of service-oriented tools and built-in support for distributed debugging, run-time tracing and logging, and dynamic deployment allows the SOAIF to dramatically reduce the time taken to implement and deliver working processes.

OAIF requirements

A SOAIF is a general-purpose infrastructure platform that lets developers and business analysts create, deploy, manage, and change processes within and across the enterprise. SOAIFs have unique requirements at both the tools and infrastructure levels that are not typically provided by any single current technology or platform. These include:

* distributed event-enabled architecture,
* flexibility via service-enabled processes,
* enterprise standards support (fault tolerance, reliability, and scalability),
* security in distributed environment,
* visual process composition and monitoring,
* rapid process changes.

By addressing these requirements, an SOAIF lets users quickly respond to changes and integrate operations efficiently, regardless of platform, language, database, or application.

Distributed event-enabled architecture

Enterprise processes are usually distributed across multiple applications and hardware/software systems. These processes are also event-based in the sense that the subprocesses are linked by a series of events. For example, the depletion of inventory at a manufacturer may lead to an event-trigger that is automatically generated and propagated to one or more suppliers to replenish the depleted inventory items.

Most current BPM solutions control the processes through a centralized hub. Changes to applications, or additions of new applications, require modifications at the centralized hub. Further, all data exchanged between applications needs to traverse the central hub. This type of topology restriction is inefficient, inflexible, and leads to bottlenecks. To overcome this limitation, a framework that tries to integrate enterprise processes needs to be fully distributed across the network within the enterprise. The framework must also be symmetric, which implies that the same event-based infrastructure software and tools need to run on all machines within the enterprise.

Enterprise standards support

Support for data exchange, messaging, and existing enterprise standards becomes essential in an SOAIF. Since content needs to be exchanged between partners, XML messages and documents will be the desired format. Further, since most businesses want to leverage existing infrastructures, an SOAIF needs to easily support multiple standards.

Fault tolerance, reliability and scalability

A SOAIF should be able to offer an extremely high degree of reliability. The platform should support a broad range of processes that span an increasing number of applications, corporations, and partners. To eliminate single points of failure and to maximize performance, a fully distributed architecture becomes essential.

ecurity in a distributed environment

A SOAIF needs to be fully distributed for maximum performance and scalability. In such a distributed computing environment, it becomes necessary to restrict the scope of interactions that partners can conduct with the corporate IT infrastructure. It becomes necessary to allow customization for the interactions of each partner by providing different security roles on a per-user and per-service basis. This requires a security model that incorporates users, Web services and more general enterprise services, and that’s fully distributed and fault-tolerant, such as the SOAIF infrastructure itself. This security model needs to be based on existing standards and tools and should support certificate authentication at both the user and services level.

Visual process composition

A SOAIF needs to provide a single dashboard with visibility into an organization’s entire distributed computing environment. The platform should incorporate visual implementation-process-composition tools, together with infrastructure-level support to instantly deploy the modeled implementation-level processes across a distributed enterprise network. The visual composition tools need to be service-oriented in the sense of being able to directly manipulate higher-level, coarse-grained implementation processes as first-class objects. They also should provide both a visual display of programming constructs and be able to map directly (and naturally) to deployable processes.

A critical problem in deploying distributed systems is monitoring and debugging concurrently running processes. An SOAIF should provide native support for tracing, logging, and monitoring any process or service across the distributed environment.

Process changes

Another challenge is responding to changing requirements. A SOAIF should provide support for incremental on-the-fly modification of the service-based flows that implement processes. This is among the most critical features expected from an SOAIF, since it lets analysts visually change and instantly redeploy processes to address dynamic requirements. Such changes are implemented within an SOAIF by abstracting all concepts relating to lower-level middleware at the tools and applications levels.

Users simply specify that a service be replaced by another running service (often on another machine); the SOAIF dynamically reroutes data to the new service by setting up new underlying middleware constructs (such as topics and queues, for example) on-the-fly. This allows the implementation to be changed without stopping the current process in much the same way as hardware is upgraded on a mainframe system without interruption of operations.

OAIF components

Essential elements of an SOAIF include design-time and run-time infrastructure, together with service-oriented tools for deploying distributed processes and implementation flows.

Enterprise service bus

The core infrastructure of an SOAIF is typically provided by an enterprise service bus (ESB), which addresses the challenges in composing, deploying, and managing distributed, service-based enterprise applications. The ESB incorporates a standards-based, enterprise-class messaging backbone, together with enhanced systems connectivity using Web services, Java 2 Enterprise Edition (J2EE), Microsoft .NET, and other standards.

One approach that contributes to an optimal SOA implementation is the use of an Enterprise service bus (ESB) to provide an infrastructural element to distributed Services on the network. The ESB approach to integration considers systems as discrete, distributed Services that connect to each other via an asynchronous, message-oriented communications infrastructure. The message-oriented infrastructure allows loosely coupled, document-oriented exchanges between independent systems.

ESBs provides the critical infrastructure components that simplify and scale integration approaches. ESBs do not however provide the required integration to meet high-level business requirements. ESBs also do not provide guarantees of loose coupling and coarse granularity to meet evolving Service-oriented needs. Implementing ESBs to meet SOA requirements require the addition of extra functionality to compose fine-grained atomic Services into coarse-grained business Services and provide policy-driven, managed, and secure Service interactions.

An ESB links individual enterprises together for extended process efficiency across the supply chain, allowing them to become more flexible and adaptable to rapidly changing requirements. The ESB lets an enterprise leverage its previous investments by supporting the deployment of processes over existing software and hardware infrastructure. As the core, underlying infrastructure of an SOAIF, ESBs offer several unique business and technical advantages:

* support for enterprise standards,
* fault tolerance, scalability, and reliability,
* service-based tools,
* easy process deployment and changes,
* component-level security,
* run-time monitoring, tracing, and logging.

Business process management

Business process management (BPM) considers systems and IT assets as activities or tasks that participate in well-coordinated and centrally orchestrated Business processes. Traditionally, the challenge of BPM is that while it is possible to construct processes that achieve integration goals, enterprises typically use BPM tools only at design time, modeling processes as they used to be or processes as they should be, but rarely processes as they actually are in the IT environment.

So, while BPM solutions can craft orchestrated processes that are composed of fine-grained Services, they don’t contain the runtime environment necessary for loosely coupled, asynchronous Service interactions. At the very least, a BPM solution must be used in conjunction with a loosely-coupled integration approach to make the business processes runtime activities that coordinate integration. Thus, by itself, BPM solutions are not sufficient to meet SOA requirements.

ervice-oriented integration

The service-oriented integration (SOI) approach uses the architectural guiding principles of Services orientation to construct an ecosystem of Services that business users can dynamically combine and compose into higher-level processes that meet continuously evolving and changing business requirements. SOI approaches transcend brittle, tightly-coupled EAI and Business-to-business integration approaches by mandating a separation of the consumer of each Service from the producer of that Service, thus enforcing the critical aspect of loose coupling that is required to allow an integration scenario to evolve automatically to meet business requirements.

SOI provides no guidance on how to build the right Services to meet current business requirements, nor does it provide a means to execute Services in the most effective, scalable manner to guarantee long-running interactions.

Enterprise standards support

ESBs implement standardized interfaces for communication, connectivity, transformation, security, and portability. Supported standards include:

* JMS for communication,
* web services, J2EE, and .NET for connectivity to various systems,
* XSLT and X-query for transformation,
* LDAP, TLS for security.

Modern ESB implementations typically support development in multiple languages. This, combined with the inherently portable ESB infrastructure, makes the ESB a true multi-language, multiplatform enterprise backbone and an ideal foundation for an SOAIF.

Fault tolerance, scalability and reliability

Several modern ESBs implement a symmetric, distributed architecture in which peer-messaging servers run on multiple nodes of an enterprise network, providing a highly scalable, reliable distributed messaging platform with no single point of failure. Modern ESB architectures combine the benefits of centralized control with distributed, parallel data flow, giving application developers the ultimate flexibility in defining the network topology of choice to route data directly and optimally between services.

Ensuring that data flowing between services does not always have to traverse a central point in the network optimizes peer-to-peer network performance. For instance, if one has a process that requires data exchanges between New York and Boston, as well as between San Francisco and Los Angeles, then the two flows of data don’t necessarily have to traverse a messaging hub located in Chicago (which is often the case in most enterprise or cross-enterprise deployments). Instead, efficiency dictates setting up direct data flow connections between peer nodes on a network.

ervice-based tools

Service-oriented tools enable composition of distributed applications from one or more services (Web services and more general enterprise services), each of which typically runs in a separate process. Services may be written in any language and communicate with each other via XML messages. This allows service-oriented tools within an SOAIF to compose flexible, easy-to-modify systems.

Easy process deployment and changes

Service-oriented processes deployed in an SOAIF are composed of "coarse-grained" Web services ideally suited for easy change and replacement. By abstracting the details of message routing from service implementations, service-oriented tools decouple and enable running processes to be modified on-the-fly by simple service replacement or addition. The tools framework within an SOAIF supports the run-time deployment of services, allowing changed processes to be deployed instantly across the network. Our experience is that this significantly reduces solution deployment costs compared with traditional, broker-based solutions.

Component-level security

The ESB defines a comprehensive security system, giving administrators full control over which services are executed where. ESBs provide the ability to set several security attributes for each service and provide administrative tools to configure security settings on the distributed ESB infrastructure across the network.

Run-time monitoring, tracing and logging

ESBs include native service-level support for run-time monitoring, tracing, and logging. All services can be monitored instantly, using visual tools within the SOAIF. Trace levels can be dynamically changed within existing services running across the network and debug logs can be routed to software tools on any node. These features greatly simplify the development, deployment, and debugging of distributed applications running across the SOAIF.

ee also

* Service-oriented modeling