A song and dance about orchestration

Some people call it choreography; others say orchestration. It's the all-important complement to service-based application assembly, making sure that all the elements in a multi-player ensemble act in concert. When the W3C's Web Services Architecture Working Group met yesterday to discuss Oracle's call to bring some harmony to the current cacophony of emerging standards, the vote in favor of action was unanimous. But on the question of whether that work should be done within the W3C or elsewhere, several vendors abstained and Microsoft voted against, according to InfoWorld's report.

The debate matters because the move to web services and a service-oriented architecture leaves a missing link ... In fact, it leaves an almost infinite number of missing links — that's the point of the exercise. Rather than defining in advance all of the connections and processes that an application or service will link up with, the service-oriented approach leaves the links open so that they can be adapted to whatever needs and opportunities come up in the future. Choreography/orchestration comes in to pick up and co-ordinate those links to fulfil specific business processes.

Thus in a service-oriented architecture, applications are not deployed as prefabricated entities. Instead, they are assembled as required, by pulling together the various services needed to complete a business process. Note that the operative word is 'assembly' (which suggests a loose coupling together of the various building blocks), rather than 'integration' (which implies a fixed and permanent join).

The worry about any concerted effort to agree a specification for choreography must be that many vendors will be tempted to protect the tight integration that is so often ingrained in their current application and infrastructure products. On Monday, I discussed Eric Dubray's assessment of the relationship between business process and web services. His conclusion, which I quoted at the end of my posting, set out three separate milestones which had to be achieved before reaching the ultimate objective of being able to model and reconfigure business processes in real time. Having "vendors stabilize their 'business process management system' offering" is only the first of the three milestones. The second is rewriting applications to take advantage of this new model. That will be by far the biggest mountain to climb on this journey, even when compared to the Herculean task of converging multiple conflicting specifications to a single, shared standard.
posted by Phil Wainewright 2:54 PM (GMT) | comments | link

Of networks and namespaces

At each level of our lives — as human beings, as citizens, and as members of whatever other communities we each belong to — the only way forward is to adapt to living in a space that we share with others. In the past few days, the same theme has surfaced in a remarkable selection of barely connected weblog articles:

• Dave Winer: Lessons of 9-11 — "We can't close our borders. We live on this planet with everyone else. Global warming, AIDs, terrorism, all penetrate all borders. New York is a world city ... we aren't above the rest of the world, but we are part of it."


• Ray Ozzie: Tyranny, Terror and Technology — "In creating a new nation, our founding fathers sought to develop a new type of governing body ... What was needed was a new organizational form: one with checks and balances. An appropriate mix of centralization and decentralization, masterfully formed so that it could take on the best attributes of both."


• Jon Udell: Mastering the network form — "Debate rages over a web syndication format known as RSS ... Throughout this whole excruciating process, and especially during the recent flare-up, there has been a deep implicit consensus — The debate is spread across a series of weblogs, all connected to one another by means of interoperable variants of the very RSS format being so fiercely debated."

The fierce debate over RSS 2.0 is of course a mere blip on the scale of human concerns when compared to the question of terrorism and the war against it. Yet both are a product of the same network forces that are throwing the human race together into the single melting pot of our modern, connected world. And the solutions (to the extent that it is possible to resolve either question in our lifetimes) come down to the same basic struggle to establish a common ground for co-existence.

Establishing that common ground in any sphere means finding agreement on a core, trusted set of rules that all participants are prepared to abide by, leaving as much flexibility as possible for individual groups to set whatever extra rules they want to agree amongst themselves. The system relies on a careful balance of trust and respect. It only works if everyone not only commits to the core set of rules, but also respects the values of individual groups and their right to set and abide by additional rules, whatever one may think of them privately.

In XML terminology, a namespace is where participants exercise that freedom to set extra rules, and Dave Winer's olive branch last week was to add XML namespaces to his RSS 2.0 proposal. It was a significant move, but one that failed to extinguish the territorial arguments over what else should or should not be included in the core.

In its tiny microcosm, the passion of the debate over RSS is a reminder of how much energy — and enmity — people are prepared to invest in either winning or resisting the imposition of a set of values on the networks they participate in. We all know that, so long as significant groups are excluded from it, both the network and the excluded each remain the poorer for it. Nevertheless, throughout history, people have fought almost to destruction rather than adapt their networks to respect the namespace of others.
posted by Phil Wainewright 8:49 AM (GMT) | comments | link

Reinventing the wheel

Delivering software functionality as an online service raises tricky questions about how to license, package, price and monitor your offering. Web services vendors are just discovering these questions, but it's not the first time they've been encountered, as I've pointed out in my ASPnews column this week. Application service providers have spent the past few years wrestling with the implications of online software-based service delivery, and carry the scars to prove it.

