RE: programming model for document-style SOAP

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.
> >
> >
>