RE: What does WSDL describe?

Mike,

> >
> > <orderForm1>
> >   <carOrMotorcycle>car</carOrMotorcycle>
> >   <colour>blue</colour>
> >   <cc>1800</cc>
> >   <model>blabla</model>
> > </orderForm1>
> >
> > then the service receiving it knows what needs to be done.
> 
> Really?  There are a lot of things that real businesses do with
orders:
> enter them, fufill them, cancel them, approve them, etc.  One could of
> course have different services for each of these (Mark Baker's
preferred
> approach, I'd guess) and one could just GET/PUT/DELETE order documents
> from
> those service queues.  If I understand the counter-argument, its that
> businesses don't want to expose all this to the outside (where it
might
> expose details of their operations they don't want exposed to
competitors
> or
> hackers, because the details are sure to change and they don't want to
> have
> to manage the redirects and updates, because the HTTP interface is
just
> some
> thing in the DMZ and the real guts of the system are scattered all
over
> the
> enterprise, etc.)
> 

I don't disagree that businesses do many things with order. That's why
they offer different forms to their customers:

CancelForm, OrderForm, SurveyForm, LicenceForm, etc. Businesses in the
real world work by exchanging documents not by instructing each other
what to do.

Again, I want to make it clear that what I am talking about has nothing
to do with REST, in case there is a misunderstanding.
 
[snip]

> deleteOrder operation.    (I guess that implies that there are some
> semantics about operations embedded in WSDL, I'm not sure).  Finally,
> let's
> not forget that the majority of SOAP systems actually deployed today
do
> use
> RPC in one form or another.  We may wish to make WSDL more flexible to
> accommodate asynchronous and one-way MEPs, but it seems self defeating
to
> make it difficult to do RPC in environments where it actually works.
> 

As you already know I disagree that there should be semantics attached
to operations in WSDL. Just because people didn't realise it at first
that Web Services were not about making RPC calls using XML that doesn't
mean that we should adopt that model. When people were moving from the
procedural to the object-oriented programming paradigm, we saw a lot of
people using C++ in the same way they were using C or Fortran. I am not
going as far as saying that there is a paradigm shift but let's not
allow the old ways of thinking and building distributed applications
lead us in defining specifications for Web Services. We can learn from
the past and our mistakes.

Just because current tooling makes it so easy to build RPC-like
applications over SOAP, it doesn't mean that it is the best model (my
2c!).

Best regards,
.savas.

Received on Sunday, 26 October 2003 10:21:54 UTC