April 12, 2004

Web Services Integration Scenarios and UML

Eric Newcomer follows up on our discussion with regards to UML's suitability for Web services.

First of all, Eric states that UML is not suited very well for Web services, since they are typically used for integration scenarios across application domains. The easy, MDA-zealot answer would be that of course you can UML for integration purposes. In fact there is a two-year-old, 304-page specification, the UML for EAI profile, that is explicitly aimed at this (it's a bit out of date, with mappings just to MQ Series and JMS, but so what). I don't have any experience with it, though, and I'm highly skeptical about publicly adopted UML profiles anyway; so I'll avoid that easy answer.

I can follow Eric's argument that basically, UML (not MDA ;-) ) has been designed to build new systems, not to integrate existing ones. Still, often you build a new system and need to integrate several existing ones into it. When you're building a system today, you'll also equip it with a Web services-enabled interface right from the start, and not add one later. In these cases, you need to do both "classical" as well as "service-based" development, and that is where I believe UML-driven Web service creation makes a lot of sense.

Even if this is not your use case, I'm not sure I agree that learning UML in order to use Web services is overkill. I'll try to back that up with a nice example, stay tuned (I'll need some spare time to do this, as well as to publish some information about the project I was referring to). It basically seems to boil down to the question whether you know one (Web Services or UML) already. Picture yourself not knowing either; what would be easier to understand — a UML class diagram, or an XSD/WSDL file?

When I'm not constrained by the borders of reality — i.e. when I stop thinking about what is actually usable today, and allow myself to think about what I believe would be ideal — I feel that it's actually MOF that I would really love to be able to use, instead of "just" UML. With a MOF-based meta-CASE tool, the Web services world would have its own Service Modeling Language (SML™), perfectly suited to the task at hand, and easy to integrate with the rest.

April 09, 2004

The hidden impact of WS-Addressing on SOAP

Christian Weyer points to a developerWorks article about WS-Addressing. Apart from food for Mark's usual criticisms about mixing transport and transfer protocols, and ignoring the places where information is supposed to be stored in the first place, it's also a nice answer to his recent comment.

WS-ReliableMessaging Implementations

As part of an article I'm writing, I'm researching a bit into WS-ReliableMessaging. As part of this, I'm looking for implementations. This is what I have found so far:

• Systinet WASP 5.0 (Beta, expect this link to become stale soon)
• Apache WS-FX Sandesha
• IBM Emerging Technologies Toolkit (ETTK)

Interestingly enough (for me, at least), Microsoft doesn't yet support WS-ReliableMessaging in WSE 2.0, although support for WS-Addressing is included.

Any pointers to implementations I might have missed are welcome!

April 07, 2004

REST Advantages

Sean McGrath writes about integration and REST:

This [REST/the Web] does not solve the general negotiation problem (which is probably unsolvable short of artificial intelligence) but brilliantly raises the integration watermark above which it becomes an issue, this significantly reduces the amount of custom coding you need to do to get a conversation going.

I can see benefits in the REST approach (ease of use, flexibility, simplicity, ...). I fail to see this one, though. The amount of custom coding required is reduced compared to what? Compared to using plain sockets: yes. Compared to the much-hated, RPC-style, initial Web services approach: no.

RESTful UDDI

Radovan writes about increased demand for UDDI, and interestingly enough suggests that Systinet is probably going to REST-enable their registry.

Ever since reading Paul Prescod's REST article, where he took UDDI as an example case, I felt that this would be a great idea. With UDDI V3's optional GET binding (which Systinet supports), it's possible to get at every UDDI entity via a simple HTTP GET. Extending that to support PUT should be easy, and the publishing API is pretty REST-like, anyway.

I like UDDI — as long as we're not talking about the Internet scale use case (the UBR). In a company-internal or extranet-style SOA, the registry is an essential component.

Even more on WSDL vs. IDL

This is really getting interesting ;-) Mark points to an update from one of the authors, Jim Webber:

The killer differentiator is that for a given WSDL portType (or soon "interface" in WSDL 2.0) there is no implication that the portType is "implemented" by a specific class at the back-end. It might make sense for you to do that in certain situations, but at other times it might make sense for one operation in a portType to be handled by one computing system and another operation from the same portType to be processed by a completely different system.

That is, indeed, a good point I was not really aware of before.

Mark follows up with asking what a successful response to a message in "contract mode" would look like, and that an HTTP 200 response code would not have semantic meaning with regards to the message. Right, it doesn't — that's why the response code doesn't matter as much as the response's content itself, and why we have things such as WS-ReliableMessaging. You can maybe fault the WS community for misusing the HTTP application protocol as a transport protocol, but at least it's done so consistently ;-)

More on WSDL and XML Schema

Chris Ferris follows up on my take on the WSDL-is-not-IDL article (as does Mark Baker).

While I agree that the main problem is one of static typing tied to the schema, I believe this is what XML Schema was intended to do. I may be wrong — I did neither follow nor look up history here — but the whole point of XML Schema seems to be to move from DTDs to something that resembles a programming language's type system. I also still maintain that even if it's theoretically possible to use something other than XSD with WSDL, this doesn't matter for all practical purposes (since I don't believe that a critical mass of tool vendors is to support, say, RELAX NG anytime soon).

I know David Orchard's versioning article, and it's great and it shows how much he knows about XML Schema's details and I'm going to use that information for my own Web services design work. Unfortunately, it also shows that all of the possible solutions differ only in the degree to which they suck. Versioning with XML should be, and I believe could be, trivially easy. Due to XML Schema, it clearly isn't.

April 06, 2004

Why WSDL Is Not Yet Another Object IDL

Savas Parastatidis links to an article he co-authored about this subject.

I strongly believe that there actually is a difference between SOA-style Web services and Distributed Objects, and I even share some of Savas's thoughts. But I don't think WSDL is a good candidate for making this point, since with its reliance on XML Schema it's probably the least flexible and most static part of the whole Web services architecture.

Update: more here

April 05, 2004

Web Services Choreography

The W3C has published a working draft of the WS Choreography Model Overview. Yet another standard to look at ... keeping up with all of the standards and specifications that pop up in the Web services arena can be serious work.

April 04, 2004

XSD vs. RELAX NG

Elliotte Rusty Harold writes:

I think the future is clear, and it ain't spelled "XSD". Major recent RELAX NG wins include DocBook, OpenOffice, XHTML, and SVG; all of which are planning to move to RELAX NG in their next versions. I have yet to encounter a group that seriously explored RELAX NG and still chose to use the W3C XML Schema Language

I have only taken a casual look at RELAX NG, but I clearly like it a lot better than XSD. Now if it would only be acknowledged in the Web services world ...

UML to model Web Services?

Eric Newcomer answers some of my criticisms of his recent posting on MDA.

Great to see that we're not that far apart, and kudos to Eric for openly acknowledging a slight change of mind — something you don't find very often. Interestingly, many opponents of code generation tend to compromise on the viability of doing one-shot generation without later on going to back to the model, while I believe that this is even worse than not doing code generation at all.

One interesting point remains: Eric believes UML to unsuited for modeling Web services. I see no reason why this should be the case. I strongly agree that Web services are not distributed objects, but of course UML can be used to model non-OO concepts as well. In fact, we are using UML in one of our projects to model Web services, and we definitely do not take a distributed objects approach.

Maybe I should illustrate this using an example. Anyone got a nice Web service I could use? ;-)

April 02, 2004

Sean McGrath, Objects, and Resources

Sean McGrath on The fallacy of business objects. While I don't necessarily agree with the overall conclusion — IMO, there's about as much proof that REST or Web services will work as there was for objects a decade ago — the article has a very nice and concise description of REST principles.

