to LooselyCoupled.com homepage
 
 Weekly emails: how to advanced search
 
 Glossary lookup:

 

Loosely Coupled weblog


Wednesday, October 15, 2003

Stop, go, flow
Asynchronous messaging matters because real life isn't like a flowchart. Depicting a process as a series of steps on a sheet of paper gives the impression that it will execute smoothly and flawlessly, with no delays or pauses. This, says Ingo Rammer, is The Flowchart Lie (PDF, 118k): "Even though these processes have a distinct starting point and ending point, they don't necessarily have to be completed synchronously!"

In real life, systems break down, information goes missing, people go for lunch — and yet despite that, developers insist on keeping users waiting for synchronous processes to complete. They do this even when, as Ingo points out, the business processes that they're automating are inherently asynchronous in nature, such as joining a mailing list, placing an order, or returning items.

The reason they do this is that it's very hard for them to adapt to an asynchronous development style. Collaxa CEO Edwin Khodabakchian, whose blog alerted me to the Ingo Rammer article, gives some insight into why this is in an article for Web Services Journal: "while most developers and architects I work with are sold on the value of an asynchronous architecture, it introduces a steep learning curve that makes it more difficult for them to take the next step."

Asynchronous messaging means starting from the assumption that the other party to the conversation isn't actually listening right now. Edwin explains that this is why web services needs extra standards like WS-Addressing, used to define where a reply should be sent, and WS-ReliableMessaging, which makes sure messages reach their destination in good order. He explains why many transactions will need to define compensating actions in case they need to be rolled back, as specified in WS-Transaction, and how BPEL provides a framework for exception handling.

Developers have got away with omitting all of these capabilities in the past because they've been able to rely on the flexibility and tolerance of an often overlooked component in any automated business system: the users. Although they're often the costliest resource in the system, human beings still deliver terrific value for money, because they come with adaptability built in as a standard feature.

People are uniquely programmed to operate in the loosely coupled environment of the real world, and over the years they've become accustomed to making extra allowances for the often absurd inflexibility and intolerance of business software systems. They improvize their own addressing formats when dealing with badly designed data entry forms. They know they need to plan for unreliable availability of system resources. They always have a compensating action in the back of their mind when beginning a transaction; and exception management is second nature to them.

Computers have always been too dumb to do all this, because their developers were either unable or unwilling to implement those features. They used to be able to argue that adding all that extra overhead was just too complex and resource-intensive to be economically viable. But times have changed. Asynchronous design patterns have been established, and standardization is making them increasingly cost-effective to implement. It's high time for developers to get up to speed and start deploying asynchronous capabilities. There's no excuse any more.
posted by Phil Wainewright 4:58 AM (GMT) | comments | link

Tuesday, October 14, 2003

WebMethods jumps ship
I'd been wondering how webMethods execs always managed to look and sound so relaxed about the imminent threat of extinction their business faced. Now I know why: they had a plan 'B'. Yesterday's three-way acquisition announcement is clearly not something that was hatched overnight. It demonstrates careful execution of a clearly thought-out strategy.

The news has been covered extensively elsewhere (see below). Here are the key points at a glance:

  • EAI software vendor WebMethods yesterday announced the acquisitions of The Mind Electric, DataChannel, and the Dante Group.

  • The total spend was $32 million, with the Dante deal already closed and TME expected to close this week.

  • Around 40 staff join in total. TME founder and CEO Graham Glass becomes webMethods CTO (replacing Jim Green, who left earlier this year to become CEO of startup Composite Software).

  • DataChannel, bought from security software vendor Netegrity, brings portal technology and personnel. The product will be renamed webMethods Portal.

  • Dante Group contributes business activity monitoring and network traffic analysis software. Its product becomes webMethods Optimize.

  • The Mind Electric's Gaia product is the cornerstone acquisition. Gaia provides a standards-based, service-oriented framework for bridging J2EE and .NET environments, described as a web services fabric. It becomes webMethods Fabric.


What is remarkable is the sangfroid with which webMethods' top management has handled its fate. "Does web services threaten the livelihood of EAI vendors?" we asked earlier this year in a Loosely Coupled feature article, Integration: Free at last?. Creeping standardization was invading their traditional territory, we concluded: "EAI vendors may need to drop their prices for these newly commoditized functions, while moving their remaining value proposition into other areas."

Now we find that webMethods management has calmly and dispassionately decided to do exactly that. According to Internet Week's report today: "WebMethods plans to gradually 'decompose' its older integration platform and move its functions, such as adapter technology, workflow capabilities and business process modeling, into the acquired service-oriented architecture."

As acquisitions go, you can't get much more strategic than the role webMethods seems to have chosen for Gaia. TME's web services fabric has effectively become webMethods' lifeboat, the vessel in which it hopes it will be able to pilot a new course for its business and its customers, steering them away from the shipwreck that lies directly ahead for anyone still steaming ahead with EAI.

So what is so good about this fabric concept? A couple of articles earlier this year provided some explanations:


If Gaia is anywhere near as good as the vision promises to be, it is going to be as far removed as you can get from the hard-wired, tight coupling of traditional EAI. With this acquisition, webMethods earns my respect for an imaginative response to a tough challenge, at a stroke repositioning the company from EAI also-ran to SOA pioneer.

Here's how the online tech press has covered the story since it broke:


posted by Phil Wainewright 12:29 PM (GMT) | comments | link
Service views
In a service oriented architecture, you don't view raw data, you call up a service that presents you a slice of information. The new buzzword for information presented in this way is a 'service view', and two new products launched this week have both used the term.

  • Composite Software, a startup founded by former webMethods CTO Jim Green, announced availability of its first product. "The Composite Information Server is designed to collect data from a variety of sources and feed it back to the end user in any format requested," reports eWeek. "Once data is accessed, the Information Server aggregates it into Composite Views ... The server is based on Composite's View Services Architecture query-processing engine."

  • Westbridge Technology, hitherto known as a web services management vendor, announced Westbridge XML Message Server (XMS) 3.0. Although this is billed as a security and management product, that is only one of many applications it can be used for. "The company describes XMS 3.0 as the premier implementation of the Service Views capability, which enables customers to have reusability and interface control that is key to service-oriented architectures," reports InfoWorld. "Service Views are virtual services composed from one or several different services that can be mixed, matched, and modified by the administrator, according to Westbridge. Additionally, Service Views serve as the logical control point for security, interoperability, monitoring, and business rule enforcement, the company said."

    A searchWebServices article expands on the potential when XMS is used with a plug-in that lets users work with service views from within Excel. "Once it is connected to an interface, Excel can be used to update an existing Web service, or to download data from a Web service to share among other spreadsheets ... [Kerry Champion, president and co-founder of Westbridge] described his company's 'center of gravity' as service views, or virtual views of a service. [ZapThink analyst Jason] Bloomberg, who said the term 'view' originated in the database world, said service views provide an organization with a single, course-grained interface that can be accessed by consumers of a Web service."


Service views may be a new term, but it's one that very accurately describes the services-driven information access capabilities that will soon become a desktop commonplace with the introduction of Microsoft's new XML-aware version of Office. We'll not only be talking about service views a lot, we'll also be looking at them, creating them, often cursing them. Service views are here to stay.
posted by Phil Wainewright 3:52 AM (GMT) | comments | link

Assembling on-demand services to automate business, commerce, and the sharing of knowledge

read an RSS feed from this weblog

current


archives

latest stories RSS source


Headline news RSS source


 
 


Copyright © 2002-2005, Procullux Media Ltd. All Rights Reserved.