[
Lists Home |
Date Index |
Thread Index
]
On Sun, 8 Dec 2002, W. E. Perry wrote:
> Ian Graham wrote:
>
> > But that's the goal. Those messages need to be wrapped into a SOAP envelope and the WS
> > framework, and the constraints of W/S tooling (and XML schemas within that tooling) seem to be
> > having a deleterious effect on achieving this goal .... But to be fair, that's in part
> > because the tooling is new, and some obvious features (fault management is poor, handling of
> > schemas, ) are not well implemented.
>
> Unless of course you were to be persuaded that REST is fundamentally
> aligned with both the architecture of the Web and the document basis
> of markup (and SOAP is consonant with neither). The internetwork is
> created by overlaying an addressing scheme on its constituent ...
I like REST. But I can't buy a REST builder, and I can't show my
development leads a REST development suite that shows -- simply and easily
-- how to build an application. That's what the team wants. They want to
buy a product that does all the 'network' work for them, in a manner
consistent with everyone else's product ....
I would very much like to have such a tool. (Visual Studio .NET -- REST
edition!)
> Why must a message be obfuscated in a SOAP envelope? If the offline
> version of the same transaction operates on sending a message, then
> send a plain text marked up message. If the online transaction works
> by executing a form of sale, then replicate that same form in markup
> and PUT it to an appropriate URL where your counterparty might GET it.
> To do that presents not only the minimum learning curve to those
> already knowledgeable of the business, but provides the most clearly
> auditable analogue of well known forms and procedures, instead of
> obfuscating what the business experts expect within the envelopes and
> other magical incantations of the technologists.
The constraints come from the Web services framework and the existing
tooling rather than from SOAP. These impose a model -- WSDL code
generating stubs and skeletons, and the developer writing code to use the
stubs or implement the skeleton classes. (IDL with angle brackets).
But the implemenations then impose a model on how you implement the
application. If something goes wrong with the service, the service returns
a fault. But when should it be a fault? Hard to tell. The tool providers
suggest that faults should correspond to remotely-thrown exceptions, so
you start muddling through some sort of exception model. But
cross-platform tooling does not consistently support faults (i.e. defined
in WSDL), so you need to tunnel exception data inside the fault details,
build custom code for it, ...and so on.
And part of the aim of returning faults is to use them in some future
'flow integration' langauge that will control orchestrated services. But,
of course, no one has done this yet, so you don't really know what things
shoud be faults, or how to classify the faults to better serve this
model. So suddenly you're worring about this sort of detail ...
And suddenly the document model is not your focus. YOur focus is on the
tooling, and what it lets you do ..... and not doing something that will
not be compatible with future tooling .....
Ian
|