April 01, 2004

BPML vs. BPEL vs. BPELJ

Another reaction to the BPELJ proposal: A paper by Howard Smith (who is CSC's CTO (Europe)). Very interesting, especially the historic (if one can already call it that) information about the BMPL/BPEL controversy. Of course it should be taken with a grain of salt, since Howard Smith is not only co-author of a book on Business Process Management, but also co-chair of BPMI.org (the consortium responsible for BPML).

More on BPEL-J

Jean-Jacques Dubray explains why he likes BPEL-J. My problem with the whole approach is that I either want to extract business process modeling information from my implementation source code, in which case I might be tempted to use something programming language-independent, such as BPEL; or I decide that my requirements can only be fulfilled by using a general purpose programming language - which would make me use something like Java, C# or some dynamic language.

The idea of using XML as a syntax for "real" programming languages plainly sucks — all it does is create an illusion of independence of a particular platform, when in reality it's just obscured badly behind a syntax totally unsuited for the task. Now whatever you think of BPEL, one of its (if not its only) benefit is that it is supposed to be portable across different BPEL engine implementations. Mixing it with Java would make me no less dependent on the Java platform that if I had used Java directly, so I just plainly fail to see the point (you could just as well directly go with the JSR JJ points to).

JJ's example — if I understand it correctly — would imply that I can mix process execution semantics with things such as accessing a database, which is something that IMO does not belong to this layer at all (and should be hidden behind another service interface).

Systinet Standards Blogger

Jacek Kopecky, Systinet's standards guru, has a blog. Great news - subscribed!

March 30, 2004

Are XML, SOAP and UDDI all the same?

Carlos Perez considers XML's fallacies revealed. I totally agree with the XML-sucks-as-a-programming-language mantra. XML Schema has its minor share of problems, to say the least. But with the reference to the Victoria Livschitz article (I've linked to it before), I wonder why SOAP (which I consider pretty good) and UDDI (which has its own problems, too, but none of them related to this discussion) enter the mix?

March 29, 2004

BPELJ madness

IBM and BEA have published a whitepaper about a combination of BPEL with Java, named BPELJ.

I fully agree with Edwin Khodabakchian that this is a totally bad idea. I have a hard time accepting XML for building programming language-like constructs, anyway; but actually combining an XML process language while requiring another one as well seems to be totally wrong.

March 22, 2004

What did Bob Sutor Smoke Before This Interview?

The mod-pubsub blog has a pointer to a very enlightening interview with IBM's Bob Sutor. Here is his explanation about what an SOA is:

SOA has been around a long time, since the client server in the '80s. As a subset of object-oriented programming and design, SOA was clearly in there. And there was a glimmer of this a few years ago, when Java was coming out. Certainly, everyone in the universe used Java. But it was the Internet and XML that made this fully possible, so today, it is characterized by saying it is distributed computing. It is loosely coupled, which means that you have very little knowledge about the actual construction of the services.

It is defined by standards that have actual descriptions of how you talk to it and how it talks back to you.

You use the same language to talk about all these interfaces--specifically, this is Web services description language, and that means that you can start leveraging common registries for services.

You can look up, "How do I talk to this version of a particular thing?" Tools start becoming much simpler, because if everything you want to use is described in the same language, you can start dragging and dropping these different things and threading them together much more easily.

Er ... Huh?

March 21, 2004

Anne Thomas Manes

Anne Thomas Manes's blog was totally dead for quite some time — now she seems to have put it back to life. Very nice.

March 20, 2004

Web Services Architecture Camps

Jeff Schneider has a great post on what he calls the three camps when it comes to web service architectures — The SOA guys, The Bus guys, and The Protocol Network guys. I believe one category is missing: The REST guys, who basically believe the rest should stop inventing new stuff and use what's available and actually has been working for quite some time.

March 19, 2004

InfoPath updates

Aaron Skonnard writes about Infopath's new features (currently in preview). It seems the InfoPath guys even have their own weblog.

I really like the InfoPath concept. Too bad there's nothing comparable for my operating system of choice.

Web Services Version Strategy at Reach

