This is the fourth and final post in our “SOA: What’s in it for me?” series. This series was in response to a question from a former cohort, Chris, from the old days at a giant semiconductor company:
“Any thoughts on communicating just exactly what SOA is to mixed audience of technical and non-technical folks, and how it will help them?”
I will assume that you have read part 1, part 2, and part 3 of this series on selling SOA to the business, developer, and data folks respectively. Without further ado, the value proposition of SOA with respect to infrastructure.
Infrastructure folks play a pivotal role in a successful SOA implementation. They generally drive selecting intermediaries in the environment, hopefully from a set of requirements from the business, developers, and data folks. In addition to these requirements we recommend these design goals:
- Resilient to changes in message format and service implementation. Optimally no intermediary would be impacted if the message format or service implementation changed.
- Ambivalent to message body. An intermediary should provide value (some sort of capability) without requiring complete understanding of the message being passed. That is to say, an intermediary should be able to parse only the data it needs to perform a particular function and no more. The reason behind this design goal is that it should not be mandatory for the intermediary to interrogate an entire message to provide value; if this were the case the performance would be negatively impacted.
- Scale horizontally and vertically to meet changing demand. Ultimately horizontal scaling occurs because applications outgrow the hardware components (vertical scaling). One way to scale out is by merely duplicating services and leveraging intermediaries to load-balance across those services. While some may label this as poor-man’s scaling it actually has some benefits. First and foremost, it is scaling by leveraging the interoperable layer of the SOA environment, the intermediary, and not a proprietary technology.
If these design goals are not adhered to you may quickly find that your services are not easy to manage, consume, and/or discover. Let’s back up a bit and look at a conceptual scenario to prove some points.
Point-to-Point Web Services
It is very common to see many enterprises already leveraging web services today, but in a point-to-point manner. The visual below represents this straightforward design:
Traditional point-to-point Web Services
In this design, a service consumer (whether it be an web-based application, desktop application, or even another service) communicates directly with a Web service. While this may be a step in the right direction (over monolithic applications), there are certainly issues:
Planning: As enterprise IT shops began delivering consumable services to its application groups, the dependencies among projects routinely became unmanageable. Any one service could potential become a virtual component to hundreds of applications. The logistics of managing priorities, funding, release schedules and deprecation was enormous. As a result a set of disciplines emerged to manage the enterprise as a parent to more independent development groups. Enterprise Architecture(EA) became the vehicle by which an enterprise could develop a vision, produce Business, Data, Application and Technology goals with related architectures; standards and governance and finally an execution plan with funding. This notion made independent development groups accountable to the enterprise and not the other way around. Enterprise Architecture is a very important driver of a healthy approach to SOA and is discussed briefly in the SOA and … section. It is recommended that the reader spend some time familiarizing themselves with enterprise architecture concepts.
Reuse: Certainly progress was being made against the goal of reuse, albeit on a scale short of enterprise class and purely from a technology perspective. However, the unforeseen roadblock revolved around trust issues. While, there was no shortage of early web services available for consumption, resistance to use services that were not built, managed and deployed by the consuming application was common. This resistance is a classic example of the “Not Invented Here” syndrome and inhibited enterprise class reuse in favor of department and/or project level reuse.
- Reuse: in this design certainly progress is being made against the goal of reuse, albeit on a scale short of enterprise class and purely from a technology perspective. Most reuse occurred when a buddy told you about a service they built. Even if the organization had more advanced ways to share services resistance to reuse was still there because they were not built, managed and deployed by the consuming application. This resistance is a classic example of the “Not Invented Here” syndrome and inhibits enterprise class reuse in favor of department and/or project level reuse.
- Standards: early releases of development tools were inconsistent at best with regard to the interpretation of emerging standards, consequently interoperability was rarely achieved without due diligence. Certainly vendors needed to cater to their development environments first and competing environments second and it was evident in early offerings.
- Shared infrastructure: as more and more services came on-line, the need for shared infrastructure (“Landing Zones”) increased both in terms of shared functional capabilities (for examples: monitoring, logging, caching and storage) as well as operational needs like failover and recovery. The traditional idea that development groups build, deploy and maintain their own and only their own, applications in isolation started to fall apart. Enterprise landing zones became required for a healthy approach to reuse and became what is known today as Service-Oriented Infrastructure (SOI).
- Discoverability: as service offerings exploded so did the need for a means to discover such services both at design-time and at run-time. Often was the case, that enterprises had services that were “invisible” to potential consumers simply due to the lack of a services catalog. Or more problematic, services would, without warning, change physical locations on a network breaking its constituents.
- Message patterns: most early web services implemented a synchronous request/reply messaging pattern, as it was consistent with the traditional component calls. That is, a service consumer would call a web service and wait (sometime in a blocking fashion) for the web service response. This pattern requires that a web service must inherit the service level agreements of the consuming application. This approach became unsustainable in a large enterprise and is today tempered with alternate (but symbiotic) asynchronous messaging patterns like Pub/Sub, Topics and Paired Queues.
- Planning: as enterprise IT shops began delivering consumable services to its application groups, the dependencies among projects routinely became unmanageable. Any one service could potential become a virtual component to hundreds of applications. The logistics of managing priorities, funding, release schedules and deprecation was enormous. As a result a set of disciplines emerged to manage the enterprise as a parent to more independent development groups. Enterprise Architecture (EA) became the vehicle by which an enterprise could develop a vision, produce Business, Data, Application and Technology goals with related architectures; standards and governance and finally an execution plan with funding. This notion made independent development groups accountable to the enterprise and not the other way around. Enterprise Architecture is a very important driver of a healthy approach to SOA. It is recommended that the reader spend some time familiarizing themselves with enterprise architecture concepts, which we will cover more in future posts.
As these issues highlight, point-to-point Web services do not help infrastructure folks, rather cause more headaches.
So how does SOA help infrastructure folks?
Now let’s take a look at a SOA design and the value it adds from an infrastructure perspective.
High Level SOA design
In this conceptual diagram we added more elements to the point-to-point Web services example. The key elements being an intermediary and repository/registry. If the design goals mentioned earlier are adhered to, some significant issues in the point-to-point design are eliminated.
- Brokered service calls: the intermediary behaves as a message broker; intercepting and forwarding messages on behalf of the message originator. Usually, this type of intermediary is implemented as a router, agent, appliance or service bus.
- Provide abstraction of (service) endpoints, technology and capabilities: with this design service consumers are not tightly-coupled to the actual service endpoint (and the technology used to create the service), which not only means more flexibility of where the service lives today (and tomorrow), but also allows for common capabilities to be built into the intermediary offering.
- Shared capabilities = Reuse + Agility: the advantage to the more feature rich intermediaries are the ability to interject capabilities like logging, caching and security. Generally speaking, placing common capabilities like logging or caching in an intermediary and not each service means a consistent implementation and execution. This implies that services need not worry about logging or caching (aggregation, transformation, etc.) as any service behind the intermediary receives the behavior for “free” unless specifically required by business and/or regulatory audit requirements. Hopefully, you can see as your SOA becomes more robust, your services can be simplified and reuse increases, all working towards improved agility.
- Enhanced message pattern support: many intermediaries support protocols other than HTTP, such as JMS. Leveraging protocols such as JMS, you can implement event-driven solutions which opens the door wide open for reliable, high performing designs.
- Metadata driven: the green cylinder icon off to the right-side of the intermediary represents a repository/registry. This is another key element to this SOA design as a repository (design-time) makes it easy for potential service consumers to discover available services and intermediaries can leverage a registry (run-time) to appropriately route messages. Additional metadata is stored as well such as SLAs, policies, additional endpoints, etc.
- Dynamic scaling: as mentioned in our intermediary design goals, one way to scale out is by merely duplicating services and leveraging intermediaries to load-balance across those services. While some may label this as poor-man’s scaling it actually has some benefits. First and foremost, it is scaling by leveraging the interoperable layer of the SOA environment, the intermediary, and not a proprietary technology.
Granted, this is only a brief introduction to the value SOA brings to the infrastructure folks, but it should be enough fire power for the nay-sayers. This type of design makes monitoring and management of services much easier for the infrastructure folks, which reduces concerns that development teams often have with services. And in the end, this makes IT much more agile to support the ever evolving business needs.
Again, this four part series is really just a teaser. Bill and I spend months with clients going into much more detail and working with them to actually implement solutions with a wide scope of capabilities. As some people have already commented, we will work on an upcoming post that will walk you through a sample design and implementation of our SOA work.
Print This Post
Tags: Enterprise Architecture, Service Oriented Architecture