Designing a Web Services interface


XML & Web services: Designing a Web Services interface

  1. Designing a Web Services interface (3 messages)


    I am designing a Web Services interface for our reporting package. Basically the package has 2 input files and a couple of settings and generates an output file. For the architecture of this I have a couple of questions:

    1) If I want C# as well as java apps able to easily interface with the service, is JAX-RPC the way to go?

    2a) As I think this through I think the way to do this is to have a single call that passes across all input settings and data and that one call then returns the output data. However, this feels kludgy as it will have on the order of 20 parameters being passed across, many of which will have default values. It's a small amount of data for all the parameters so it's not a performance hit but 20 parameters in a method feels wrong.

    2b) The alternative is to create a session connection and pass each paramater across seperately for those that have non-default values. That would look cleaner but seems to me to require a lot more overhead.

    3) I have 2 hash maps I need to pass across. However, it says for C# to not pass hash maps. Any suggestions on the best way to pass the data in hash maps?

    thanks - dave

    Threaded Messages (3)

  2. Uh[ Go to top ]

    1. Best way to go is to define XSD schema for your web service input and output, and stick to it (thus doc/literal wsdl). Then the question of wheter you use JAX-RPC on one endpoint is completely irrelevant to what you use on other endpoint (C#, BPEL, etc).

    2a. You need to think in terms of messages, as in e-mail. Would you design e-mail interface of your reporting engine so that customer would have to send TWO e-mail requests (one with "parameters", and another one to get document back)? Of course not. Design one request/response operation that does the job. Also if the report generation is lengthy (which I would assume it can be in some cases) provide push/async response delivery mechanism. So as an alternative option first request could provide "reply to" address to report service. Once the report generation is complete your service (acting as "client" now) would send the document to that address. In fact having only this option is very compelling, but due to issues associated with firewalls, etc you might still want to support other type of operation, where client "waits" for the document generation over the open connection.

    2b. See 2a ("session across e-mail messages" is wrong).

    3. See 1 (there is no "hash map" in XSD, so define sequence of name/value pairs).
  3. Uh[ Go to top ]

    1) Is there an example somewhere you could point me at that shows how to do this? I've been through the axis documents and my reading of it is the only truly SOAP method it provides is JAX-RPC with the doc/literal being just raw xml. Did I miss something?

    thanks - dave
  4. Anna Karenina again :)[ Go to top ]

    If you design your input/output using XSD, and hand-write WSDL in doc/literal mode, you can run Axis WSL2Java to generate JAX-RPC client or service. For C# you can run WSDL.EXE from .NET.

    You can google for "Axis WSL2Java", and if you are not sure how to write XSD and doc/literal WSLD then read some introduction to XSD/WSDL, and browse samples of doc/literal services from (and/or check out WS-I samples).