Today, I’m going to take a look at SOA (Service-Oriented Architecture) from a different angle that is often overlooked. SOA governance is sometimes an after thought, though critical to the enterprise.
SOA governance is best defined by Anne Thomas Manes as: “The processes that an enterprise puts in place to ensure that things are done … in accordance with best practices, architectural principles, government regulations, laws, and other determining factors. SOA governance refers to the processes used to govern adoption and implementation of SOA.”
One of the risks that emerge as more and more applications become integrated is the spreading of bad data (e.g. invalid, incomplete, etc.). Misinformation and bad data constantly challenge organizations today. Engaging in SOA activities without consideration for governance is like opening up a four lane highway with no cops to patrol it. Controlling life cycles and versioning, governing people, policies, design-time, run-time and processes to establish and maintain desired behavior are examples of SOA governance. Continue reading →
There are a number of blogs, discussion groups, podcasts, etc. talking about Service-oriented Architecture (SOA) and Service-oriented Integration (SOI). Instead of focusing on them individually, this blog focuses on using them together for better ROI results.
Service-oriented Integration (SOI) is the practice of using XML over HTTP (e.g. Web Services) to achieve interoperability between applications and services – for example, wrapping a legacy application function and exposing it to other applications, services, and business partners. Service-oriented architecture (SOA) encompasses architecture principles and best practices that guide the design and implementation of SOI, including methods that minimize coupling, complexity, and functional overlap. Most SOA initiatives start with the need to integrate an application; I believe the reason why companies fail and overspend on SOA initiatives is due to the lack of consideration for SOI and SOA together.
Enterprise Service Busses (ESBs) have become a popular communication mechanism in middleware infrastructures, allowing organizations to implement messaging systems that facilitate collaboration among disparate applications and software services. All communication between components takes place via messaging on a “bus”, removing direct contact and introducing a loosely-coupled architecture into the infrastructure. Messages are published to the bus and received by subscribing to the bus. To avoid all of the messages swirling around in one large pool, the concept of topics (sometimes referred to as channels or queues) provides a degree of separation.
To make messaging effective in this design, a common messaging model must define the messages both sent and received by the ESB. These models usually include specifications for the payload of the message and any control information that is passed along. Messages can be data-centric, containing a payload, or command-level where processing instructions can be carried, such as starting/stopping a service.
ESBs also make an effective core data transport for Service-Oriented Architectures (SOA), although they are not required to implement an SOA. They are, however, a key part of an Enterprise Integration strategy and leverage many of the Message Exchange Patterns (MEPs) in use today, such as Publish/Subscribe (leveraged in communication protocols), Competing Subscriber (often used in load-balancing schemes) and Idempotent Subscribers (ensuring that you only receive one copy of a message).
The strength of an ESB lies in its ability to send/receive messages, route them based on content, transform them into other formats, and/or publish them to additional channels. The ESB becomes the “hub” of your infrastructure, connecting all of your disparate systems and services, allowing them to communicate in new ways.