RE: programming model for document-style SOAP

Assaf,

I absolutely agree with you. You should always use the right tool for the
job. You want to give your users a specific interface that makes them more
efficient at their jobs. You want separation between presentation logic and
business logic and between business logic and data resources.

I think we have a diconnect regarding our definition of RPC. I'm talking
about the client programming model. Specifically, I'm talking about the
client programming model between the business logic and the data resource
(the service). I'm not talking about the server programming model nor the
SOAP message style. For the record, I'm of the opinion that we should do
away with SOAP encoding. Once we all agree to only use literal encoding, I
don't think the SOAP RPC convention really makes any difference. The method
name in SOAP RPC is nothing more than a content wrapper supplying a little
bit of information to the SOAP server about how to deal with the content. If
your service supports multiple operations, it indicates which operation you
are requesting. It doesn't necessarily map to a specific method on an
object. Some people build SOAP services and try to expose every object
method, but that's certainly not my recommendation. I encourage people to
build coarse grained services. In any case, I don't think the RPC convention
adds a lot more confusion than it does value.

But let's get back to the topic. A service can't service just anything. It
provides a specific service. Going back to the purchase order example, the
service can't accept just any purchase order. It can only accept a purchase
order that conforms to a format that it knows a priori. It defines the
format of acceptable purchase orders in a schema, and it describes
acceptable methods that you can use to submit those purchase orders in a
WSDL file.

As long as I have a WSDL file, I can use an RPC client programming model to
talk to that service (if I want to). I can generate a client proxy that will
take data from whatever UI I offer to my end user and package the
information into an XML message that conforms to the schema defined in the
WSDL.

Perhaps my UI is a browser, and it captures the information from the user
and immediately formats it in XML. In that case, I definitely don't need to
use the RPC client programming model. It's easier just to package it into a
SOAP message. But let's say that my UI is a desktop application written in
VB or a browser application written in JSP. In this case I'm capturing the
information in a programming language object graph, and I very definitely
want to use the RPC programming model, because it will automatically take my
object graph and render it into the PO XML structure and package it in a
SOAP message for me.

This is one of the real beauties of SOAP/WSDL. The client programming model
is independent of the server programming model. From my perspective, the
driving motivation between using the RPC programming model and the DCA
programming model on the client is determined by the client data model. If
the client is working in XML, use DCA. If the client is working in language
types, use RPC.

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Assaf Arkin
> Sent: Wednesday, January 15, 2003 1:48 AM
> 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.
> > > >
> > > >
> > >
> >
>

Received on Wednesday, 15 January 2003 09:50:27 UTC