Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Categories of Web Service messages: data-oriented vs actio
 > From: Andrzej Jan Taramina [mailto:andrzej@c...] <snip/> > Roger proposes: > > > I have convinced myself that there are two fundamentally different > > approaches to designing Web service XML messages. They are: > > > > 1. The data-oriented approach > > > > 2. The action-oriented approach > > It's not just Web Services that has this paradigm choice. > Client server has > wrestled with Messaging vs RPC for a long time as well. This > seem to be just > a continuation of the same debate. I think there is some confusion over terminology happening, here. I don't think "action-oriented" necessarily means RPC; it can operate at a higher level of abstraction than that. The way I was interpreting this is data-oriented = one-way messaging. You fire off some information and you don't care what gets done with it. Very loose couplings between systems, very scalable. It's an ideal approach when you can get away with it. Action-oriented = request/response messaging, although the response does not necessarily need to be synchronous. There is simply an expectation on the part of the publisher of the message that there is an endpoint receiving this message that will fulfill the intent of the message, and will provide an appropriate response. RPC is just one narrow case of "action-oriented" in this view. I strongly suspect others are not viewing these terms the same way. > Soap allows both paradigms, but it seems that RPC is the > default modus > operandi for many developers, probably since it looks like > local method > invocations and as such is easily understood. The problem > with RPC has > always been that the developer loses sight of the fact that > the calls are in fact > network invocations and as such have massively larger > latencies. This causes > no end of problems when inexperienced developers use too fine > a level of > granularity. Yes, kind of like Java developers invoking a bunch of fine-grained "get" and "set" methods on an EntityBean in an EJB app, rather than using coarse-grained "value objects" as advocated by Sun's J2EE blueprints (and then proclaiming that EJBs are not scalable). You are quite right that web services are rehashing the same design issues that previous distributed computing architectures wrestled with -- and web services developers will repeat the same mistakes. It is not simply because developers like the local method call approach. Even in scenarios where you do not have that abstraction and developers are having to build integrations between systems, I've seen a tendency to immediately gravitate to building a bunch of hand-crafted, tightly coupled point-to-point integrations. This is a challenge that EAI vendors have had to confront in the marketplace. They have a sound solution to a very real problem, but getting customers to pay attention and actually seek a solution to this problem rather than just plodding along incurring the costs and pain of fragile point-to-point integrations is a hard sell. From my own experience, I have found that when things are working, you often can't get anyone to pay attention to architecture. But if you are there at the right time with the right solution when things blow up and everyone is wondering how to prevent these sorts of catastrophes, you can start to get through to people and get them to think a bit more about the architecture they are employing. You have a brief window, then, to get folks to think about architecture. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
