ESB Book - New Cover

The book "Modern ESB Architecture for SOA" I am writing together with Mark and Arnaud now has a new and final cover.

SOA Forum 2009 is history

On Wednesday the SOA Forum 2009 (http://www.soa-forum.ch) came to an end. We had a spectacular crowd of 175 attendants. Below are the slides that I presented in Track 2 together with Martin Kräuchi:

End-of-time Prophecies on Middleware, SOA, ESB and else

When Nostradamus pronounced and published his famous prophecies in the 16th century he did not need to worry about target consumer categories. His predictions - some of them interpreted as end-of-time prophecies or just plagues, earthquakes, etc. - where all-encompassing. Unfortunately, none of his writing was ever interpreted as predicting an event before it actually ocurred. :-)

So, what about those target consumer categories? I came across these when reading an excellent article by Steve Vinoski with the title "Is Middleware Dead? (IEEE Internet Computing, vol. 8, no. 4, 2004, pp. 94-96). This article is also about predictions -- in the technology and market domain this time.

Steve Vinoski wrote this article in response to "The End of Middleware", where Jonathan Schwartz of Sun touted middleware to be dead. The assumption behind this pronounciation: everybody would use Sun's Java Enterprise System then there would be no need to integrate with other middlewares. Of course, it did not pan out this way.

Similar pronouncements about the death of CORBA, SOA, ESB and many other technologies have been made. Steve points out that such predictions frequently do not take the target consumer category into account. According to Crossing the Chasm, there are five such categories in a technology adoption lifecycle (- innovators, - early adopters, - early majority, - late majority, - laggards).

When an "early adopter" feels that a certain technology is dead -- it may be alive and kicking from the point of view of the "laggard". One-size-fits-all solutions are therefore impossible. Where are ESBs on that adoption bell curve? Pretty much at (or slightly after) the peak, I'd say.

Stateful vs. Stateless Services

From a runtime point of view it is advantageous to have stateless services. Statelessness - from a conceptual point of view -- means that the service does not "remember" state between consecutive invocations. Of course, the service may still store information in the DB backend. The important point, however, is that this state is not within the service instance or the service volatile memory.

Clearly, stateless services do scale better: Additional instances of the service can be fired up to cope with increased load. They can also deal better with failover situations. A client request may be routed to an alternative instance transparently when the original instance goes down.

However, sometimes stateful services do make sense from a modelling perspective. Nicolai Josuttis, for example, describes a shopping cart service. For this type of service, a client would expect to successively call operations to add new items.

A stateful service may be implemented as a stateless service: either by sending all relevant information (eg the shopping cart contents) with every request or by sending a session ID with every request and keeping the shopping cart contents in the DB. Or a "real" stateful service keeps the shopping cart state in memory - this requires session affinity: ie, each successive request by a given client must be routed to the same service instance. When this instance goes down, the user must start their shopping trip all over again -- possibly an acceptable tradeoff in an eCommerce application. Nicolai Josuttis works out the associated tradeoffs (state in frontend, state in service, state in backend) really nicely in his book (p.195).

Oracle aims for a Slice of Cake

Frank Martin of Oracle quipped that after the takeover of Sun, Planets and Moon might follow soon. Meanwhile, The Economist had another very good high-level story about the Sun takeover by Oracle titled "Mr Ellison helps himself". Great analysis with the conclusion that our industry is going from horizonal/modular to vertical/integrated with the Sun acquisition being just one indicator of the overall trend. The cake (market) is more segmented into slices than into layers. This has significant repercussions regarding the IT value chain that all players wil need to adapt to.

Message-Driven SOA = Robustness

I love Bill Poole's blog - In a post last year, Bill describes a service model that is built around cohesive business areas/capabilities and along the following principles: large grain services; asynchronous reliable communication; no centralized data; no cross-service transactions.

