[
Lists Home |
Date Index |
Thread Index
]
Catalog order systems are orders of magnitude less
complex than average business processes. The invoice
is an easy mark but a terrible exemplar.
Why isn't one of the parameters the name
of the XML vocabulary?
Why isn't one of the processes the negotiation
to choose the XML vocabularies?
If the process were deep, I'd tell them the
namespaces of the elements in the invoice.
If the process were deep, I'd know which
desk was handling my invoice today and
the amount of sick leave the worker at that
desk has accrued. Business interfaces don't
do that. They deliberately ensure that information
exchange is formal and encapsulated. That is
why SGML works as well as it does.
len
-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
"Bullard, Claude L (Len)" wrote:
>
> I don't believe in
>
> "The ultimate goal of Web services, many vendors say, is to let Internet
> applications interact with each other the same way humans interact with
> them."
>
> That doesn't work.
Today I step through some Expedia forms to buy an airline ticket, or to
buy a book from Amazon. Tomorrow I write a Python program to step
through for me. It demonstrably works, even with plain old HTML. I know
it works because I do it!
> ... I believe humans configure these systems to work
> and keep up with what they do. Again, pay attention to what I am
> saying about not going too deep with this. Fine-grained processing
> will become hazardous to the health of the business at light speed.
That's why you want to concentrate on *XML message vocabularies* and not
procedure call parameters. You define your XML first to be coarse
grained and then define interfaces into your business systems rather
than generating schemas from your Foxpro or C# code.
> After that, again as I said to Dave, it appears the vendor gets
> to choose between RPC and UDDI/HTTP in the toolkits. Many of us
> who build applications get to choose among the toolkits.
Microsoft shipped their REST toolkit in 1998.
|
