Entries from March 2008 ↓

WS-* vs REST (ack)

There’s a lot of interesting bloodletting debate going on about the different technical approaches to services development – RESTful versus ws-* (ws-splat). The great thing about this debate is that it helps expose fundamental requirements, preconceptions and trade-offs.

I’m currently on the sidelines…my own position is that while acknowledging that ws-* is overly complex and has led us down a lot of blind alleys in the standardization wars process, the fundamental aspects are useful and productive if used properly. REST approaches are conceptually elegant and simple in their use of and adherence to the “resource oriented” view of the world-wide-web, but I haven’t used them “in anger” yet and need to reserve judgement.

There is currently a very interesting discussion on the value of WSDL happening at TSS. One of the best contributions to the discussion from William Childers says:

WSDL is supposed to give us away of tying together the service, its address, its operations, the required message formats and the supported delivery channels. That’s very useful and is something that can be processed and used at either design time or run-time (e.g. WSIF).

If WSDL (and Schema) did not exist we’d have to invent them. You can argue about how good they are as solutions (not so great) but I don’t see how you can argue that solutions aren’t needed which I believe is one of Joseph O’s points.

On the other side…Stefan Tilkov at InfoQ gives a good defence of REST against the doubters.

Well reasoned discussion about these approaches will help to clarify each and also help to educate the wider user community. Currently the REST approach certainly dominates public web services (such as Google, Amazon, Facebook etc) and that ws-* dominates enterprise web services. I feel there is significant common ground between the two and we will see a middle way that bridges some of the differences and leads to both better ws-* implementations and better REST implementations.

Why Service Consumers and Service Providers should never directly communicate

I just read this interesting rant from ZapThink on the importance of loose-coupling between service providers and consumers. It highlights the difference between a Service Oriented Architecture and SOA’s evil twin the “bunch of web services” (JBOWS).

“Lots of things change in an IT or business environment: location and availability of services, versioning of Service implementations and contracts, changes to business processes and policies, new or changing requirements for reporting, visibility, and control, and of course the need for new capabilities to solve emerging business problems or capitalize on new business opportunities. However, if you think that a Service is just an API, then all hell breaks loose when you try to connect a Service Consumer directly to a Service Provider.”

I wrote about this in a previous post…the need to Design for Change is a critical requirement for any organization and is one of the prime reasons behind adopting an SOA approach. Architectural approaches such as “loose coupling” are an important part of design for change. But that is only one dimension of the problem. Design for change also needs to be built into the IT culture. Change processes must be a natural part of your Services development and management lifecycle.

I find a common mistake is that Services are designed for a point purpose at a point in time without regard for how they will change over time. The result is brittle solutions that are expensive and risky to evolve.

The ZapThink article goes on to talk about late binding and the use of a services proxy and WS-Addressing to route service invocations to the appropriate provider. This is somewhat simplistic and I find that the pointed comments about “integration-centric techies” is a bit hyperbolic, especially since the ZapThink SOA Roadmap clearly shows an evolutionary progression starting from “static binding to static services” as the first phase along the ZapThink road to SOA. But everyone is entitled to change their mind, and leaving that aside I agree that strong decoupling of consumers and providers is important for a mature SOA. Some of these concepts have been discussed by others in terms of “Service Virtualization.”

Change is a continuing and important challenge for an SOA and the solution is “in your architecture” rather than something that can be bought off the shelf. Consider these sources of change that we must deal with every day:

  • Hardware failure in either our service implementation, or network connectivity – the need to support fault-tolerance or high availability.
  • The need to load-balance service invocations across a number of different but redundant providers
  • Changes in the underlying applications supporting the service provider – e.g. package version upgrades
  • Changes in the location of a service provider – e.g. in a disaster recovery situation, or planned migration from one facility to another.
  • Migration of service implementations – e.g. migration from a legacy application to a new platform.
  • Functional changes to service provider to support new business requirements
  • The need to support multiple service versions to allow phased migration of consumers from one service version to another.
  • The need to phase out old services which do not provide sufficient ROI.

The challenge is that all of these changes happen on different timescales. Some changes occur on sub-second timescales (fail-over and load-balancing) while other changes can occur over months (system migrations). There is no single indirection technique that will span all these requirements.

do be do be do

Slightly off topic but I couldn’t resist one of my favourite quotes (from Kurt Vonnegut) in response to a post by Miko Matsumura re SOA Governance…

“To be is to do”–Socrates.
“To do is to be”–Jean-Paul Sartre.
“Do be do be do”–Frank Sinatra.

Leverage and Vantage

I’ve been busy with customer projects for the last few weeks and hence the lack of postings. In this post I want to touch on some conversations about top-down versus bottom-up approaches to SOA.

This is a pertinent question because there is still a communications gap between the “business” and “IT” in many (especially large) organizations and as a result SOA initiatives are often driven from the IT side of the fence with little support or even understanding from the business.

There is a fundamental “chicken and egg” problem with SOA. It won’t gain support from the business unless a business case can be made…but conversely SOA payoffs are elusive without business support. Faced with this situation, many IT architects who want to develop an SOA approach are forced to try to conjure the egg out of thin air and hope that a chicken will hatch. The danger with this approach is that rather than gain an SOA you may end up with just a bunch of web services.

Two key facilities that an SOA initiative needs are leverage and vantage. Vantage to see where you need to go, and leverage to push the organization in that direction.

SOA is all about providing services to support the processes of the business – typically across organizational silos. There is a need to understand all the processes and their requirements – now and for the future. This visibility needs a vantage point “above the fray”. A point from where you can see the processes in their entirety. Without this vantage point you risk building the wrong services, or building services for the wrong processes or not anticipating future process changes. Moreover this vantage point must be experienced from the point of view
of the business – not just IT. So the question for an SOA initiative is “who in your organization has this vantage?” You may be lucky and have complete visibility from the IT cockpit, but that is rare. In general no one person has this vantage and it generally resides across different roles and people. Hence the need for some governance process to capture that vantage into a SOA plan.

So let’s suppose you have this vantage and want to execute on an SOA initiative. SOA is primarily about sharing – shared services built on shared resources using shared standards. Without sharing you wont get the SOA pay-off. But sharing requires communication and cooperation. Leverage is required to reconcile conflicting priorities in terms of requirements, schedule, funding, and resources. There may be some organizations where all these conflicts can be reconciled within the IT department, but I haven’t seen any yet. Typically resolution is required at an organizational level above the participants – that is the prime purpose of organizational hirearchy. Hence you need the appropriate leverage to get everyone moving down the SOA path.

While the type of issues your SOA initiative will face are fairly general, the specific issues and their resolution will be germane to your organization. This means that the place you will achieve the right level of vantage and leverage will be different for your organization. You might be lucky enough to work in an IT department that has the appropriate leverage and vantage, but that is rare. More likely you will have to go higher up to get these facilities for a successful SOA. This is the essence of the “top-down” approach to SOA.

I guess the “middle-out” approach might be characterised by “figure out how much leverage and vantage you have access to an scope your initiative from there.”