Chris Ferris (whom I sadly can't link to correctly, since his RSS feed does not include the permalink to his entry and his blog is next to unnavigable) points to a very well designed services/messages versioning policy (it seems Sean McGrath had his hands in it).

SOA is like the Night Sky

A very interesting post by Microsoft’s Pat Helland that emphasizes the difference between exposing internal data transactionally vs. message-based. I tried to make some of the same points (I think) some time ago.  

[via Savas' blag]

March 18, 2004

1060 NetKernel Article on TheServerSide.com

A very readable article on TSS about the 1060 NetKernel (I briefly mentioned it some time ago).

From a business perspective, I find the dual license model they use pretty interesting.

The author, Peter Rodgers, also has very thoughtful answers in the associated discussion thread. My favorite:

As a general observation. Our feeling is that with the XML-service world, the application must eventually handle the XML message no matter what the protocol. For many XML processing problems we've found that the later you bind to procedural objects the better - ie when you have the choice, keep your system loosly coupled.

Amen to that.

Linda and the Web

Mark Baker believes that something very Linda-like — the World Wide Web — changed the world. I'll assert that the Web changed the world, no problem. I fail to see how this claim is true, though, since I don't particularly see the Linda (tuple spaces) approach actually being used in the way the Web is (mostly) used today.

True, there's the uniform interface idea, which is in action even when I use my web browser to buy a book at Amazon.com. I don't see the spaces idea applied in program-to-program interaction very much, though. That's not to say that it would be a bad idea, on the contrary. It's just not this aspect that made the Web the success it is, IMO.

At least one vendor is very heavily moving in this direction, though; I'm very curious in how this will work out.

ZapThink on Web Services/SOA markets

From a ZapThink report:

Here's the hard truth: there are no permanent Web Services or SOA "markets." Web Services are interfaces to software, not software itself. SOA is architecture, which means the organization of software and other resources, not those resources themselves. The markets for Web Services and SOA products and services we do have are transitional -- that is, arbitrary categories brought to life to add definition to markets in transformation. Once companies figure out
what Web Services and SOAs are really for, such temporary markets will evaporate as quickly as the online underwear pure-play.

An interesting read, even if you don't happen to agree.

March 17, 2004

Vinoski on Web services notifications

Via Mark Baker, I came across this very nice article by Steve Vinoski on Web services notifications.

March 10, 2004

WS-ReliableMessaging

A new version of WS-ReliableMessaging has been published.

March 09, 2004

Jim Webber on Loosely Coupled Web Services

Via Mark Baker, I came across Jim Webber's blog - and across this excellent article highlighting the differences between Distributed Objects and Loosely coupled Web services.

SOAP and HTTP GET

An interesting DeveloperWorks article about the SOAP 1.2 support for HTTP GET, and some comments from Chris Ferris. I don't agree with all of them; e.g. I think if you are using a Web services toolkit, you are going to want to use it for all kinds of requests, and not have different implementation technologies for different semantics.

Web Services: Avoiding APIs

I've spent some time thinking about the pros and cons of using APIs vs. using standardized wire formats, prompted by a whole bunch of references to this issue - by Don Box, Dave Orchard, and Sean McGrath. It's becoming more and more clear to me what the advantages of standardizing on the wire formats are, so I thought I might as well share some of my ideas. Feedback, as usual, is very welcome.

So what's the issue? I believe that when you take your first look at Web services, and have a strong background in Distributed Objects, or other, older RPC-based technologies, you get a strong feeling of déjà vu. After all, isn't this all just CORBA or DCOM reinvented, with a different wire protocol? What could be the advantage of using a fat, text-based format instead of a nice, binary, efficient protocol like DCE RPC, IIOP, or plain RMI? Why would anyone in their right mind even care about what the bits you send over the wire look like?

You might be tempted to support Web services standards, most notably SOAP, just as another, additional transport. Create a common API, and use it to send messages via RMI, CORBA, or JMS - without having to change anything in your application code. Have custom transports, and plug them in as needed. Isn't this the best possible strategy?

Unsurprisingly, I think the answer is: no - on the contrary, it's the worst thing you could possibly do.

First of all, there is an architectural difference between the way applications should be designed for tightly coupled vs. loosely coupled interactions. This is mostly related to the granularity of your services, as opposed to the granularity of your components' or objects' interfaces. While I believe this argument to be strong, it's not really related to the technology being used - you can just as easily build a loosely coupled system based on, say, JMS. In fact, I have seen customers do exactly that - independent components on a common bus, with the ability to add and remove components that listen and send to specific topics or queues, allowing for great flexibility in system evolution.

But there is another aspect, and a downside that seems to be less clear: Standardizing on the API doesn't buy you very much in terms of interoperability.

Let's say you standardize an API used to access services (or objects or whatever) that reside somewhere in your infrastructure. The effect is that you have a high interoperability between the partners that use the same API. You can change the API implementation, and everyone using that API will be interoperable again - in the cases where you use dynamic linking, this will happen instantaneously.

But what about others? What about third party products, or products developed in different departments of a large organization? Do they use the same API? Are they even developed in the same programming language, and if not, do you have an implementation of the API for that programming language as well? How sure can you be that even if you have one, it's in sync with the other implementations?

With a protocol like IIOP (which is what CORBA and J2EE use for transport), there is simply no way you could standardize the message on the wire format level. There's no easy way to describe it, and the only way to make sure everybody can interoperate is that you use the same CORBA version and 100% compatible implementations. Of course, CORBA interop has become a lot better in the last few years. But problems always occur when the underlying format needs to be changed - as is the case e.g. for transactions (with the need to propagate a transaction context) or security.

The beauty of SOAP - wow, that alone should have somebody flaming me - is that it actually makes it very easy to standardize on the format level. XML in general, and SOAP headers in particular, are very easily extensible. Basing your interop standards on a certain kind of SOAP message, including standards-based and non-standards-based headers, yields interoperability on the wire level. This in turn, enables a C++ app to talk to a Java or C# one, and if there's anything e.g. in the SOAP message's header that is specific to a certain type of application or interaction, implementations that don't understand this header can simply ignore it. With the level of support from a standardization perspective — after all, other people are likely to experience the same problems that any given organization does, so it's likely there'll be a common standard at some point in time —, and with more and more applications that provide SOAP interfaces out of the box, integrating applications becomes an order of magnitude easier.

February 29, 2004

Quicklinks

A bunch of quicklinks I'm too tired to blog about in detail:

• Aaron Skonnard: Using MessagePredicate for WebMethod Validation
• Fabrice Marguerie: Getting a little closer to SOA
• Bill de hÓra: Under the hood at PubSub
• Jason Clark: Inside "Indigo," Chapter 2: The Journey of a Message
• Qanyon.com: Qanyon World Factbook - A Distributed Rich Client Application

UML or XML Schema for Common Types?

Mark Ericson commented on a blog entry from Adam Blum regarding the usage of XML, or to be more specific, XML Schema, to describe common business types:

XML schema is one of many concrete ways of representing the types, there are certainly many others including our programming languages and database schema. [...] I haven’t thought of myself as a UML evangelist, but perhaps UML can provide a richer type modeling environment that promotes type reuse and can be mapped to both XSD and the ‘layered standard’ when needed.

I totally agree with Mark. In his answer, Adam (who actually alerted me to this comment, claiming it could have come from me ;-)) suggests that UML should be used by shops that are doing it anyway, while using XSD seems to become the default way of doing this.
I disagree with Adam: I strongly believe that it's foolish to believe that common business types specified in XML Schema are a good idea if you are concerned about protecting your investments in the future. XSD just happens to be extraordinarily popular right now; and in time, it will be replaced by something else (RelaxNG? Schematron? Something totally different? Who knows.) In addition, XSD, even when combined with WSDL and the whole bunch of WS-* standards, is only a small part of your common business knowledge (the service interface layer), and captures zero information about your implementations.
Thus, I strongly believe that a common business knowledge repository should be on a meta-level, and be used to generate other representations — with XML Schema just being one of them, while others could be SQL DDL, Java, C#, or whatever your current technical environment requires.

February 28, 2004

WS-Eventing Feedback

Werner Vogels has a very interesting summary of the WS-Eventing feedback workshop.

February 24, 2004

Duck Typing

An utterly brilliant article by Sean McGrath. Incidentally, I see this when I'm in the middle of a very interesting e-mail discussion regarding my own post regarding XML and typing.

February 22, 2004

REST interface constraints

Bill de hÓra (one day I'll find out why I can't enter his name properly) has an interesting post about the debate kicked off by Russel Beattie:

I take the opposite view to Russ; not having mainstream availability of PUT and DELETE is the singularly most broken aspect of web technology today.

I like REST, and I believe that Russ's problem is a stupid omission in the J2ME standard, not a fault of the Atom spec. On a purely theoretical side, though, I wonder whether there really is a difference between having a uniform interface that contains just two verbs (GET and POST) and one that contains all four (DELETE and PUT as well). Isn't the point that the interface is constrained, not that it is constrained to something specific? You can't avoid a certain amount of overloading, no matter whether you have 2 or 4 or 10 verbs, since there's more than 2 (or 4 or 10) things you will want to do.

SOA: Elements of Good Design

Via the SOA mailing list, I came across this article that appeared in business integration magazine. It's nice to see that people start writing more than introductory texts on SOA, although I did not find anything particularly new in this one — I am reminded of the beginning of the J2EE hype 4 or 5 years ago, where it took people some time to gain enough experience with the technology to write about architectural issues and every text written about the topic was essentially the same ...
One issue discussed in the article came up multiple times in my own work in the last few weeks: Whether or not to use UDDI to enable an SOA, and if one decides to use UDDI, how to solve the registry vs. repository issue; I'll follow up on that in another post.

February 21, 2004

XML, Type Systems, and Programming Languages

Dare Obasanjo writes about the impedance mismatch between XML Schema and the CLR type system (where you could easily substitute the CLR with Java's or any other statically typed OO language's type system). Interestingly enough, Sean McGrath has a post about an impedance mismatch, albeit on a higher level.
The more I think about it, the more I believe that the idea of using XML as a simple object serialization format for statically typed languages is fundamentally flawed, at least in the context of loosely-coupled, service oriented system architectures.

February 20, 2004

Vinoski blogs

IONA's Steve Vinoski has a weblog, which is great news.

An introduction to REST-based Web services

Roger Costello has written an excellent introduction to building Web services in a RESTful way. I wish he had gone into more detail regarding the way you describe REST services with WSDL; other than that, it's very easy to understand and highly recommended.

February 18, 2004

WS-Discovery

BEA, Microsoft, Canon (?) and Intel have published the WS-Discovery specification:

This specification defines a multicast discovery protocol to locate services. The primary mode of discovery is a client searching for one or more target services. To find a target service by the type of the target service, a scope in which the target service resides, or both, a client sends a probe message to a multicast group; target services that match the probe send a response directly to the client. To locate a target service by name, a client sends a resolution request message to the same multicast group, and again, the target service that matches sends a response directly to the client.

February 17, 2004

Web Services and the Semantic Web

Dave Orchard suggests using the semantic web to solve tactical problems:

I think that if SW folks want to convinced WS folks to use their "stuff", they really need to do a better job of showing short-term benefits. And that means really understanding the "customer", ie Web services.

Events, Eventing and Notification

Werner Vogels has a nice, high-level overview of WS-Eventing, WS-Notification and WS-Events (I never even heard about the last one).

February 15, 2004

WS-Eventing

Microsoft's Bruce Williams has written an introduction to WS-Eventing for dummies: part 1 and part 2 [via Aaron Skonnard]

REST and Atom

Russel Beattie, occasionally pretty informative, writes a post which is amazingly clueless. The only reason for mentioning it is that the comments to it are very entertaining. I hereby declare Sam Ruby my role model for blog conversations.

February 13, 2004

REST-based (?) Micro-Kernel

Carlos Perez pointed to 1060 Research, makers of a product called NetKernel. They have an interesting whitepaper that is worth reading.

WS-ReliableMessaging, WS-Addressing Implementations for Apache Axis

Via Jorgen Thelin I came across WSFX, an Apache project to create open source WS-* implementations. It seems to be in its infancy, but there are already subprojects for WS-ReliableMessaging (Sandesha) and WS-Addressing.
I strongly believe that support for asynchronous interactions is a critical factor to deliver on the Web service promise of Loose Coupling, and for wide-spread acceptance of any standard, having an open source implementation is great.

February 10, 2004

Look Ma, no SOAP

Via the XML Cover Pages, I came across this nice, clean spec:

XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP is not a new protocol. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP.

February 09, 2004

XDI - the Dataweb

I had never heard of this before (not sure whether I need to feel ashamed now) and came across XDI due to Mark Baker's post. I just speedread the whitepaper, and I believe in this case, he has a point — it doesn't seem obvious how this differs from the Web so much as to merit a complete set of new standards (as if we didn't have enough of those, already). The notion of automatic synchronization between resources seems interesting, though; I'm not sure whether a purely Web/REST-based approach to this exists somewhere ...

Messages and Documents

An interesting discussion got started by Mark Nottingham and triggered responses fromMark Baker, Patrick Logan and Sean McGrath. I have yet to be convinced that preferring messages/document/files over APIs in general is a good idea — it works very well in simple cases, but leads to a high dependency on internal structure in more complex ones. APIs, at least high-level ones, are there to offer a layer of abstraction. Connecting to the underlying files (or database, for that matter) can lead to a very brittle connection unless the mechanism is explicitly designed to be used for interoperation.

February 06, 2004

(Not) Using XML 1.1

Dare Obsanjo has some strong statements about XML 1.1:

XML is a lousy format for most of the things it is used for. The one benefit it has is that it is widely supported and a guaranteed way to interoperate in a cross-platform manner. By tampering with this the W3C is effectively diluting one of the few benefits of using XML. This is an regrettable occurence. Unfortunately it looks like things will get worse now that the W3C also wants to dabble in “binary XML”.

I wholeheartedly agree with the statement about binary XML, and strongly suspect he is right about the rest as well ...

Pass by Reference in Web Services

Jeff Schneider continues his search for answers on how to do pass by reference in Web services.

I believe pass by reference is impossible when doing Web services.

Some time ago, I had a long and heated discussions with a customer and several colleagues about whether Java does pass by value or pass by reference, where we were evenly split among the views that there is only pass by value on the one hand, and only pass by reference on the other hand. (Incidentally, while looking for a normative definition, I came across an article that shares my point of view - Java does pass by value only. Really. Think about it.)

To me, pass by reference semantics only make sense in the case of programming languages - it's a syntactical issue that you put a variable in place of a formal parameter, and the language implementation (compiled or interpreted) passes a pointer to the variable instead of the value. I believe anytime you make a copy of some data - which is unavoidable if caller and callee don't reside in the same address space - you can't do pass by reference.

Of course I concede that a Web services-based language might offer some sort of syntax to pass pointers under the covers, but that would probably be a bad idea and only lead to subtle bugs. Better to pass references - and pass them by value.

Web Services and Sessions

I wonder how I missed this article by Sergey Beryozkin.

New in SOAP 1.2

The W3C has a nice document describing the changes from SOAP 1.1 to SOAP 1.2. There's also a whole list of updated W3C recommendations:

• Extensible Markup Language (XML) 1.1
• XML Information Set (Second Edition)
• Namespaces in XML 1.1
• Extensible Markup Language (XML) 1.0 (Third Edition)

[found via Christan Weyer]

February 04, 2004

NetKernel - a Java-based virtual REST OS

Mark Nottingham links to NetKernel. Quoting his quote:

NetKernel is a Java-based virtual REST operating system for internet applications. NetKernel is a scalable microkernel which implements a modular REST abstraction in which all software components are URI addressable REST-services.

That sounds very interesting indeed.

NetKernel - a Java-based virtual REST OS

Mark Nottingham links to NetKernel. Quoting his quote:

NetKernel is a Ja links to <a href="va-based virtual REST operating system for internet applications. NetKernel is a scalable microkernel which implements a modular REST abstraction in which all software components are URI addressable REST-services.

That sounds very interesting indeed.

REST vs. SOAP (again)

In a very interesting posting, Mark Baker points to an age-old thread (four years old, to be exact) that I find utterly fascinating.

January 31, 2004

REST and MVC

A very good article by Bill de hOra: REST Wars.

January 30, 2004

Message Passing

Dare Obsanjo writes about James Robertson's comments on SOA vs. Distributed Objects:

It is just an unfortunate naming collision that some object oriented languages use the term 'message passing' to describe invoking methods on objects which I'm sure is what's confused James Robertson given that he is a Smalltalk fan.

While I agree with almost everything written by Dare here, I have one issue: I'm by no means a Smalltalk expert, but AFAIK, there is some conceptual difference in this regard between different types of OO languages. One of the coolest features of Smalltalk seems to be the doesNotUnderstand message. In fact, my respect for Smalltalk was renewed by one of Dare's colleagues.

January 28, 2004

MS SOAP Toolkit is Dead

From MSDN, found via Simon Fell:

The Microsoft SOAP Toolkit is deprecated by the .NET Framework. The toolkit provides basic Web services capabilities for COM components and applications. SOAP Toolkit support will be retired on July 1, 2004. For the latest on supported technologies for developing Web services, visit the Web Services Developer Center on MSDN.

January 20, 2004

Providing Compatible XML Schema Evolution

Dave Orchard points to an article he wrote about what can and could be done to provide compatible evolution of Schemas.
Update: Dare Obasanjo has a very interesting follow-up.

January 15, 2004

Don Box on Indigo

The newly launched TheServerSide.NET has a 40 minute long interview with Don Box. Highly recommended. If only the content at TheServerSide.com had similar quality ...

January 14, 2004

Web Services and Distributed Objects

Dave Orchard writes about the difference between Web services and Distributed Objects. He has a very nice explanation about the problems with XML schema extensibility, something that I found to be an unsatisfactory solution to Web services versioning when I wrote about Doug Purdy's movie on MSDN.
Before I learned better, I thought that you could validate an XML document against a schema and it would still validate if there were additional elements that were in different namespaces. Sadly, this doesn't seem to be the case. If it were, I believe things would be a lot easier ...

January 12, 2004

Loose Coupling

Patrick Logan points to an interesting post from Carlos Perez which contains this fragment:

In general, a relational database provides a fixed, queried, self-describing, lazy evaluated system that is inherently loosely coupled. It's surprising that it's perceived to be more tightly coupled than a component based system.

One can certainly build very loosely coupled systems by using an RDBMS as the shared storage area. The problem is that this will only work if the systems and the common schema they share have been designed for this purpose. For example, it would be pretty easy to connect a whole bunch of systems to an RDBMS and use some TupleSpace-like stored procedure API.
What you need to make sure, though, is that you don't use the data-oriented integration strategy that has currently become so popular as an excuse to expose your implementation details, of which the RDBMS schema — at least in the most of the cases — clearly is one.

January 08, 2004

WS-Eventing

Mark Baker has written about WS-Eventing (try the first link if you see an empty page). It seems to me that the whole REST/WS debate comes down to the discussion whether SOAP should take advantage of the underlying transport/transfer protocol. In fact, it's probably all about whether it is a transport or transfer protocol. For Mark, it's stupid that the SOAP/WS-* specs ignore what HTTP has to offer from a transfer protocol side. The reason, of course, is that SOAP aims to work equally well over different protocols. While this might be achieved by exploiting the features of each different protocol to the largest degree possible, I can understand that one might view this as not worth the resulting confusion — the benefit of the current approach is that things look very similar, regardless of whether you're using HTTP, SMTP, JMS, or some sort of proprietary transport (like TIBCO).
It's interesting to note, though, that Mark also attests that WS-Eventing does a lot ofsome things the right way.

January 07, 2004

WS-Eventing

Microsoft, BEA and TIBCO have published Web Services Eventing (WS-Eventing) (what kind of word is "Eventing"? Oh, well):

This specification defines a protocol for one Web service (called an "event sink") to register interest (called a "subscription") with another Web service (called an "event source") in receiving messages about events (called "notifications").

The CORBA Notification Service gets reborn ...

January 04, 2004

Sad demise of former gurus

I used to hold Robert Martin in high esteem - back in the days when I was still doing C++, and his was a very pragmatic approach to OOP. But crap like this has made me change my mind.
Take this, for example (on Web services):

Of course it couldn't be just remote procedure call. It had to be remote object invocation! We can't just have functions and procedures, we've got to have objects. Functions are just to passe. Objects are where it's at.

Oh my ... what has this got to do with reality? Who claims that Web services has got anything to do with objects?
Robert: Get a clue.

Old Truths Still True

I skimmed an old JavaSpaces book, and came across a reference to a paper I had recently searched for, but was unable to find because I couldn't remember author(s) or title. It was the famous Note on Distributed Computing from Jim Waldo et. al., dated 1994:

There are fundamental differences between the interactions of distributed objects and the interactions of non-distributed objects. [...] Work in distributed object-oriented systems that is based on a model that ignores or denies these differences is doomed to failure, and could easily lead to an industry-wide rejection of the notion of distributed object-based systems.

How true.

December 29, 2003

WS & Santa Clause

Sean McGrath has written a very nice and RESTful christmas story.

December 21, 2003

Visitors from the Czech Republic

Last Thursday and Friday were extremely interesting — we had asked our friends at Systinet for an in-depth workshop on WASP's advanced features, and Radovan kindly sent us three of the core developers. It was great fun spending two days with Tobbi, Mirek, and Jirka, and once again I was impressed by the level of expertise everybody working for that company seems to have.

Now we'll have to put our newly-gained knowledge about writing custom serializers, transports, and the intricacies of WS-Security to work ... this product is really, really cool, and I can't wait to get my hands on the other stuff that Rados currently only hints at :-)

December 15, 2003

Information Hiding in Web Services

Radovan has written an interesting piece entitled Flying Data and Business Process, which reminded me of some thoughts I had a while ago.

If you look at some of the stuff written about Web services, or XML in general, you might get the feeling that there is a huge conflict between different views on how to architect systems "the right way". I don't believe that this is necessarily the case; I'll try to elaborate a bit.

If you follow accepted design patterns in an object-oriented approach, you are likely to hide a lot of detail between interfaces. Objects are responsible for doing something; what private data they use remains hidden to the outside user.

A component-based approach enhances this idea by creating components as larger entities (in the broadest sense of the term) that hide a lot of both operations and data behind a few, coarse-grained methods. It's a pretty well-accepted fact that this coarse-grained aspect is a critical factor for achieving useful component abstractions; this is enhanced enormously once you are talking about components that can be invoked remotely, as the cost of operation invocation becomes ridiculously high.

What, then, is a service? Does it have the same granularity as a component, as approaches that simply turn J2EE session beans into SOAP-accessible service implementations seem to suggest? I don't think that this is the right way, and I seem to be not alone with this view. The emphasis on data in more advanced service approaches shows that for one, the granularity is even higher, and additionally, that the data becomes much more important than a set of operations.

Should we thus abandon OO and CBD approaches? Is the answer to expose all of our data in the form of XML documents?

Unsurprisingly, I don't think so.

Just as once you are talking about components, it becomes irrelevant whether you have implemented your component with a procedural or object-oriented language, a service consumer couldn't care less about that type of component or app server or runtime environment you used to implement your service. But still, this doesn't mean that you should simply expose all of your implementation data, since this is going the tightest coupling one can imagine — a coupling between a client and the utmost implementation detail: the persistence schema.

So what am I getting at?

My view is that while the by now classic approach of hiding information and exposing only the absolute minimum still holds true for the most of the data, you should treat the data used for interaction in a loosely-coupled scenario differently. Objects are an excellent implementation technique. Components, especially those deployed in an advanced infrastructure, such as a J2EE application server, greatly enhance your productivity by freeing you of tedious middleware-related tasks. But neither are in any way appropriate for communication across company boundaries, and this is the place where you should aim for very few, document-oriented service interfaces.

December 08, 2003

REST questions

In Learning to REST, Adam Bosworth asks some very good questions about rest. I'm very curious about the answers ...

December 04, 2003

FABRIQ

Clemens Vasters has provided some interesting background on a project he is currently working on.

I believe that what can easily be seen is that the overall architectural patterns, let's say: the meta-architecture, really doesn't differ that much — whether you are using C, C++ and CORBA, combinded with the Event or Notification service, J2EE/JMS, MSMQ, or any other bunch of technologies.

Pluggable services in a web services bus

Adam has written about Pluggable services in a web services bus. Very interesting. Some comments over there — sadly, Adam has not enabled trackback :-(

December 02, 2003

Web Services and Humans

Jon Udell has written a short article about Web services and human interaction.

This is clearly one of the big chances for advanced Web services solutions to differentiate themselves from classical middleware — the availability to plug humans into machine-driven processes to handle exceptional conditions.

However fancy your transaction policy, however advanced your error handling implementation might be — in some cases, there is simply no replacement for having a human look at a situation and apply good old common sense to solve problems.

November 26, 2003

(Hopefully) Constructive Feedback on Mark Baker's Article

Update: Mark Mark responded; I'll try to comment ASAP.

I have to admit that the last post about Mark Baker's article was a bit harsh — and definitely did not contain much constructive criticism. So I probably deserved the comment I got from Mark. Let me try to go into more detail about the problems I have with what Mark has written:

As a proponent of using the REST architectural style for Web services development, I've often been frustrated when I hear REST dismissed out of hand as a solution for some problems, while at the same time, "document style Web services" are deemed amply suitable for it. This frustration stems from my view of REST as a generalization - an "uber architecture" of sorts - of coarse grained, loosely coupled, document oriented approaches to application integration, which suggests to me that anything that can be accomplished with document style Web services, can be accomplished within the constraints of REST, and in a not too dissimilar way either.

Up to this point, I totally agree. I don't claim to be an expert in REST in any respect, but from what I have gathered about it so far, it definitely seems that the ideas behind REST are applicable for a lot of scenarios.

In this essay, I'll describe how core features of the Web relate to document style services, and in doing so, will describe how to build the Web with Web services.

Wow! This is going to be a great article — finally somebody who gets both REST and whatever-you-want-to-call-non-RESTual-services, is going to explain the differences and similarities! I'm thrilled.

What a document isn't, at least by the (IMO, accurate) use of the term in a Web services context, is a bag-o-bits which isn't asking anything of anyone; the current time, a purchase order, a signup sheet for pickup floor hockey.

Er ... well, I think I can see the point, but I can't really make sense of the examples. So, a purchase order isn't asking anything from anyone? That can't be true — so obviously, these are counter examples - a purchase order is asking something. Looking at the paragraph, even for some length of time, I have problems finding out what exactly Mark is getting at - I fail to see the similarity between a pure piece of data like current time and a very concrete, business level document like purchase order. Arguably, it's just not phrased very clearly, or maybe it's because I'm not a native English speaker.

They aren't asking anything of anyone, because their job is simply to capture state; a signup sheet captures the state of those who desire to play, a purchase order captures the state of the desire of a purchaser to acquire some goods or service, and the time, well, communicates the state of some clock.

Now I'm totally lost. (Again, probably my English.) A purchase order isn't asking anything of anyone, if just captures the desire of a purchase to acquire some goods or service? When I write a purchase order, I clearly ask the supplier to deliver some sort of goods to me. How can this not be asking for something?

Documents are state.

OK, I'll buy that and move on, there's surely going to be some more detailed explanation about this later, right?

When dealing in documents/state, a designer often finds it useful to be able to know which documents are about the same thing. For example given two documents representing the state of some business process, it's quite useful - and often necessary - to be able to determine if the two documents are both of the same business process even though they differ due to, perhaps, being snapshots taken at different times.

Although I don't consider "quite useful and often necessary" to be enough of an explanation, I agree, so let's move on:

There is more than one way to address this problem, of course. One way would be to include information in the document which could be used to uniquely identify the business process; the parties involved, the time it began, etc.. While this has its advantages, it also has two large disadvantages; the inability to support alternate formats (e.g. images) which can be used to represent the state of the same business process, and that those identifying characteristics are known only to software which also knows the format. That latter problem would prevent, for example, a generic caching mechanism.

I almost wrote another "I agree" below this quote, but then I thought a bit about it. While Mark obviously was thinking of content negotiation, support for Expired headers and so on, he doesn't talk about it at all. How is anybody supposed to make sense of that?

I'm also left with the question of what, exactly, the advantages of the first approach are ("... has its advantages ...").

I'm fine with the transfer/transport distinction. But then Mark goes on:

And of course, what one could achieve with the "PROCESS-THIS" (aka POST) and "STORE-THIS" (aka PUT) operations would require that the protocol that defined these operations be used. They wouldn't be "protocol independent".

So what? Is this an advantage? Or a disadvantage? How am I suppose to make sense of this remark, unless I have previously made up my mind on the question of REST/HTTP vs. SOAP/anything?

In the next paragraph, the point seems to be that GETting documents from somewhere might be useful too. I just have to agree.

OK, I'm a bit puzzled by now, but surely things are going to be clarified in the next few sections. (Seriously, that's what I thought when I first read the article). Imagine my surprise when I saw that the next paragraph's title is Conclusions:

The relatively recent shift away from RPC and towards "document exchange" (aka state transfer) is extremely welcome progress for this POV, but IMO, just the first step of many towards fully appreciating the enormity of the World Wide Web project.

In a conclusion, it makes sense to combine some of the preceding text's contents and present them in the form of a summary. Now where was the "recent move away from RPC and towards document exchange" mentioned before? Who made this move?

So here's is my conclusion: Maybe Mark is so smart that he just can't explain things that he considers to be obvious to everybody. (Maybe the article was, as he explained, really written for people he has already exchanged opinions with for hours.) So perhaps Mark really has a lot to say, and I just fail to understand it. Then again, perhaps not.

Building the Web with Web services

Mark Baker has written an article on his O'Reilly weblog, and says:

If this doesn't convince you, I don't know what will.

I hate to say it - but this article is just crap. When I initially subscribed to Mark's blog, I did so because he was frequently mentioned as a well-known REST proponent. Following his writings, I got the feeling that either I am simply too dumb to understand all the references to some greater, hidden, from his point of view, obvious things; or alternatively, there is nothing deep hidden beneath the shell he creates.

I have long suspected so, but now I am finally convinced that in Mark's case, the emperor really has no clothes.

November 22, 2003

Binary XML

I have commented on this before, so it's nice to see Dare Obasanjo's comments on Microsoft and Binary XML. I strongly believe that this path is not worth pursuing. That is not to say that I don't consider Indigo's approach to optimizing communication between the same WS stack's instances flawed in any way - on the contrary, I think it would be great to have something similar in other stacks, as well. Standardizing a binary protocol, though, is cleary a step backwards, IMO.

November 18, 2003

Coarse grained

I see that Systinet CTO Adam Blum has moved his weblog to TypePad, which is cool. Finally having subscribed now, this is definitely a weblog I'll watch very closely.

If you have not yet seen it, it's definitely worth a look - I have high hopes that there'll be some very interesting discussions in the future about Adam's views.

I only wish he would drop the "I'll be posting on this topic fairly soon." standard last sentence ;-)

