RE: programming model for document-style SOAP

hi, Assaf,

Well said. I believe that we are actually in agreement. I especially like
your conclusion:

"We say RPC is not suitable for
systems where you want to expose services over a heterogenous network of
clients and protect from changes as much as possible. Using RPC in such
scenarios is bad. "

Hao



-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Wednesday, January 15, 2003 5:48 PM
To: Hao He; 'Anne Thomas Manes'; 'Christian Hoertnagl';
www-ws-arch@w3.org
Subject: RE: programming model for document-style SOAP


Do you know that person that uses the blade of a knife to turn screws and
the handle to knock nails in place? Do you think they could do a better job
if they had a better knife?

A professional would always use the tool that is most appropriate for the
problem at hand. So if the problem is building coarse-grained interfaces
then RPC would not be the right tool. RPC would be the knife from that
alegory.

On the other hand if you want to slice bread, a knife would work better than
a hammer or a screwdriver. So sometimes a knife is exactly what you want to
do.

As a professional I also like to understand what the problem is so I can
find the right solution. Even if I have the best RPC tool, if the problem I
am trying to solve required non-RPC interfaces, then an RPC tool is not the
right approach. If someone is using RPC as the solution to a non-RPC
problem, I do not blame the tool nor do I care how good the tool is - they
are using the wrong tool. Period.

Some abstraction layers are best achieved by having non-RPC interfaces. Even
if you can download an RPC tool developed in 2010, you are still better off
not using it because it's the wrong tool.

On the other hand, some abstraction layers are best achieved using
RPC-interfaces where there is sufficient abstraction in the RPC layer. In
that case, a bad RPC tool would be a bad RPC tool, but still the tool of
choice.

We all know why non-RPC abstraction (PO being the mythical example) is good.
So I won't bother to explain why you shouldn't use RPC for purchase orders.

Instead I'll look at a different example. Let's say I have a procurment
application. Every day users go in and place orders for various quantities
of aluminium. They never buy anything else. I also have another system for
buying office suppliers.

I can abstract the two systems and have a unified interface. But that means
the users who buy office supplies would want to know what they do with the
weight/density/MTBF fields. And the users who buy aluminium would want to
know why they need multiple line items with different SKUs.

I get much better bang for the money if I use a standardized (abstracted)
purchase order schema to send all my purchase orders regardless of what I am
buying. But I get much more bang for the money if I customer tailor the
front-end to the specific needs of the user.

Now, here's the tricky part. My users could have an abstracted form in which
they have to write the XML purchase order document. Or they could have a
form with a set of fields which represent the data they need to provide. I
am not fooling myself, the later case is a form of RPC. Even if I encode it
as an XML document, it's still RPC.

The question is: where do I perform the abstraction between the very
specific form and the very generic purchase order? Do I make it inside the
front-end application? Do I separate the presentation side of the
application from the abstraction component and have an interface in between?

In the first case I may end up mixing presentation with logic. In the second
case, I need an interface between the HTML form and an application level
representation (the actual RPC operation). I can decide to always make it an
API. I can decide to use IIOP. I can decide to expose it as SOAP.

Of course whenever the interface changes (say I add more fields to the
form), I need to change the software. A bad thing. I pay for it in developer
time. But, if I make the interface task-specific (less abstract) I get
better productivity on a day to day basis. So I make my users work less. A
good thing. Personally, I think software should work for the user instead of
the user working for the software, so I would go for the task-specific
solution.

In this example I am actually illustrating two different uses of WS. In one
we expose services over the Internet to be used by a large collection of
heterogenous systems, in which case RPC may be the least preferred approach.
In the other, we have a very specific solution, in which case RPC is the
better approach.

Pros and cons to having RPC (as well as non-RPC, never as the only option):

Pros:

1. No superflous abstraction when it's not needed. Use the right tool for
the right problem.
2. Increases the uses for WS, benefiting from the network effect to make WS
even more usable.

Cons:

1. Two options, developers may end up using the wrong tool.

I personally think the pros outweight the cons. That is, I would want to
have two options. I would counteract the cons by having best practices that
would instruct people when to use the right tool. We all know that
restricting options does not lead to better solution since it does not
prevent people from doing things the wrong way. It only gives them less
options.

