ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Snell" <jsn...@lemoorenet.com>
Subject RE: IRC Chat Comments
Date Mon, 04 Sep 2000 17:24:25 GMT
Comments Inline:

-----Original Message-----
From: Jacek Kopecky [mailto:jacek@idoox.com]
Sent: Sunday, September 03, 2000 5:11 AM
To: 'soap-dev@xml.apache.org'
Subject: Re: IRC Chat Comments


>>Hello James. 8-)
>>
>>This is a good initial design, here are my comments:
>>
>>1) To avoid confusion I would rename SOAPDescription to SOAPService,
>>since service description languages are used to _describe_services_
>>and SOAPService provides API for working with the service, not with
>>the description of the service.
>>

  Actually, I was thinking that the SOAPDescription would be used to work
with the description of the service.  The SOAPDescription would basically
allow the developer to create/read/manipulate/program against, the
description of a service, while the other classes perform the actual work.
That's what I was thinking anyway... I'm probably just not understanding
what exactly you're saying here so, please, explain further :-)


>>2) Does your design allow for id/href references between headers and
>>body? It was you who first told me this was possible. 8-)
>>

  Oh yeah... of course! :-)  The basic SOAPHeader API would include some
kind of method like "referencePayload" or something.    More sophisticated
approaches could be taken by custom SOAPHeader classes.


>>3) As I understand it the only difference of your SOAPPayload and
>>SOAPHeader classes is in the location of the resulting XML in the
>>Envelope tree. If we could find a simple way to tell a SOAPPayload
>>where in the Envelope to put itself, we could derive SOAPHeader by
>>inheritance from SOAPPayload. Or both these classes could be inherited
>>from a common SOAPPart (the name can be changed).
>>

That's a possibility.  We could do something conceptually like:

  SOAPPart header = new SOAPDigSigHeader();
  SOAPPart payload = new SOAPPayload();
  SOAPEnvelope env = new SOAPEnvelope();

  env.attachPart(icHeader, header);
  env.attachPart(icPayload, payload);

It would simplify the API significantly, but I think it might be cause some
confusion among the masses.  Hmm.. I'll have to think this through a bit.

>>4) I still don't understand (nobody has ever attempted to explain it)
>>why you would not use the "client-side tools" on the server side. It
>>seems like adding the reverse functionality to all the client-side
>>tools would make them appropriate to ease handling SOAP messages on
>>the server side. That would make Envelope, Payload, Header and
>>Description (Service) common to both sides. That's exactly the
>>approach we took in IdooXoap - the low level doesn't care whether it's
>>the server or the client, it only knows a lot about SOAP messages. 8-)
>>

I actually would use the client side tools on the server, especially when
building the response that is sent back to the client.

When a message is received, it would be broken up into it's particular
classes (SOAPEnvelope, SOAPPayload, and SOAPHeader) and distributed to the
Payload and Header Handlers accordingly.

>>I see you approached from the c++ side, but I think we agreed on the
>>IRC that "version 3.0" which is supposed to have exactly this kind of
>>API would actually be more of a rewrite rather than a change of 2.0.

Yes, I can see that.  It would be a major rewrite -- but I think that it is
one that is definitely required.

- James

>>                            Jacek Kopecky
>>                            Idoox s.r.o.


Mime
View raw message