RE: programming model for document-style SOAP

Many SOAP implementations now support dynamic proxies. A dynamic proxy maps
to a portType, not to a binding. It decouples the RPC interface from the
over-the-wire representation. The binding is performed at runtime, so
assuming that two services support the same portType, you can use dynamic
binding to bind to RosettaNet for the first one and OAG for the second one.

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Assaf Arkin
> Sent: Tuesday, January 14, 2003 10:32 PM
> To: Hao He; 'Anne Thomas Manes'; 'Christian Hoertnagl';
> www-ws-arch@w3.org
> Subject: RE: programming model for document-style SOAP
>
<snip>
>
> 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.
> > >
> > >
> >
>

Received on Wednesday, 15 January 2003 10:21:20 UTC