So in my world we don't say RPC is bad. We say RPC is not suitable for
systems where you want to expose services over a heterogenous network of
clients and protect from changes as much as possible. Using RPC in such
scenarios is bad.

arkin


> 1. RPC is not the whole problem but it is part of the problem at a coarse
> grainded environment.  So we can still blame it partially. :)
> 2. The goal here is to achieve loose-coupling (minimize artificial
> dependencies (AD)) between interacting systems.  We seem all
> agree that RPC
> encourages tight coupling.
> 3. Having correct abstraction layers is an effective approach to
> reduce AD,
> even for a RPC system.
> 4. We seem all agree that having tools to do the right abstraction is
> difficult, at least for now.
> 5. I suspect that by the time the IDEs are smart enough, there
> will be many
> other alternative solutions (just as good if not better) available.
>
> Hao
>
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Wednesday, January 15, 2003 2:32 PM
> To: Hao He; 'Anne Thomas Manes'; 'Christian Hoertnagl';
> www-ws-arch@w3.org
> Subject: RE: programming model for document-style SOAP
>
>
> The point I am trying to make, and I think Anne is making the
> same point, is
> not in favor of RPC per se.
>
> It just points to the fact that using RPC is not the problem and avoiding
> RPC is not a solution.
>
> Is the incoming PO going to change? For some applications this has not
> happend in decades. For other applications this happens on a continuous
> basis.
>
> What you need to do is determine: is change likely to happen?
>
> If your application is designed based on generic data structure for a
> purchase order, then for many applications I have seen this has
> not changed
> in years. The generic data structures for buying anything from
> books to cars
> to airplans don't change all to often, if it all.
>
> On the other hand, if you depend on specific datastructures (RPC
> or no RPC)
> you may experience change. If you depend on the datastructure to
> be specific
> to a book, then you won't be able to buy/sell PDAs. Same way if you depend
> on a specific credit card. So abstraction is the way to go, but
> abstraction
> at this level is achieved through definition of the data structure not the
> operation.
>
> If you depend on a specific way to encode the message you will experience
> change. You will need one component to support the RosettaNet encoding and
> one to support the OAG encoding, even if both express the same data.
>
> If you use a tool that maps your object data structure to a
> message encoding
> (as most current day IDEs) to, then you are in coupling the
> software to the
> over-the-wire message and you will face change down the road. But
> if you use
> a tool that decouples the object data structure from a more
> abstract message
> and allows multiple over-the-wire representations, you get the level of
> abstraction you need.
>
> We can say that the current level of IDEs proves that RPC is not
> a suitable
> approach. We could also say that the current level of IDEs proves that
> someone needs to better design these IDEs to account for best practices.
>
> Will we be having this discussion in two years from now when we all have
> better IDEs that support abstraction?
>
> arkin
>
>
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> > Behalf Of Hao He
> > Sent: Tuesday, January 14, 2003 7:03 PM
> > To: 'Anne Thomas Manes'; 'Christian Hoertnagl'; www-ws-arch@w3.org
> > Subject: RE: programming model for document-style SOAP
> >
> >
> > hi, Anne,
> >
> > I agree that either approach is ok and one does not have to use
> either if
> > they don't want to.
> >
> > The difference (or question to explore) is:" how much value does the RPC
> > model and proxy generation provide when compared with the cost
> > they incur? "
> >
> > My point is that at coarse grained level, the RPC approach is not cost
> > effective.
> >
> > In your PO example, the additional cost of using SOAP for the submitPO
> > method and generating proxy is just far greater than POSTing a PO XML
> > directly to the server.
> >
> > Processing the received XML is a different issue. I agree that
> you may be
> > able to generate some code for processing the XML if there is a stable
> > processing pattern (not XML parsing) available.  However, due to
> > the nature
> > of extensibility of XML (and the nature of business), the
> incoming PO will
> > evolve and so will the processing pattern itself.  This would make code
> > generation quite difficult if not impossible.
> >
> >
> > Hao
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Wednesday, January 15, 2003 1:00 PM
> > To: Hao He; 'Christian Hoertnagl'; www-ws-arch@w3.org
> > Subject: RE: programming model for document-style SOAP
> >
> >
> > Hao,
> >
> > I don't think that the difference between the RPC and DCA
> > programming model
> > in Web services is quite so cut and dried. While I agree with you that
> > method-based RPC invocation is fine grained, I disagree that
> you can't do
> > (or that it's inconvenient to do) coarse-grained invocations with an
> > RPC-style programming model. You can use late binding with an RPC-style
> > programming interface, and you can design your client and server to deal
> > with variable content. For example, you can design your input and output
> > messages to support the <choice> construct, directing the request off to
> > different methods based on the information supplied. The point
> is, you can
> > let the tools generate a lot of the code for you. As long as you
> > have schema
> > definitions for your message structures, I don't see why you
> need to write
> > your own parsing code.
> >
> > Let's say that you have an order processing application. It
> > accepts purchase
> > orders, and depending on what's being ordered, the purchase
> order might be
> > in a variety of formats. You create a WSDL description for this
> > service, and
> > the PO is described in XML Schema, using <choice> to indicate
> the variable
> > formats. In your service you map each of the choices to a
> different method
> > for processing, but the individual methods aren't exposed
> through the Web
> > service API. There's just one API, which is submitPO. You should
> > be able to
> > generate a client proxy from that WSDL file and then invoke
> operations on
> > that proxy (e.g., submitPO). It should generate the appropriate
> > SOAP message
> > structure based on the object graph of your PO.
> >
> > Now, or course, if you prefer to do your own XML processing,
> that's up to
> > you. My point is that you don't have to if you don't want to.
> >
> > Anne
> >
> > > -----Original Message-----
> > > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> > > Behalf Of Hao He
> > > Sent: Tuesday, January 14, 2003 6:48 PM
> > > To: 'Christian Hoertnagl'; www-ws-arch@w3.org
> > > Subject: RE: programming model for document-style SOAP
> > >
> > >
> > > The central problem here is the level of granularity.  IMO,
> RPC is more
> > > suitable for fine grained processing while Document-Centric
> > Approach (DCA)
> > > is more suitable for coarse grained processing.  Yes, you can
> use either
> > > approach to do both but the cost would be higher than necessary.
> > >
> > > With a RPC approach, by its nature of tight coupling, it makes
> > sense to do
> > > early bindings, things such as stub generation with strong typing.
> > >
> > > By contrast, you want to do late bindings with DCA.  A typical design
> > > pattern here is layering, with each layer being specialized in
> > solving one
> > > particular problem.
> > >
> > > Hao
> > >
> > >  -----Original Message-----
> > > From: Christian Hoertnagl [mailto:hoe@zurich.ibm.com]
> > > Sent: Tuesday, January 14, 2003 9:02 PM
> > > To: www-ws-arch@w3.org
> > > Subject: RE: programming model for document-style SOAP
> > >
> > >
> > >
> > >
> > > Anne, Hao,
> > >
> > > I agree with Anne's reply indicating that the choice between RPC or
> > > document-style does not mandate a particular client programming
> > style. The
> > > WSDL spec e.g. specifically says that "This information _may_
> be used to
> > > select an appropriate programming model".
> > >
> > > However, while I understand that you can do document-style
> > messaging using
> > > normal stubs, I'm also interested in scenarios where the messages
> > > have more
> > > variable format (an unknown number of documents, each with optional
> > > attachment, say) than is typical for RPC (three integer
> > parameters, say).
> > > For handling sg. like this an approach with callback handlers
> (like Hao
> > > seems to indicate as well) seems like an attractive option to
> me. I'd be
> > > curious to learn more about existing approaches esp. of this kind.
> > >
> > > Regards,
> > > Christian
> > >
> > > Hao He <Hao.He@thomson.com.au> wrote on 01/09/2003 01:55:14 AM:
> > >
> > > > We are using a strategy pattern in our implementation: you have
> > > a generic
> > > > reader which decomposes the document to various parts that can
> > > be handled
> > > by
> > > > various handlers.  Perhaps  this is similar to your handler as
> > > well?  The
> > > > cool thing about this approach is that each handler only
> > needs to under
> > > one
> > > > aspect of the document.
> > >
> > >
> >
>