Unfortunately, I don't see much evidence of vendors' web services teams spending any time talking to ASPs to find out what experiences they've already had, and so they'll probably end up repeating the whole learning process in its painful entirety. This will be a sad waste of a great body of knowledge about the pitfalls of pay-as-you-go pricing, the shortcomings of the fixed per-user subscription, the unmanageability of per-user and per-device licensing, the pros and cons of packaged pricing versus a-la-carte modules, and the many unexpected complexities of measuring, reporting and maintaining service levels in a multi-tiered, multi-provider environment.

This is despite the often warm support that Novell and IBM, the two vendors I've highlighted in my column, provided to ASPs in the past. This doesn't bode well for a rapid evolution of effective solutions to these problems. On the other hand, maybe it opens up opportunities for ASP survivors to translate their hard-won experience into a first-mover advantage in the web services sector.
posted by Phil Wainewright 4:02 AM (GMT) | comments | link

Looking ahead to California, London, Paris

Business activity is rightly taking place in an atmosphere of respectful hush this week. That likely means next week will be doubly busy. Some vendors will have been saving up announcements to coincide with InfoWorld's Next-Generation Web Services conference in Santa Clara, which begins on Wednesday 18th, while in London, Access Conferences will kick off the European web services conference season the day before with its Web Services Technology Summit (for a full calendar of upcoming conferences, see Loosely Coupled's new events directory).

The first product unveiling of the week from a web services vendor will likely come at a breakfast briefing on the 17th in Paris, when French web services startup Orchestra Networks will present a seminar to mark the release of version 2.5 of its EBX Platform. Based on J2EE, the platform is used for developing and managing modular, reusable interactive web services for publication and syndication over multiple channels. Orchestra's customers include France Telecom, Société Générale and Kraft Foods.
posted by Phil Wainewright 5:38 AM (GMT) | comments | link

Business process and web services

The relationship between business process and web services is very important, but is not often explained very clearly. Jean-Jacques Dubray posted an article last month, The end in mind ..., which I felt touched on many of the key issues. I've been studying it in detail to get a firmer grasp of the underlying concepts and to relate them to what's going on in web services at the moment. What follows is not a summary of the original article, but draws on it as a foundation for summarizing my own perspective.

• One of the most important things to highlight is that we are in the process of moving to a new application model, one that is fundamentally different from the one we're familiar with. Today, an application is a discrete piece of software that a user opens on their computer in order to perform a specific task. In the new model, the icons that users click on will call on an underlying layer of interconnected application processes. The new application model is an infrastructure layer, transparently providing software automation to perform business processes as required.


• This change to a new application model is driven by two needs:
  
  
  1. The need to evolve applications rapidly to meet changing requirements
  
  
  2. The need to integrate readily between applications and processes (some people have started to call this "process federation")
  
  
  
  A further factor has been the emergence of a reliable, shared, standardized infrastructure. This has been a significant enabling force.


• In response to these needs, applications are fragmenting into process components which are easier to rearrange and integrate with each other. Standardized web services interfaces and protocols provide the architectural framework that makes this feasible.


• Business process modelling seeks to automate the task of rearranging process components. It does this by expressing the business model as metadata through which the user can directly reconfigure the process logic. Instead of process components executing in a predetermined pattern that has been built into the software, the user can choose to vary the process by selecting from a range of options that are defined separately, often using XML schema.


• But in today's application model, different categories of process component are all jumbled up together. Before we can make any real progress, we must separate these components into three distinct layers:
  
  
  1. Individual tasks performed by users or devices (tasks).
  
  
  2. Integration and workflow to connect individual tasks within a process (process flow).
  
  
  3. Business process modeling and orchestration to plan, co-ordinate and manage the deployment of tasks and workflow (business model).
  
  
  
  The task and process flow layers are concerned with automating business process logic. They make up the new application model, while the third layer comprises the business model that it serves.
  
• New tools and methodologies in business process management are required to bring automation to the business model layer, including an effective way of handing off exception handling to users. Major vendors will bring 'business process management systems' to market.

Where are we now? The answer is, not very far. Most applications are designed around a limited collection of pre-set tasks. Some come in suites, with certain tasks permanently joined together in pre-set processes. People spend a lot of money adding custom tasks of their own, and joining them together in custom processes. Now they're using web services as a quicker way of doing this.

Very rarely does anyone give any consideration at all to whether they might want to reassemble tasks and processes in different ways later on. Even if they do, very few applications are architected in a way that supports this more flexible model. But it's important to have that possibility in view, even if the reality of modeling and reconfiguring business processes in real-time is still something of a futuristic vision (especially in a B2B context). This is what Jean-Jacques Dubray thinks it will take:

"Everything that you see or can buy today is still at the infrastructure and application model level. This is going to remain like this for a while. For how long? We will remain here until a) infrastructure vendors stabilize their 'business process management system' offering b) most applications are rewritten to take advantage of this new application model and completely isolate the process-oriented logic from the model-oriented logic, c) tool vendors emerge with business process suites which provide the hooks to manage this infrastructure and metadata at the 'business process level'."

posted by Phil Wainewright 9:04 AM (GMT) | comments | link