In the past I've worked as architect on an eGovernment project that followed just these same architectural principles. That was by design and also by necessity -- since the underlying product (SonicESB) naturally guided developers into modelling services as entities with a purely message-oriented interface (of course, that was putting the horse before the cart). Services in SonicESB aren't really services in the conventional sense -- they are written against an API and can communicate with other Sonic services only using that API. The API binds onto a JMS abstraction layer that exercises the underlying MOM implementation. However, some queues that drive services may be exposed via Web service interfaces to the external world. Sonic also offers a light-weight process construct: itinerary-based routing includes a routing slip with every message and describes which queues/services must be traversed in what order.

The project team really bought into the benefits of temporal decoupling and came to see it as godsend -- they also came to accept the unusual asynchronous communication style that goes with it.

• individual service may be taken down for maintenance without negatively affecting the rest of the system -- messages simply get buffered until the service comes up again
• as a corollary to the above: services do not need to handle peak loads -- just the average load. When bursts of messages arrive they are simply backlogged in the queue until the service can process them.
• non-blocking for the message producer: fire-and-forget with reliable messages; producers "know" that messages eventually arrive - SLA of the recipient is can help in giving a deterministic timeframe
• monitoring of queues: analyze queue utilization over time; detect usage patterns and adapt to and/or predict load situations;
• inspection of in-flight messages: analysis of messages; remove and store individual messages; replay them at a later stage (or for testing); isolate poison messages and use them for failure analysis

While this particular system was built on top of Sonic, the general principles can be carried over onto any technology that supports reliable asynchronous messaging. Examples are JMS, AMQP, XMPP, WS-Notification, and others. The problem here is: how do you schema-describe your messages? This can be done by out-of-bounds mechanisms, albeit unsatisfactorily.

Virtualization at the Endpoint?

Aaron Skonnard describes the Microsoft Managed Services Engine (MSE) over at MSDN.

Service virtualization is nothing new, of course - it's a pattern that underlies most SOA middleware products (ESBs) and agents (Actional, AmberPoint,..). Hosting platforms (WCF, App Servers) also provide rudimentary virtualization on top of the business logic.

The strength of virtualization lies in its power to isolate consumer and provider and decouple them -- more so than what would be possible if they interacted directly (somebody once said - not without irony - that "any problem can be solved by another layer of indirection" - was it an R. Johnson?). This shields a service developer from the requirements of the consumer and allows her to focus on business logic -- rather than getting multiple stakeholders to agree on the non-functional aspects of the service interface.

ESBs place service virtualization "in the middle" - the MSE that Aaron Skonnard describes places it at the endpoint. Endpoint-based virtualization is becoming a new trend. WCF does it and some other containers - to a limited degree. Some LOB packaged applications start to offer this functionality at the endpoint (e.g., Siebel with the inclusion of Fusion Middleware). This is also in support of pure SOAP architectures that describe the enterprise as just a collection of SOAP-speaking endpoints (with reliability, security, etc. all being controlled through WS* protocols).

Virtualization at the endpoint, however, is not equivalent to virtualization in the middle. It limits you to those aspects of a communication that occur -- well, at the endpoint -- just before hitting the business logic. All aspects that are more centralized conceptually, are more difficult to address. Think about location transparency, for example. If this aspect is implemented on a central, shared intermediation layer it is simple to move backend service providers to new locations. If there is no such infrastructure, then every consumer must be able to directly address the provider endpoint. Either you configure these addresses in peer-to-peer fashion (which is a mess) or you do some kind of lookup: this could be via DNS (only works with HTTP), a registry or a centralized resolver service. The two latter solutions require that the consumer endpoint (either the stack or the business logic) handles the address resolution.

Then, think about content-based routing -- and things get more difficult. This would be a functionality that the consumer endpoint would provide -- or an intermediate infrastructure service. Other examples for virtualization/intermediation requirements taht map more easily onto a (conceptuall) centralized implementation, rather than onto a set of distributed smart endpoints:

• messaging patterns (pub/sub, reliable, async) - reliable queueing can be done at the endpoint but it's a maintenance nightmare (think trapped messages, poison messages, ...)
  
• complex event processing - for correlation/pattern detection, all events must be brought together at the event correlation engine for the application of rules
  
