Re: Simple WS Scenarios [Was Counting Noses]

www-ws-arch-request@w3.org wrote on 06/07/2003 11:53:54 AM:

> 
> Glad to try.  This may be particularly useful because getting to
> specifics may surface misconceptions on my part.
> 
> 1 - There is an application resident on a Web server somewhere that I
> invoke, from an application on another server, with a simple GET with
> some parameters.  The service (or whatever you want to call it) does
> something or other and returns a binary image (a png file) as an HTTP
> image/png type. That's all it returns -- the image manufactured from
> scratch using those parameters -- and that's all I need back.  One of
> the two things I had difficulty with in getting this working (the other
> is not relevant to this discussion and SOAP certainly would not have
> helped that problem) was figuring out how to handle the binary stream of
> data.  Eventually I discovered some method in the system library that
> would just stream it out to a file on disk, which is what I wanted.  I
> believe that my task would have been significantly more difficult if I
> had also had to cope with some XML SOAP header that came along with the

Only if you tried to handle that level on your own. It would be no 
different
than trying to implement the HTTP protocol stack on your own. But this is
the realm of middleware. Most SOAP toolkits bypass all this gorp and give
the application programmer something that is far more natural for them to
use.

> image.  That SOAP header would not have done me any good whatsoever, and
> I am not interested in any of the addons that it might offer (like
> signing the image, for God's sake).  Streaming the header plus the
> binary image to a file would definitely not have been what I wanted.

Right, so don't use it, but again, you are implying that most developers
would be doing all this gorp on their own which is not likely under most
circumstances.

> 
> 2 - We have an automated XML feed from our Help desk to a service
> company.  I'm not positive how it works, but I think it just does a
> simple POST and slams the XML into something that stores it as-is.  For
> one reason or another that's ALL that is needed.  SOAP headers would
> simply be added characters that would be thrown away, and presumably
> software would have to be written to strip those headers off.

Fine, then don't use SOAP. However, in the event that what you really 
wanted
was a direct feed from the source to whatever it is that reads 
periodically
from the filesystem the XML that was simply dropped into the file system
as a result of the POST, then IMO the types of APIs generated by most
Web services toolkits would be far more natural for the developers.

> 
> In both cases, note that the result of the "push" or the "pull" is
> simply to take a defined set of data and put it somewhere.  The data are
> not processed at that time.  SOAP stuff would require processing to
> strip it off.  Cost with no benefit.

Well, like I said, if there was a requirement to eliminate some of the
time from the processing of the complete application (e.g. eliminate the
time where the information simply sits idle on the filesystem), then you 
might
want to reconsider this. Additionally, if this is indeed just a pitstop,
then for security reasons, you might not want to have the information
simply sitting on the HTTP server's filesystem. It is more prone to 
risk of attack. If it were me, I might have a direct feed into my pub/sub
or message queue infrastructure, such that the messages would trigger
the down stream processing and such that the information were not sitting
on my HTTP server's filesystem waiting for some hacker to find and exploit
in ways that I might not appreciate.

> 
> It sounds like Hao can probably come up with better scenarios, and I
> hope he does so.
> 
<snip/>

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Received on Monday, 9 June 2003 06:14:57 UTC