You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Wouter Cloetens <wc...@raleigh.ibm.com> on 2000/06/23 10:38:09 UTC
Re: Discussion points: SOAP Implementation proposals (and more)
On Thu, 22 Jun 2000 15:07:06 -0700, James Snell wrote:
>I put together a
>collection of proposed recommendations for the implementation of several
>application layers (security, complex xml encoding, etc).
I like the standardisation of batched SOAP requests,
authentication/access control (I'm very interested in mapping that to
EJB authentication and ACLs) and the ability to not have to expect a
reply. The latter is essential for a publish/subscribe interface, which
is something our group needs, and can be implemented with the SMTP
(multiple recipients) and JMS (publish/subscribe) transport types.
I'm sorry if these issues have already been raised. I'm new to the
list. I'm only raising issues to start a discussion - I haven't had the
time to really dig into some of the appropriate technologies to propose
the Right Way(tm) of implementing them.
What I'm still missing in SOAP is the ability to send large binary
objects across transparently. I'd like to do this using multipart/mime,
using the reference-to-value system (href="<identifier of
multipart-mime body part>"). SOAP4j could probably map the parts to the
Java Application Framework, or in the case of application/octet-stream,
to a byte array or an InputStream.
Now, with the following line in mind:
"Multiple independent SOAP-Envelopes can be transmitted as different
parts of a Mime Multipart transmission. These SHOULD be treated as
completely independent SOAP requests."
Is there a standard MIME type to identify the consecutive SOAP
requests? Suppose I want to do multiple SOAP requests in a single
document which also contains value references to MIME parts as
described above. "text/xml" may not do the trick - what if one of my
values is an XML document itself? Alternatively, I suppose the
multipart document could contain more multipart types, each starting
with "text/xml", but that would make it impossible to refer to the same
(typically large) value part from several SOAP requests.
Another common concern is the verbosity of SOAP. Is anybody suggesting
a standard way to indicate compression of the contents, e.g. using a
MIME-type indicating a compressed datastream for the entire SOAP
payload? The same, I would imagine, could apply to signed messages, or
encryption of the whole content (rather than just a method or a
parameter ).
Finally, what I'm missing in the SOAP spec is an enumeration type. I
don't mean the indication of a set of legal values, but rather an array
of an undetermined length. One of the inefficiencies of SOAP4j at the
moment is that, when I have to pass a enumeration of objects or values
through SOAP, I have to store the entire set first (e.g. in a Vector)
and then, when I know its final size, create an array which I can then
populate and hand off to SOAP4j to encode.
I'm certain this isn't a language-specific issue (C++ collection
libraries, Perl lists etc.). Thinking from a Java standpoint, it would
be sensible to implement this by mapping an Enumeration type to such a
new SOAP construct. An application can then choose to extend an
Enumeration class so the SOAP encoder will do callbacks to retrieve
consecutive values (nextElement()) and determine when the value set
ends (hasMoreElements()). Caveat is that in Java, every object in an
Enumeration can have another type. I don't know if it's sensible to
either restrict that behaviour and expect only the same type as the
first element, so the syntax would be almost identical to that of a
SOAP array currently, or if every element's type should be described
distinctly.
bfn, Wouter
AW: Discussion points: SOAP Implementation proposals (and more)
Posted by Juergen Fey <jf...@roottec.com>.
Hi,
>
> > What I'm still missing in SOAP is the ability to send large binary
> > objects across transparently. I'd like to do this using multipart/mime,
> > using the reference-to-value system (href="<identifier of
> > multipart-mime body part>"). SOAP4j could probably map the parts to the
> > Java Application Framework, or in the case of application/octet-stream,
> > to a byte array or an InputStream.
>
> I don't think it's appropriate for SOAP to send large binary objects using
> mime or whatever. HTTP does this quite well already thank you.
>
>
Well, i am currently working on using Base64 inside of SOAP. The idea of
using
HTTP to transfer binaries is not bad. There are advantages of doing this
transfer
inside of SOAP however:
Usually there is additional data, handshake stuff and so on. So the BLOB is
just a part of an overall "packet". It would be easy to embed the BLOB as
part
of the whole transfer.
You`re right that HTTP is able to handle BLOBS. Hmmm. Perhaps i could pass
back an identifier from SOAP on the Server to the client which tells the
file destination/URL. After the binary transfer both client and server could
go
on with their handshaking stuff.
So many choices ...
Juergen Fey
RE: Discussion points: SOAP Implementation proposals (and more)
Posted by James Snell <js...@lemoorenet.com>.
James,
Comments inline,
>My hope for SOAP is for it to stay "Simple". The more that gets
>put in, the more that it's no longer simple.
I'm all for SOAP staying simple. What I am proposing is not to expand the
SOAP specification itself, yet rather to have an agreed upon set of
recommendations for how SOAP will be used across implementations. Because
of the emphasis that companies like Microsoft and IBM are putting on SOAP
(MS is wrapping into everything they're doing with the .Net project), it's a
given that SOAP will expand heartily into the enterprise, like it or not.
>I'm still forming a concrete opinion without those Enterprise-tinted
>glasses on. :)
I look at everything through enterprise-tinted glasses. I have to, that's
what I do to pay the bills :-) ...
>I don't think it's appropriate for SOAP to send large binary objects using
>mime or whatever. HTTP does this quite well already thank you.
I would agree with you here. As I've said in the past, I have yet to see a
convincing argument that SOAP is a valid solution for the transfer for
binary data.
>> Is there a standard MIME type to identify the consecutive SOAP
>> requests?
>I may be naiive here -- but what would be wrong with using the HTTP/1.1
>mechanisms for keep alive, etc. These already let you do multiple requests
>in a single connection for efficiency. Why reinvent this wheel?
That works fine across the HTTP transport. But what about SMTP? What about
MQ Series? MSMQ? Raw TCP/IP? Also, I'm not necessarily interested in
consecutive client-to-server calls as much as I am in a format for a single
client-to-server call containing multiple requests.
>Once again -- I'd lean on HTTP's ability to do content-encoding... Wrap the
Again, this works great if SOAP was an HTTP only protocol. But it's not.
In order to maintain consistency across all transports, the solutions we
choose need to be transport independent --- this is not to say that
transport level solutions CANNOT be used, however.
- James
RE: Discussion points: SOAP Implementation proposals (and more)
Posted by James Snell <js...@lemoorenet.com>.
James,
Comments inline,
>My hope for SOAP is for it to stay "Simple". The more that gets
>put in, the more that it's no longer simple.
I'm all for SOAP staying simple. What I am proposing is not to expand the
SOAP specification itself, yet rather to have an agreed upon set of
recommendations for how SOAP will be used across implementations. Because
of the emphasis that companies like Microsoft and IBM are putting on SOAP
(MS is wrapping into everything they're doing with the .Net project), it's a
given that SOAP will expand heartily into the enterprise, like it or not.
>I'm still forming a concrete opinion without those Enterprise-tinted
>glasses on. :)
I look at everything through enterprise-tinted glasses. I have to, that's
what I do to pay the bills :-) ...
>I don't think it's appropriate for SOAP to send large binary objects using
>mime or whatever. HTTP does this quite well already thank you.
I would agree with you here. As I've said in the past, I have yet to see a
convincing argument that SOAP is a valid solution for the transfer for
binary data.
>> Is there a standard MIME type to identify the consecutive SOAP
>> requests?
>I may be naiive here -- but what would be wrong with using the HTTP/1.1
>mechanisms for keep alive, etc. These already let you do multiple requests
>in a single connection for efficiency. Why reinvent this wheel?
That works fine across the HTTP transport. But what about SMTP? What about
MQ Series? MSMQ? Raw TCP/IP? Also, I'm not necessarily interested in
consecutive client-to-server calls as much as I am in a format for a single
client-to-server call containing multiple requests.
>Once again -- I'd lean on HTTP's ability to do content-encoding... Wrap the
Again, this works great if SOAP was an HTTP only protocol. But it's not.
In order to maintain consistency across all transports, the solutions we
choose need to be transport independent --- this is not to say that
transport level solutions CANNOT be used, however.
- James
AW: Discussion points: SOAP Implementation proposals (and more)
Posted by Juergen Fey <jf...@roottec.com>.
Hi,
>
> > What I'm still missing in SOAP is the ability to send large binary
> > objects across transparently. I'd like to do this using multipart/mime,
> > using the reference-to-value system (href="<identifier of
> > multipart-mime body part>"). SOAP4j could probably map the parts to the
> > Java Application Framework, or in the case of application/octet-stream,
> > to a byte array or an InputStream.
>
> I don't think it's appropriate for SOAP to send large binary objects using
> mime or whatever. HTTP does this quite well already thank you.
>
>
Well, i am currently working on using Base64 inside of SOAP. The idea of
using
HTTP to transfer binaries is not bad. There are advantages of doing this
transfer
inside of SOAP however:
Usually there is additional data, handshake stuff and so on. So the BLOB is
just a part of an overall "packet". It would be easy to embed the BLOB as
part
of the whole transfer.
You`re right that HTTP is able to handle BLOBS. Hmmm. Perhaps i could pass
back an identifier from SOAP on the Server to the client which tells the
file destination/URL. After the binary transfer both client and server could
go
on with their handshaking stuff.
So many choices ...
Juergen Fey
Re: Discussion points: SOAP Implementation proposals (and more)
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 2000/06/23 01:38, Wouter Cloetens at wcloeten@raleigh.ibm.com wrote:
> I like the standardisation of batched SOAP requests,
> authentication/access control (I'm very interested in mapping that to
> EJB authentication and ACLs) and the ability to not have to expect a
> reply. The latter is essential for a publish/subscribe interface, which
> is something our group needs, and can be implemented with the SMTP
> (multiple recipients) and JMS (publish/subscribe) transport types.
I'm kind of concerned by this. ebXML gets into the whole pub/sub scenario
and defines the ability for data to be sent over SMTP. My hope for SOAP is
for it to stay "Simple". The more that gets put in, the more that it's no
longer simple.
Let me expand. I wrestled for a while with where SOAP fit into the universe.
Bemoaned it's lack of certain things. And yet was surprised at how many
people were actively wanting to use it. Then, somewhere along the line, I
spent enough time without the Enterprise-tinted glasses on and talked with
some of those people who were wanting to use soap to accomplish things. Tim
O'Reilly put it well in his talk at JavaOne when he was talking about the
ability for a company to publish an XML view of the top 10 books being sold,
or maybe just the top 10 books in a catagory. Currently to do this, you have
to screen scrape. A whole interesting set of applications arises when you
can do this easily.
So, I'll make it blatant that my agenda item in this group is to keep SOAP
simple and not let it crawl too far into the Enterprise. Let other solutions
handled transactions and such. For example, ebXML. In fact, SOAP may already
be too complicated. I'm still forming a concrete opinion without those
Enterprise-tinted glasses on. :)
> What I'm still missing in SOAP is the ability to send large binary
> objects across transparently. I'd like to do this using multipart/mime,
> using the reference-to-value system (href="<identifier of
> multipart-mime body part>"). SOAP4j could probably map the parts to the
> Java Application Framework, or in the case of application/octet-stream,
> to a byte array or an InputStream.
I don't think it's appropriate for SOAP to send large binary objects using
mime or whatever. HTTP does this quite well already thank you.
And, we're talking about Apache/SOAP here -- not SOAP4j. :) Just a gentle
reminder that this is an Apache thing now and not an IBM thing.
> Is there a standard MIME type to identify the consecutive SOAP
> requests?
I may be naiive here -- but what would be wrong with using the HTTP/1.1
mechanisms for keep alive, etc. These already let you do multiple requests
in a single connection for efficiency. Why reinvent this wheel?
> Another common concern is the verbosity of SOAP. Is anybody suggesting
> a standard way to indicate compression of the contents, e.g. using a
> MIME-type indicating a compressed datastream for the entire SOAP
> payload?
Once again -- I'd lean on HTTP's ability to do content-encoding... Wrap the
request with a Gzip stream. Does wonders for transmission time since XML
turns into tokens amazingly well due to its nature. This let's it be a
transport level issue and not an issue that has be directly solved again.
> The same, I would imagine, could apply to signed messages, or
> encryption of the whole content (rather than just a method or a
> parameter ).
Signed messages -- can't we lean on DSig? Encryption -- can't we lean on
HTTPS?
.duncan
Re: Discussion points: SOAP Implementation proposals (and more)
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 2000/06/23 01:38, Wouter Cloetens at wcloeten@raleigh.ibm.com wrote:
> I like the standardisation of batched SOAP requests,
> authentication/access control (I'm very interested in mapping that to
> EJB authentication and ACLs) and the ability to not have to expect a
> reply. The latter is essential for a publish/subscribe interface, which
> is something our group needs, and can be implemented with the SMTP
> (multiple recipients) and JMS (publish/subscribe) transport types.
I'm kind of concerned by this. ebXML gets into the whole pub/sub scenario
and defines the ability for data to be sent over SMTP. My hope for SOAP is
for it to stay "Simple". The more that gets put in, the more that it's no
longer simple.
Let me expand. I wrestled for a while with where SOAP fit into the universe.
Bemoaned it's lack of certain things. And yet was surprised at how many
people were actively wanting to use it. Then, somewhere along the line, I
spent enough time without the Enterprise-tinted glasses on and talked with
some of those people who were wanting to use soap to accomplish things. Tim
O'Reilly put it well in his talk at JavaOne when he was talking about the
ability for a company to publish an XML view of the top 10 books being sold,
or maybe just the top 10 books in a catagory. Currently to do this, you have
to screen scrape. A whole interesting set of applications arises when you
can do this easily.
So, I'll make it blatant that my agenda item in this group is to keep SOAP
simple and not let it crawl too far into the Enterprise. Let other solutions
handled transactions and such. For example, ebXML. In fact, SOAP may already
be too complicated. I'm still forming a concrete opinion without those
Enterprise-tinted glasses on. :)
> What I'm still missing in SOAP is the ability to send large binary
> objects across transparently. I'd like to do this using multipart/mime,
> using the reference-to-value system (href="<identifier of
> multipart-mime body part>"). SOAP4j could probably map the parts to the
> Java Application Framework, or in the case of application/octet-stream,
> to a byte array or an InputStream.
I don't think it's appropriate for SOAP to send large binary objects using
mime or whatever. HTTP does this quite well already thank you.
And, we're talking about Apache/SOAP here -- not SOAP4j. :) Just a gentle
reminder that this is an Apache thing now and not an IBM thing.
> Is there a standard MIME type to identify the consecutive SOAP
> requests?
I may be naiive here -- but what would be wrong with using the HTTP/1.1
mechanisms for keep alive, etc. These already let you do multiple requests
in a single connection for efficiency. Why reinvent this wheel?
> Another common concern is the verbosity of SOAP. Is anybody suggesting
> a standard way to indicate compression of the contents, e.g. using a
> MIME-type indicating a compressed datastream for the entire SOAP
> payload?
Once again -- I'd lean on HTTP's ability to do content-encoding... Wrap the
request with a Gzip stream. Does wonders for transmission time since XML
turns into tokens amazingly well due to its nature. This let's it be a
transport level issue and not an issue that has be directly solved again.
> The same, I would imagine, could apply to signed messages, or
> encryption of the whole content (rather than just a method or a
> parameter ).
Signed messages -- can't we lean on DSig? Encryption -- can't we lean on
HTTPS?
.duncan