|
|
Adam Bosworth is leading off today at CTO Forum. After being introduced as an XML first mover, he graciously directed the spotlight to Jean Paoli, who's sitting in the back row (and will be speaking on a panel later). Adam recalled a plane trip in 1996, during which Paoli had passionately explained to him the promise of XML to him. A nice moment!
Recalling his use of the ARPANET in 1973, Bosworth says: "You can have the ecosystem sitting there for a long time, before anyone turns the key." The PC unlocked one door. HTML/HTTP unlocked another. No surprise: BEA bets that Web services will unlock the next door.
More history. "Who remembers Cullinet?" 5 hands go up. "Twenty years ago, they dominated the database company industry." What happened? The client/server wave brought overwhelming value, and others rode that wave. Being dominant, Cullinet saw no benefit to making things cheap, easy, and standard. "When these waves come, they come with ruthless force."
When Bosworth asks enterprises how many apps they have deployed, they say: thousands. He categorizes the integration challenges like so:
Integrate the UI,
integrate the data,
integrate the business processes.
The realities of integration are not pretty. Data lives behind firewalls, apps guard it jealously, you can't run one query to reach all of them. Apps change all the time, independently of one another, are deployed at different times by different people (who don't like each other), and are not always available. (Echoing Ian Foster, Adam says: "It turns out to be a bad idea to assume an app is like electricity, always on tap.")
Here are some first principles:
Coarse-grained messaging. Get everything you need in a single round trip. Why? If not, you shut apps down. Even now, the numbers are big: 3000 messages/second flowing through Web services message brokers. To be coarse-grained, though, you have to be able to represent anything in the payload. "The insight, sitting on the plane with Jean in 1996, was that XML is the way to do that."
Public contracts. You can change your operating system, you can change your object model, but don't change your public contract. We know this works. "The proof point is the web."
Asynchrony. "I've been surprised by how slow some companies have been to pick up on asynchrony." The recently-published WS-Addressing "contains the core plumbing for standards based asynchrony."
Message-driven model. We need a programming model for message-driven programming. How does a developer write code in that environment? "It's no problem for systems programmers, but for everybody else, it's a challenge to make it easy for them to write apps that wake up when a message comes in."
Declarative query. "We don't have a good query mechanism for
XML. We have XSLT, designed to take semi-structured data whose
schema was unknown, and generate rich UI. But there was a little
problem: it's almost unreadable, and performance is poor because
it's rules-based. In practice, Web services messages have known
schema. A query language that knows the schemas can optimize."
The punchline: "Our implementation of XQuery will do most simple
transforms in a millisecond."
Scripting. "Imagine a VB without VB." You have a form
designer, and components, but no scripting. In theory you can do
everything you need, in practice it's hideously inefficient, you
would have to build a custom control for each piece of business
logic. We don't do that. We extend the behavior with a language.
"If you do choreography, and you don't have a visual tool these
days, you are the moral equivalent of VB without a forms designer."
Similarly, lacking a procedural language for choreography, the
current situation is like VB without VB. "At the end of the day,
there's no substitute for procedural logic to deal with the
realities of real apps."
Two complementary technologies will enable "dynamic
runtime-modifiable systems, rather than static compile-time systems
that make you shut down and restart your services." They are:
XML Query, for declarative work, and
ECMAScript for XML (E4X), for procedural work (see also this heads-up)
XML repository. In Adam's vision of SOA (service-oriented architecture), a message broker sits in the middle of everything. It sees a lot of self-describing XML messages, and it has to do high-performance storage and retrieval. So it's a true XML database. There's nothing relational about this problem. But, being an old database guy, Adam sees an opportunity. In the message broker, the XML data store is not inherently multiuser. "It deals with messages in flight, and this makes it possible to do all sorts of optimization."
Great talk. It's always refreshing to watch Adam Bosworth paint the big picture!
Former URL: http://weblog.infoworld.com/udell/2003/04/01.html#a653