November 04, 2003

Documents and Web services

Jon Udell has written a piece about WinFS. I don't really care that much about what kind of product Microsoft will ship in the year 2006, but one paragraph just hit right on the mark again:

Finally, I've drawn attention to a remarkable synergy that InfoPath, most notably, makes possible. The message payloads exchanged on the Web services network, and the documents read and written by people, can be the same texts, governed by the same datatype and structure definitions. And those texts are universal in scope, not tied to any platform or framework. True, InfoPath is a Windows-only creature, but since it's built on open standards, InfoPath-like software can exist on other platforms and can interoperate with InfoPath.

Yes, exactly. Sadly, I'm still waiting for that other tool to show up somewhere ...

November 03, 2003

Adam Blum, CTO, Systinet

Adam Blum, CTO of Systinet, has a blog called Coarse-grained. I met Adam a few weeks ago and greatly enjoyed our discussion - looking forward to a lot of interesting thoughts.

October 19, 2003

Server state and REST

Bill de hÓra writes about the Web scalability myth:

The ideal multi-server model is where state is manged on the client. It's the one place on a client-server or service oriented network topology where a single point of failure is ok (think about it). Now, this idea, this management of state of the server is also where the deployed web (HTTP browsers) breaks with REST architecture.

Exactly! Very cool that this comes from a REST proponent. When I try to explain what REST is about, and get to the part of the story where I mention that it's not keeping state in server sessions what makes the Web's architecture so great, experienced developers look at me with doubtful eyes and wonder what the hell I'm talking about, with most of them having spent numerous days of their lives circumventing HTTP's statelesness by means of server-side state ID'd by cookies or session rewriting.