• message routing (addressing, CBR) - as mentioned above
  
• layered security defense - combination of multiple security mechanisms where threats are filtered out at multiple policy enforcement points (PEP) along the communication path
  
• control point for runtime governance (can you really rely on your distributed containers?) - to some degree, since you can monitor messages in progress, but not the availability of services that are not in use
• Provididing multiple interfaces to different clients at different network locations - maybe you only want to make a certain "engineered" interface (different operations, different policies) available to another department, DMZ-external, etc.

The following diagram gives a conceptual idea of where intermediation/virtualization can take place when looking at the consumer-provider communication path:

Developer Summit 2009 - Stockholm

I'll be speaking together with Herbjörn Wilhelmsen at the Developer Summit 2009 in Stockholm about How to Survive the Bermuda Triangle of Legacy, Services and ESB.
Developer Summit, Scandinavia’s leading developer conference is turning 5 years! This year 40 sessions on 6 tracks, key-notes and workshops are planned.

SOA Forum Schweiz 2009

The SOA Forum 2009 will take place May 12-13 in Zurich Sihlcity's cinema mediaplex. The motto this year: "Beyond the hype and theoretical discussions. Use SOA right – succeed in practice”.

Be sure to mark the date in your calendars! We'll have some really interesting and controversial keynote speakers at the start this year - wrapped up with a panel discussion.

• Thomas Erl: "Next Generation SOA"
• Anne Thomas Manes (Burton): “What Becomes of SOA During Though Economic Times?”
• Michael von Uechtritz (Gartner): final keynote

I'll do a talk on mediation strategies in SOA and have a look at a SOA reference architecture.

SOA-ESB book page & interview

Thanks to Thomas Erl for just setting up this brand-new page on the upcoming ESB Architecture for SOA book. There is an associated audio podcast on InformIT where Joe McKendrick interviews Mark Little and myself about some of the ESB-related patterns that made it into the SOA design patterns book.

SOA Design Patterns book released

The SOA Design Patterns book is now released. Mark has the details.

Zotero

In the past I've used various bibliography tools, such as EndNote (when on Word) and BibTex (when on LaTeX). Eventually, however, I've found bibliography heaven - a tool called Zotero. It's free, open-source and integrates nicely with Firefox. The more I use it the more I come to like it.

Steve Jones on the Business Service Bus (BSB)

I've read the post about Business Service Buses (BSB) by Steve Jones and the associated GoogleDoc with interest. Steve describes how a enterprise-wide BSB mediates multiple lowever-level and more domain-specific buses (DSB). I've seen such a model (I call it "hierarchical ESB topology") used in practice by at least one client.

pro arguments:

• divide and conquer philosophy: hide and package structural complexity, only expose services to the upper level that are required there -- hide domain-internal services
  
• the bus infrastructure effectively models the organizational structure
  
• distributed governance -- i.e., each business unit can manage and control governance according to its particular requirements (also see the IBM article Choose an ESB topology to fit your business model)
  

cons:

• extra complexity ("middleware for your middleware")
• heterogeneous technology mix - leads to duplicate license costs, operational & maintenance costs
  

An alternative?
An alternative to the hierarchical ESB topology that Steve proposes would be the "intermediary layer" pattern: Only the business-unit or domain-specific services are encapsulated by an ESB or other type of intermediation layer (legacy wrappers or adapters, domain-specific intermediation services, XML appliances, etc.). This intermediation layer is necessary so that a standard SOAP + WS* protocol can be exposed to the upper level.

Instead of using the BSB one would then rely on the SOAP stack plus the advanced WS-standards to govern the reliability, security, availability, location, routing and other non-functional aspects of the message exchange. The endpoints exposed by the different intermediary layers would also need to agree on messaging patterns and on data formats (see www.soapatterns.org: canonical schema (158)).

I've modified Steve's diagram and replaced the BS with "SOAP and WS*" so that it looks like this:



Now I'd be really curious: what are the pros and cons of this alternative model compared to the original hierarchical topology pattern?