SOA for the Enterprise

How can I support automated business processes and increase operational visibility?
How can I connect applications in a cost-effective yet durable way?
How can I leverage existing IT investments?
How can I increase IT flexibility to adapt to changing business requirements?

These are just some of the long-standing IT dilemmas. Historically, applications and systems have suffered from too much rigidity: it's simply too hard to change things once they've been built. While this is problematic for stand-alone applications, it's often catastrophic for large-scale business systems.

Today, service-oriented architecture provides the opportunity to achieve broad-scale interoperability while offering the flexibility to continually adapt technology to business requirements. No small feat, particularly when you consider the extent and complexity of today's IT environments.

The benefits of the SOA Enterprise include:

• Broad-scale application connectivity and interoperability.
• Easier alignment of IT around the needs of the business, representing applications and systems as a set of modular, reusable business components which can be flexibly joined together to form automated business processes.
• Enhanced reuse of existing applications and data, minimizing custom software development.
• Reduced application integration costs.
• Reduced vendor lock-in and switching costs.

SOA is as significant an IT transition as the move to GUI, client/server, or object-oriented computing. Industry veterans recognize that the concepts underlying service-oriented architecture are not new, and that today's SOA represents a powerful summation of technology approaches that have been refined over the last two decades.

Providing a uniform means of connecting systems is simple in theory, but has been difficult to achieve in practice. Driven by new Internet-based standards and protocols (Web services), we now have the interoperability and concentrated community effort needed to make ubiquitous SOA possible. Broad awareness and ubiquity of Web services standards have catalyzed the adoption of standards-based SOA. Today's Web services allow deployment of service implementations on arbitrary platforms, offering interoperability between new and legacy systems and confidence in the ability to support future technologies.

The W3C Web Services Architecture Working Group defines SOA as, "a form of distributed systems architecture that is typically characterized by the following properties:

• Logical view: The service is an abstracted, logical view of actual programs, databases, business processes, etc., defined in terms of what it does, typically carrying out a business-level operation.
  
  
• Message orientation: The service is formally defined in terms of the messages exchanged between provider agents and requester agents, and not the properties of the agents themselves.
  
  
• Description orientation: A service is described by machine-processable meta data.
  
  
• Granularity: Services tend to use a small number of operations with relatively large and complex messages.
  
  
• Network orientation: Services tend to be oriented toward use over a network, though this is not an absolute requirement.
  
  
• Platform neutral: Messages are sent in a platform-neutral, standardized format delivered through the interfaces."

Web services are by far the most broadly accepted and important standards today for representing services for lookup and communication. Web services provide a uniform service model and description (Web Services Description Language or WSDL), a common service registry (Universal Description, Discovery, and Integration, or UDDI), and service invocation (Simple Object Access Protocol or SOAP).

SOA: A Model to Bind Services Together

In addition to providing interfaces for applications to expose their functionality, SOA must also consider the architecture that binds services together. Web services specifies two primary service models: client/server and event-driven. Client/server (or RPC-style) services tightly bind the client application to the API exposed by the server. In this case, the contract is the API and interaction is typically synchronous. In the event-driven model, the service responds to incoming messages and emites messages in response. Here, the contract is the message and interaction is typically asynchronous.

There are many benefits to the event-driven model and compelling reasons to prefer it to the client/server model for SOA. The event-driven model is loosely-coupled, offering greater flexibility by minimizing dependencies between applications. It is much easier to deal with new message versions containing additional fields than with the ripple effect of changing fine-grained application interfaces. In the latter case, a simple change can break a whole chain of calling applications. Messages provide much more insulation between the conversing applications.

For a service to be successful, it must be readily understood by people other than the original developer. In an event-driven interface model, the interface is typically a self-describing XML business document rather than a literal representation of an application's object architecture. Understanding and processing a self-describing document is significantly easier for a service consumer than deciphering a number of fine-grained objects, methods and their meanings.

Finally, asynchronous messaging provides the opportunity for greater efficiencies of parallel processing of event streams, and offers resiliency if a particular service in a complex system becomes temporarily unavailable. Event-driven interactions de-couple the invocation of a service from the production of a result. Applications don't wait for a response from other applications as in the RPC model, but react to events whenever they come in. Event-driven architectures based on messaging also benefit from the resiliency provided by the messaging infrastructure, naturally insulating applications from system and network outages.

SOA Infrastructure

As Web services support becomes ubiquitous among applications and application development platforms, attention is turning to the issue of bringing them together into a coherent whole. How should I think about the relationships between services? How will I connect them across my business? How will I orchestrate interactions across them? How will I manage and monitor them? How will I secure them? These questions point to the need for SOA infrastructure beyond the application platforms which provide the services themselves.

The goal of an enterprise SOA is to build a flexible and durable infrastructure that makes it easy to bridge any set of applications at any time to solve business challenges. The SOA must make it possible to dynamically add and re-configure services on the fly, as well as to alter the logical flow between services as business processes change.

To support the goals of service orientation, SOA infrastructure must support:

• Flexibility: Must allow organization to change processes and relationships between applications through configuration instead of coding.
  
  
• Heterogeneity: Must span new service-enabled applications as well as existing applications, while providing a consistent service model.
  
  
• Distributed deployment: Services will be spread across an organization and between organizations.
  
  
• Management: Infrastructure must be able to manage and monitor itself, as well as the services deployed within it.

These requirements are directly addressed by an enterprise service bus (ESB), a pre-built SOA infrastructure offering enterprise-grade capabilities. It is generalized to support a wide variety of integration project types, implements and reinforces architectural best practices, and is suitable for individual projects yet scales on a global basis.

Related Topics

• Application Integration Patterns with SOA
• Enterprise Service Bus
• Web Service and an ESB
• Enterprise Application Integration
• Enterprise Messaging
• Semantic Integration
• SOA Management

You may also be interested in:

• Sonic Resource Center
• SOA Insights
• Sonic ESB Product Family
• Webinars
• Partner Programs