Tuesday, May 21, 2002

Just finished presenting a talk on IBM Web Services to the newly formed "Java By The Bay" Java user's group.  Had a blast.  Did a fairly informal talk with a demo highlighting interoperability and the importance of implementing proven design patterns.  Good questions afterwards.  The other presentation was given by a guy from Sun who works on their UDDI implementation.  He talked about the emerging Java community Web services API's (JAX-RPC, JAXM, etc).  Good talk, good guy.  I really like seeing the technical folks who are actually in the trenches implementing this stuff out talking and interacting with end users.  Anyway, looking forward to future meetings with this group.  Not only was it fun, but it gave my wife and I an excuse to leave the 2-yr old with grandparents and get away to San Francisco overnight. :-)  9:43:03 PM

Now that the morning email is done, it's breakfast and off to San Francisco! 8:25:43 AM

Jon's Radio: "Does SOAP routing necessarily preclude an HTTP-derived transport? If so, why? If not, what would a more regular and comprehensive approach to intermediaries look like? Is more formal capability declaration the way forward?"  SOAP-over-HTTP introduces a new processing layer that previously did not exist between the business application and the wire transfer/transport protocol.  This new layer opens the possibility to move functionality typically provided on the transfer/transport protocol layer up a layer so it's not tied to underlying transfer/transport mechanism.  Intermediaries are a prime example of this.  By defining a SOAP routing mechanism that deals with intermediaries, we give ourselves an intermediary processing model that is completely independent of the intermediary processing capabilities of the underlying transfer/transport.  This, in effect, does indeed prelude (but does not eliminate) the necessity for such constructs in the transfer/transport layer.  It can be argued that SOAP, in fact, that SOAP itself could preclude the use of HTTP altogether.  It would be a fairly straightforward proposition to create a standardized SOAP over TCP/IP protocol that completely addresses the needs/requirements of the vast majority of Web services.  Not sure if that answers your question. 8:19:26 AM