Maybe it's fair to say that REST is what the Web should have been. To use the existing Web as an example for a successful, RESTful system, might just be bogus.

SOA vs REST

Dare Obasanjo on SOA:

So where are we now? Well, it seems that XML Web Services are now passe and Service Oriented Architectures are in. To an XML guy like me, this is great because it means that I can now build RESTful XML Web Services and still be buzzword compliant. No more hiding XML behind objects that don't map properly to the data and clunky RPC-encoding schemes for me.

Interesting. I wonder whether it's really SOA vs. RESTful XML Web services - to me, these are orthogonal concepts.

September 11, 2003

Java and Web Services are not a match made in heaven

The more I think about this, and read about it, e.g. here, or here, or think about it in this context, the more firmly I believe that Java, or any strongly typed programming language, is not a good vehicle for building document-oriented Web services. If you contrast the standard Java APIs for SOAP (yes, I know Web services and SOAP are not equal, but anyway), it's obvious that JAXM, while a lot more flexible than JAX-RPC, is also extremely tedious to program. If you compare this to e.g. Aaron Swartz's xmltramp, Sam Ruby's lazydom (both for Python), or Doug Purdy's Smalltalk solution, they combine the usability and elegance of accessing elements directly with the dynamics of not tightly coupling your code to a specific version of a document format.

