B
Bruce Wood
Mike said:Could you elaborate a tad? Just what can be done?
Well, for example, the gurus recommend that Web Services be stateless.
That, along with the knowledge that each call carries a lot of overhead
makes us prefer to make one call to search for stock items and return
the whole list to the client, rather than writing a "get first / get
next" style interface. We also offer client programs fewer options as
to how much information is returned for each item, because it's better
to return more info than the client wanted than to have a client
calling over and over again to get progressively more information about
a particular item. "Return the entire result, and return enough or more
than enough information about each item on one call" is the philosophy
we're running with for now.
If we were running a binary interface we might have done it
differently: make more calls to finer-grained routines on the server
side.
Also, I'm not sure how to determine when a WS should be used over some
other techology. If I my business uses a Java server, then just use a Java
technology to pass the data. Is that how you are determining which to use?
What would be some other factors?
I think of it this way: If I have a server running Java, and I'm pretty
sure that all of my clients, now and in the future, will either be Java
clients or browser-based clients (which could be served by a Java-based
Web server), then I would go with RMI, knowing that that would, for all
practical purposes, lock me into Java forever. I would get much better
performance and it would be easier to make the whole thing work. The
price I pay is that if my bosses ever come to me and say that they want
me to write a C# client on a Windows handheld then I'm in a bit of
trouble. (At that point I would either talk them out of it or build Web
Services on top of the Java server framework and use those, but I
wouldn't really be leveraging all of that RMI investment.) Lots of
shops are one-language shops, and in that environment there's really no
reason to incur the performance penalties of Web Services.
If, on the other hand, there is a reasonable likelihood that I'll be
dealing with all sorts of clients, and browser-based won't cut it (so I
would need to deploy client apps on various client platforms), then I'd
seriously consider Web Services because of the interoperability, even
though the performance sucks (comparatively) and in some cases it's not
as solid as some of the binary protocols (depending upon whose app
server you're using).
In our case, it's our server side that's the problem. Our choices there
are extremely limited... basically it's Web Services or nothing for us
on the server side.