[
Lists Home |
Date Index |
Thread Index
]
Ian Graham wrote:
> 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 ....
But that's just the point. The business as practiced is your blueprint. Build close analogues in
markup of the offline forms of the business. Use the basic verbs of http to manipulate those forms.
What 'network' work is there to do? You get GET, PUT, POST for 'free'. And of course it interoperates
because 1) on the Web you are internetworked with everyone who shares the URL addressing scheme and
the http verbs which exploit it; and 2) your business documents, data, messages, etc. are close enough
analogues of the offline stuff that a potential counterparty who can understand the offline forms well
enough to engage in the business in the first place gets the easiest possible transition to the online
version.
> 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).
Of course they do, and you don't need them. The point is that your constraints should be the
constraints of the business. Why employ a tool which makes demands of you beyond those of the
business?
> 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.
Not at all. Ask what is the usual procedure in the offline version of the same business when
confronted with an analogous fault. If the fault doesn't exist offline, then it is a problem which
your tool and your network framework have gratuitously handed you, and which you may safely strip away
from a faithful online model of the business. But if an analogous fault occurs offline, use the same
recovery procedure that the industry itself does. That is how I learned to love exception files:
business offline routinely tosses things that don't fit into a rework pile to address separately from
the main line of execution. The people who are actually expert in the business won't fault you for
doing the same thing in your online version: they know from experience that it is a necessary and
common best practice.
> 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.
Who cares what the tool providers say. What does the business *do*. Do that.
> 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 ...
Sure, learn from the rework pile and refine your mainline procedures from it. But don't ever think
that the rework pile won't be necessary.
> 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 .....
And you've been bamboozled by the technologists into fiddling with technology instead of implementing
business transactions . . .
|