My prediction is that either Java will somehow enable this, or be to Web services what C is to OO.

August 19, 2003

Web Services and Versioning

Radovan talks about Typing again, as a follow up on his entry on Versioning and Web services, inspired by watching the Microsoft video starring Doug Purdy. I finally found some time to watch it myself, and here are some thoughts about it ...

First of all, I really like Doug - for a knight of the Evil Empire, he shows a great sense of humour. I also love the Mac OS X poster on his wall - a sure sign of technical competence, expressed by his choice of operating system.

Doug presents four different alteratives about how to implement loosely coupled, resilient Web services:

1. Use an XSD Any type and just stream an object in its binary form
2. Use an XSD string and pass around the object's XML represenation in string form
3. Use an open content model and have the web method strongly typed (in his example, with "Person" appearing in the method signature)
4. Pass a DOM object though the interface

Doug's recommendation is to use the open content model variant, and it immediately seemed to make sense to me - at least as far as I understand it. That is because the other three options are clearly bad, because

• just streaming a binary representation of an object through SOAP bypasses all of XML's validation features, seems a totally inappropriate usage of the SOAP stack, and, first and foremost, totally kills interoperability;
• Using a string to pass around XML is marginally better, but still requires programmers on both the client and server side to work directly with XML - something that should be left to the runtime (after all, that's what one has it for, right?);
• passing a DOM is a bit better, but still removes the ability for the SOAP stack's tools to generate any meaningful client or server side skeleton code for you.

In addition, all of these three methods take meaning out of the XML Schema that is being generated (as part of or included from the WSDL). IMHO, one of the cool things about Web services is that you can see what the services do by looking at the WSDL. This is also key in enabling tools like Microsoft's InfoPath to create anything meaningful from the WSDL definition.

So there is a lot to be said for having strongly typed methods in your service implementation - the XSD will reflect the actual content types, tools will be able to generate a meaningful client and server ... of course the basic premise of Doug's presentation is to show how to come around the one major problem with this approach: Once you change your method signatures, you have to recompile the client.

So the concept of using an open content model seems to be a great way to address this. However, I don't think Doug's example is very good, and I'm also not sure how this can be translated into other SOAP stacks and programming languages.

The problem with Doug's example is that I don't think it really illustrates the problem, which I understand ot be this:

Assume I have a method like this:

  public void add(Person p);

with Person containing some fields in version 1:

public class Person {
  public String version;
  public String name;
  public int age;
}

and an additional field in version 2:

public class Person {
  public String version;
  public String name;
  public int age;
  public String address;
}

then what I'll want is to be able to have two different XML Schema definitions for the two versions. This way, I can publish version 1 at some point in time, and have consumers generate client implementations against that schema. Now the key is that once I upgrade the server to version 2, and publish the schema, I want both version 2 clients to be able to generate a client for version 2, as well as version 1 clients to be able to happily continue sending me version 1 persons.

I don't see any clear way how to achieve this. I'll need to play around with some code before I start making wild guesses ...

August 08, 2003

WSVT - the Web Service Validation Tools

via Christian Weyer:

The Web Service Validation Tools Project contains a set of Eclipse plugins that provide Web service validation functions. This includes plugins to assist in determining if a Web service conforms to the guidelines defined in a WS-I Profile.

more ...

June 15, 2003

XCAP

Taken from the draft XCAP spec:

This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP is not a new protocol. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP.

This sounds very interesting indeed - pure REST.

June 12, 2003

SOAP How It's Supposed To Be

IngoRammer.Com - Ingo Rammer's Weblog: SOAP how it is supposed to be, and how Systinet has been doing it for years.

May 06, 2003

The network is not the computer

Patrick Logan writes:

I do think the compensating approach is better than the atomic approach at the distributed business level of "transaction". But I am not sure either should be a part of the connection architecture. Compensation "meta-data" if you will should be a part of the documents exchanged among business partners, no matter how those documents are exchanged.

Exactly, and impossible to put any clearer.

April 22, 2003

Understanding the Web services stack

Sam Ruby's presentation from the ETCon: Tutorial

April 16, 2003

BPEL submitted to OASIS

Web services standards facing a split? | CNET News.com

Led by the three powerhouse companies, about 20 businesses will propose the creation of a technical committee within the Oasis standards body to standardize the Business Process Execution Language for Web Services (BPEL4WS), which is a language for automating complex business processes. The companies, which include SAP and Siebel, will make the submission to Oasis as early as Tuesday, according to the IBM executive. An official announcement from Oasis is expected in about a week.

April 14, 2003

Reliable Messaging and Web Services

MSDN has an article entitled Reliable Message Delivery in a Web Services World: A Proposed Architecture and Roadmap that outlines how several new Web services standards fit together to support asynchronous, message-oriented communications.

April 07, 2003

Very interesting debate about the value of SOAP

Sam Ruby: Bruce Eckel said SOAP sucks?

April 01, 2003

WS-Goodness

Web Services Goodness (WS-Goodness)

Microsoft Office 2003 Beta

Finally the Office 2003 beta, including InfoPath, has arrived. InfoPath looks really, really interesting, although I'm sure that I'll be disappointed once I know more about its details - this seems to be the case with MS apps for nearly everytime. Anyway, I hope I'm wrong, since it would be very cool if it turned out to be the first document-oriented Web services standard client out there ...

March 29, 2003

SOAP with Attachments

This document proposes a set of concrete idioms and conventions that clarify the processing model of SOAP Messages with Attachments, yielding the following enhancements: * Alignment with the XML Infoset-based data model and the SOAP processing model ￐ opaque data may be correctly processed by intermediaries and may be secured* Backwards-compatible message syntax ￐ every message conforming to this proposal is a legal SwA/1.0 message* Alternate message syntax for SOAP processors that have no knowledge of SwA or this proposal ￐ message content can be faithfully serialized in a form that is understandable by SOAP processors that do not comply with this specification

SoapScope

Don Box's Spoutlet has the info that SoapScope, which I wanted to take a look at for quite some time (Random Stuff: SOAP Debugger), has gotten a Jolt award. I'll have to buy it, after all ... this looks really cool.

March 28, 2003

WS-Reliability vs. WS-ReliableConversation

Apart from some thoughts regarding loose coupling, David Chappell talks a bit about the need for reliable messaging over SOAP. I think he has a pretty strange view in one respect: He makes it sound as if it was Sun's and the other WS-Reliability authors' mistake that we now have two specs. In my view, it's just plain stupid that IBM and MS did not just express their problems with WS-Reliability and jointly turn it into a decent spec. But maybe I'm just dreaming ...

March 19, 2003

Web Services Hype Cycle

I think this Gartner figure entitled Web Services Hype Cycle hits right on the mark. I have the feeling we might be a little further along the curve than originally predicted in 2002, but the form is still the same for every new technology being introduced.

March 05, 2003

NetWorkWorld on REST

NWW has an interesting piece on a RESTful approach to Web services.

March 01, 2003

Web Services-Stile: Dokument- vs. RPC-orientiert

SOAP unterstützt zwei orthogonale Konzepte: Den Stil (style), der entweder Dokument-orientiert oder RPC-orientiert sein kann, und das Encoding, das entweder "literal" oder "encoded" sein kann. Diese lassen sich im Prinzip beliebig kombinieren, tatsächlich relevant sind aber nur die Verknüpfungen "document/literal" und "rpc/encoded".
Diese beiden Varianten unterscheiden sich zunächst einmal auf einer rein technischen Ebene, d.h. sie bestimmen, wie genau die Informationen zwischen den Kommunikationspartner ausgetauscht werden. Dabei sind sie auf den ersten Blick nur ein wenig relevantes Implementierungsdetail.
Interessanter sind jedoch die Konsequenzen, die sich für die Architektur einer Web Services-Lösung daraus ergeben. Auf beide Bereiche gehe ich nacheinander ein.

Rein technisch lässt sich der Unterschied wie folgt erklären: Bei RPC/encoded wir SOAP verwendet, um genau die gleiche Aufgabe zu lösen, die man alternativ auch mit RMI, CORBA, DEC, RPC, DCOM etc. erledigen könnte: Es wird ein entfernter Prozeduraufruf durchgeführt. Dabei wird eine Methode (oder eine Prozedur) mit 0 bis n Parametern aufgerufen und gibt 0 oder einen Rückgabewert als Ergebnis zurück. (Dieser Aspekt wird durch das "rpc" in "rpc/encoded" gesteuert). Die Codierung der Parameter erfolgt in einer sehr simplen Art und Weise, die als Teil des SOAP-Protokolles definiert ist (der "encoded"-Teil). Dieses Verfahren ist für Entwickler mit Erfahrung in der Entwicklung von verteilten Anwendungen unmittelbar einsichtig und für die Hersteller von SOAP-Stacks einfach umzusetzen.
Bei "document/literal" wird ebenfalls eine Prozedur aufgerufen. Allerdings wird dieser ein Dokument zugesandt, und der Rückgabewert ist ebenfalls ein Dokument. Es gibt daher keine Beschränkung, wie komplex die Rückgabe ist. Die im document/literal-Verfahren versandten Dokumente sind durch ein XML Schema exakt beschrieben; die Codierung ist deutlich komplexer, aber auch mächtiger. Dies erlaubt auf der einen Seite z.B. die Validierung eines Dokumentes gegen das Schema, stellt aber auch größere Anforderungen an die Hersteller.
rpc/encoded wurde vor allem wegen seiner Einfachheit zu in Implementierung wie z.B. ApacheSOAP als primäre Variante unterstützt. Microsoft dagegen setzt schon seit langem auf document/literal.
Mittlerweile sind sich nahezu alle Anbieter darüber einig, dass document/literal die Zukunft ist und rpc/encoded sich als ein Fehler der Vergangenheit herausstellt. Warum? Um diese Frage zu beantworten, muss man den Sprung aus den technischen Details in die Bedeutung für die Architektur machen.
RPC-orientierte Web Services basieren auf der gleichen Architektur wie z.B. CORBA- oder J2EE-Lösungen. D.h.: Es wird eine Schnittstelle zur Verfügung gestellt, die eine Reihe von Methoden beinhaltet, die nacheinander aufgerufen werden, um ein bestimmtes Ziel zu erreichen.
So könnte z.B. eine Bestellung durch eine Folge von Remote Calls wie diese abgewickelt werden:

productFactory.findProductsByCategory("Washing Machine");
(... Darstellung des Ergebnisses, Auswahl von 2 Produkten aus einer Liste im Client ...)
order = orderFactory.create();
order.addProduct(4711);
order.addProduct(0815);
order.setBillingAdress(...);
order.setShippingAddress(...);
order.submit();

Beim ersten Blick fällt auf, dass es sich bei diesem Beispiel um eine "Conversation" handelt, auf Server-Seite also ein Kontext (Status) existiert, der clientspezifisch ist. Neben dieser (aus Skalierbarkeitsgründen wenig wünschenswerten Tatsache) gibt es noch einen anderen wesentlichen Punkt: Die einzelnen Parameter machen nur im Kontext Sinn. Bei 4711 handelt es sich um eine Artikelnummer; erkennbar wird dies aber nur, wenn man sich die gesamte Konversation ansieht.
Bei einem dokumentorientierten Web Service würde stattdessen die gesamte Bestellung in einem einzigen Dokument übertragen:

<test>
<order>
  <products>
    <product id="4711" />
    <product id="0815" />
  </products>
  <shipping-address>
     <...>
  </shipping-address>
  <billing-address>
     <...>
  </billing-address>
</order>

Mit anderen Worten: Das Dokument enthält sämtliche Informationen, die für die Durchführung der Bestellung notwendig sind - unabhängig davon, in welchen Einzelschritten diese von der anderen Seite bearbeitet wird.
Dokumentorientiere Web Services ermöglichen eine wesentlich losere Kopplung, unterstützen auch asynchrone Protokolle, erlauben die Bearbeitung durch mehrere Parteien (bzw. auch die Aufteilung der Arbeit zu einem späteren Zeitpunkt) - kurz: unterscheiden sich nicht nur implementierungstechnisch, sondern auch qualitativ von klassischen Distributed Objects-Lösungen.

Document vs. RPC-oriented Web Services

Phillip has asked me to write something about this in German - so that's what I'm going to do here. I'll translate stuff once I find the time.

February 27, 2003

REST + SOAP

REST + SOAP

SOAP Debugger

Another interesting article by Jon Udell: Debugging SOAP mentions a SOAP debugger developed by the makers of SoftICE. When I find the time, I'll definitely take a look at it.

Spontaneous Web services choreography

In The disruptive Web, Jon Udell describes how a few (non standardized) Web services were aggregated in a way never foreseen by the service providers. It makes very interesting reading and shows some of the potential behind the whole idea.

Combining SOAP and JMS

XML & Web Services Magazine - Making Web Services More Flexible

Why SSL ain't good enough

A nice article on XML.com, webservices.xml.com: Securing Web Services [Jan. 15, 2003], explains why SSL is not enough for securing B2B, web services-style communications.

February 26, 2003

Adam Bosworth's talk

In this paper, presented at the VLDB conference, Adam Bosworth, ex-Microsoft manager, ex-Crossgain co-founder and now VP at BEA, explains his view on ... well ... several things.

February 25, 2003

More UDDI stuff

Phil Wainewright describes how he view UDDI's role. Keith Rodgers goes into more detail.

Don Box on UDDI

In an article in his weblog (Coming to grips with UDDI) Don Box, Microsoft's Web services guru, shares his view on UDDI.

February 24, 2003

What's new in UDDI 3.0

What's New in UDDI 3.0 - Part 1
What's New in UDDI 3.0 - Part 2
What's New in UDDI 3.0 - Part 3

IDC estimate: $21 Billion Market for Web services by 2007

Web Services to Reach $21 Billion by 2007, says IDC.
I believe it to be very questionable whether the Web services market as such even exists.

Web Services Orchestration Tools

In an HP whitepaper, different approaches to Web services orchestration are described. I'm not really sure what to think about this. The question that puzzles me most is this: Do we really need standards like this? Is the combination of Web services really something that should be done any differently than the development of a new service or the wrapping of an existing system?

Phrased differently: Isn't it much more efficient to use some sort of scripting language to tie together several Web services to build a larger one?