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
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.