Thursday, September 30, 2004

When is a web service not a web service?

I've long had a bit of an issue with the definition of the term "web service". An old colleague of mine and I wrote a fantastic mobile Windows CE application a few years ago that had to have MSMQ surgically removed at the 11th hour owing to a bug in the TCP stack on CE (or something like that.) We replaced it with XML over HTTP, and as far as I'm aware it's still going strong.

I've always described the project as using web services, but we didn't use SOAP, and we were really just posting text to an old-fashioned ASP page. Web services do now seem to predicate the need for SOAP, which I don't really agree with, but the official definition (or the nearest thing I could find) is rather less precise on the protocol. This is what W3C has to say on the subject:

"There are many things that might be called "Web services" in the world at large. However, for the purpose of this Working Group and this architecture, and without prejudice toward other definitions, we will use the following definition:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."

The interesting bit here (for me) is the last sentence, and the use of the word "typically" and "other web-related standards".
Does this mean that SOAP messages exchanged over FTP or SMTP could be defined as web services (though I'm not sure how WSDL would fit into this)?
Does a web service have to be request-response, or can it be simply push / pull?

Enterprise Integration Patterns

Just started Enterprise Integration Patterns by Hohpe & Woolf. I'm only 50 pages in, but it's already proven of value in communicating some core concepts in the whole message/event-driven architecture to my client. An invaluable reference for anyone working in this 'space'.

Tuesday, September 28, 2004

Is anything safe?

Following on from the "J2EE is dead" comment below, now the internet itself is under threat: "The end of the internet is nigh"

Monday, September 27, 2004

Naming collision

OK - turns out (unsurprisingly) that they know each other already -

Kevlar Suit

Nice provocative article from David [.NET] Chappell on the demise of the J2EE community process. Should get a few people hot under the collar.

Sunday, September 26, 2004

Let the blogging begin

I've been reading "Enterprise Service Bus" over the last week, to try and put BizTalk into context, alongside integration, messaging and SOA solutions from the non-M$ side of the fence.
Unfortunately, the author (about whom more later), dismisses the entire M$ effort in a single sentence in chapter 1, "...its integration capabilities are locked into BizTalk, which is a hub-and-spoke integration server... to qualify as an ESB, both a distributed message bus and distributed integration capabilities need to exist."
Hmmm. I'm not sure I agree with this - one of the strengths of BTS and its "host" architecture is that it can be distributed, even if it all ultimately sits on top of the message box 'hub'?
Well, I persevered with the book, which is excellent btw, and am convinced more than ever the BTS satisfies almost all of the author's requirements for an ESB.
The author is David A Chappell, who many might think they know as the David Chappell of the eponymous consultancy, and BizTalk evangalist. Which makes his comments all the stranger.
This David Chappell, however, is "Chief Technology Evangalist" of Sonic Software, a J2EE shop. What are the chances of that - two leading exponents of integration software, working from opposites sides of the fence, with the same name?