to homepage
 Weekly emails: how to advanced search
 Glossary lookup:


Loosely Coupled weblog

Friday, August 30, 2002

Tempted by Cocoon
I find myself intrigued by the architecture and capabilities of Cocoon, an Apache-based (and therefore open source) framework for XML publishing. It has two major virtues: a) it enforces a separation of content, logic, and style; and b) it assumes a service-oriented model, and thus it is built with the expectation of syndication (something that most website management systems support as an afterthought).

This article on WebServices.Org by one of Cocoon's developers is a useful jumping-off point for information about Cocoon, and also illustrates some of its advantages in the context of embedding form-based services within a partner website or web-based application. It seems to me that Cocoon goes a long way towards addressing some of the big issues that exist when offering content or services through a multi-tiered online syndication network — which is exactly what on-demand web services have to do.
posted by Phil Wainewright 1:35 PM (GMT) | comments | link
On-demand applications
I never thought the day would come when I'd find myself agreeing with Tom Siebel, but here we are: "In the not-so-distant future, applications will write themselves to conform to pre-established business processes," the founder and CEO of Siebel Systems told delegates to this week's CRM conference in New York, reports eWeek.

Delegates at XML Web Services One in Boston were hearing a very similar message from Eric Newcomber, CTO of web services platform vendor Iona. "Software right now is still a craft industry, where you have lots of individuals coming up with unique solutions that then need to be handcrafted together," he said, quoted in InfoWorld. Web services standardization "will enable software 'mass assembly' on a wide scale," he predicted. "XML and the commodity software around Web services gives us a real potential to define the missing standards for integration, get faster time to market and better ROI."

Interestingly, this future entails the cannibalization of both Siebel's and Iona's core products. Newcomer believes web services will prevail over CORBA, the middleware standard on which Iona's platform is based, while Siebel says that web services will obsolete the client-server generation of software — a prime example of which, of course, is Siebel's own CRM suite.

Naturally, Siebel wouldn't be saying this if his company didn't have an answer. The Universal Application Network (UAN) is Siebel's platform for self-assembly of applications that fulfil industry-specific business process needs.

Unfortunately I cannot support Siebel's prescription as heartily as I agree with his prognosis. I would have more confidence in the project if it didn't have such a list of industry worthies on the development team — do Tibco, WebMethods and Vitria really have such a vested interest in automated application assembly? True, it supports some up-to-the-minute specifications, including Business Process Execution Language (BPEL) and XSLT (eXtensible Stylesheet Language Transformations). But it seems to assume a business process model in which all possible business processes are known and defined in advance. That may be how enterprise applications were built in the days of client-server, but I'm not sure that it's going to answer the requirements of an on-demand service architecture.

The shortcoming in Seibel's vision is the belief that all business processes can be "established" in advance. Yes, it will be an improvement on current technology to be able to automatically assemble applications from established best practice, rather than having to pay a developer to handcraft a solution. But as soon as you make it possible to assemble them automatically, you create the potential to assemble them on-the-fly, and that's going to be the breakthrough capability that creates new competitive opportunities.
posted by Phil Wainewright 7:18 AM (GMT) | comments | link
Inside the citadel
Adding XML and SOAP security to firewalls is at best a temporary measure, at worst a self-delusion of the worst kind. Securing web services at the boundary is missing the point entirely. So I am bemused to see so many announcements over the past few days of firewall devices designed to do just that.

Ray Ozzie neatly summarized what's wrong with the firewall approach to web services security in his weblog recently: "I continue to be frustrated watching supposedly expert technologists pitch VPNs and enterprise 'boundary-oriented' security products, seemingly ignorant of the fact that boundaries between organizations are disappearing ... we've known for years that end-to-end security at the application or middleware level is the only real answer."

Of course, that doesn't mean there isn't a market for XML firewalls. Plenty of enterprises still rely on a boundary-oriented security policy, and therefore they have no choice but to continue to build up the walls of the citadel. But there shouldn't be a market for XML firewalls, and in the long run there won't be, because enterprises will either have switched over to a distributed security model, or they'll have gone out of business.

Successful participation in a networked world implies opening yourself up to the network (for more on this, see my October 2000 article, ... We Are All Inside the Machine). That means distributing security down to every device, every user, and every service. It won't be easy — throwing up a firewall is a whole lot simpler — but it's the only way. Any enterprise that doesn't have this on its roadmap has got its head in the sand and its neck on the line.
posted by Phil Wainewright 3:16 AM (GMT) | comments | link

Tuesday, August 27, 2002

Still not enough standards to go round
Hardly a day seems to go by without somebody announcing a new web services standards initiative. Earlier this month, Novell seized an opportunity that had been overlooked by bigger names such as Sun, Microsoft and IBM, winning the chairmanship of the OASIS Management Protocol Technical Committee, formed to develop an XML-based management protocol specification for web services.

Given the hopelessness of coming up with systems management standards for web services at this stage in the game, Novell may discover it has drawn the short straw there, but nevertheless it has put down a marker that it plans to be a serious player in the standards game. Being the master of a standard brings not only kudos but also valuable competitive advantage to a vendor. It can be good for the industry as a whole, too, by ensuring that standards definition gets driven at a commercial pace. The trick is to keep everyone else sufficiently engaged that no one starts going off on their own tangent.

Hence the latest brainwave from WS-I, the web services interoperability group set up by IBM and Microsoft. WS-I has launched WSBasic, a set of profiles designed to help enterprises develop and run web services that will plug in with others. According to WS-I representatives quoted in eWeek yesterday, the organization will be releasing a whole stack of profiles that build on the foundation of WSBasic, and as if that wasn't enough, "they expect that vertical industries will build on the WS-I profiles by adding industry-specific standards to them." So in the end, everyone will be able to make their contribution to the standards stack — an excellent ploy to try and ensure that everyone buys into it.

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

Monday, August 26, 2002

More about BPEL4WS
A very useful introduction to the recently-launched BPEL4WS business process specification is now available on the IBM developerWorks website. This is billed as the first of a series that will alternate between explanations of the concepts behind BPEL4WS and articles on technical implementations. The article outlines the fundamental concepts behind BPEL4WS, filling in some useful detail on the ideas embodied in the specification.

For those feeling puzzled by all the conflicting business process specifications that have emerged over the past few months, Doug Kaye has published a handy diagram on his weblog (though I suspect the inclusion of the OASIS-led Business Transaction Protocol as part of the stack may be an over-simplification). Doug makes the important point that the alternative specification pre-dates SOAP and therefore is based on XML, whereas BPML4WS "utilizes, and is locked to, SOAP" (so perhaps it should be 4SWS, rather than 4WS). Whether this is a good thing or not readers will have to decide for themselves.

Edwin Khodabakchian, writing in the Collaxa blog, has picked up a discussion board posting with some comments from Cisco's Ricky Ho, comparing BTP to WS-Transaction. Ho highlights several differences, which he sums up thus: "While I think BTP is more sophisticated, WS-transaction has taken out some powerful features (maybe they want to make thing simpler)." Perhaps the point is that they want to make things more loosely coupled.
posted by Phil Wainewright 4:17 AM (GMT) | comments | link

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

read an RSS feed from this weblog



latest stories RSS source

Headline news RSS source


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