I am rewriting a Delphi soap server, which an existing Java application makes calls to. The Java application calls the SOAP server 5 times to get information, and the SOAP server goes to a Sybase database to get the results. The results are parsed into XML and returned in 5 separate return trips (obviously). Now, is more ideal to reduce the overhead by making one call which will have multiple XML files embedded in the result, or best to continue with the high overhead calls? It seems as though it would be easier maintenance-wise to have multiple calls, but I assume they are expensive. (If you're wondering, I'm rewriting both ends of the application, and have to do the Delphi portion because it is a Sybase database and the ODBC driver is better than the JDBC driver(the free ones anyway)). Is this covered in a pattern somewhere? Thanks...
I see nothing wrong in exposing a very high-level operation taking in all 5 "requests" at a time if you're fine with it from the client's point of view (i.e. willing to handle the bigger/uglier input and output messages).
I agree with Lasse. Nothing wrong with a "coarse-grained" web service, as far as what you are implementing makes sense. According to me, the only way to choose between 1 or 5 roundtrips is to think from a business perspective. In your old Java-Delphi app, are the 5 calls mandatory due to business issues ? And what about the XML you are sending back to the client ? Can it be seen as a unique XML containing multiple responses ? Or is is really 5 different XMLs you are gathering just to increase performance.
The 5 trips were originally designed to pull information from 5 different tables. I will still have to pull from 5 tables, but I could embed the 5 results in one response...
I generally vote for fewer trips to larger grained services, but temper that with a suggestion to see if this is really a problem, first. In another life (LU6.2 APPC) I found fewer trips with bigger payloads was worth quite a bit of effort in concatenating messages at one end and parsing them at the other. You have to decide if building an aggregated service is the best way to spend your time. Can you get timings comparing fewer trips with bigger payloads to more trips with smaller payloads without doing a lot of refactoring on your service?
Originally posted by Wendy Wise: I am rewriting a Delphi soap server, which an existing Java application makes calls to. The Java application calls the SOAP server 5 times to get information, and the SOAP server goes to a Sybase database to get the results. The results are parsed into XML and returned in 5 separate return trips (obviously). Now, is more ideal to reduce the overhead by making one call which will have multiple XML files embedded in the result, or best to continue with the high overhead calls? It seems as though it would be easier maintenance-wise to have multiple calls, but I assume they are expensive. (If you're wondering, I'm rewriting both ends of the application, and have to do the Delphi portion because it is a Sybase database and the ODBC driver is better than the JDBC driver(the free ones anyway)). Is this covered in a pattern somewhere? Thanks...
Wendy, I'm trying hard not to poke too hard at this one, since I know you don't have much of a choice -- your boss made you do the delphi thing. But -- does he really think that the fact that the Delphi ODBC drivers are MARGINALLY faster than the JDBC drivers will make up for the time spent generating, parsing, transmitting and receiving the XML that makes up the Web Service even if you manage to do it in one call??? I've just not got a good feeling about this design... Kyle
You are correct in that I don't have a choice, but your issue seems to be with the speed of parsing the XML using Delphi? Is that correct? (I know you have issues with the general design, but what else? If you can give me something concrete, I can build a better case...
Post by:autobot
I've got no option but to sell you all for scientific experiments. Or a tiny ad:
a bit of art, as a gift, the permaculture playing cards