I think I understand your argument, Ricky, but here is the deal. My web service performs the job of processing numerous types of database queries, too numerous to describe in a static API. The best way to describe the queries requested is to provide an XML document (or XML stream, if there is a difference) to the service, have it process all the query scenarios, and return the result, which IS an XML document.
I'm just trying to find the best way to describe the datatype that holds the XML documents.
For example, my java interface for the web service may look like this:
public interface IMyInterface
{
public String executeQuery(String query);
}
OR
public interface IMyInterface
{
public Document executeQuery(Document query);
}
OR
public interface IMyInterface
{
public byte [] executeQuery(byte [] query);
}
I just want the most efficient way to pass this stream...
Barry
-----Original Message-----
From: Ricky Ho [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 29, 2002 6:09 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: XML and web services
What I mean the main value of "self-describing" web services is that the
invocation detail is all described in the WSDL. When you pass the XML data
as "String", "ByteArray" or "Document", you lose the schema description of
your XML. So I think the best approach is use document/literal encoding
rather than manipulate the data type to another form.
Rgds, Ricky
At 05:08 PM 10/29/2002 -0500, [EMAIL PROTECTED] wrote:
>What I was thinking of was some sort of equivalent - not necesarily the DOM
>tree sa I've laid it out here.
>
>
>
>
>
>Ricky Ho <[EMAIL PROTECTED]> on 10/29/2002 05:06:49 PM
>
>Please respond to [EMAIL PROTECTED]
>
>To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
>Subject: Re: XML and web services
>
>
>This has the issue as the previous one that the schema structure of the DOM
>tree is undefined in the WSDL.
>
>Rgds, Ricky
>
>At 02:41 PM 10/29/2002 -0500, [EMAIL PROTECTED] wrote:
>
>
>
>
>
> >Doesn't this all seem complex compared to just supporting an XML datatype?
> >
> >For a number of the Weblogic services I've created I used things like:
> >
> >- <message name="fetchAdvisorListRequest">
> > <part name="arg0" type="dom:org.w3c.dom.Document" />
> > </message>
> >- <message name="fetchAdvisorListResponse">
> > <part name="return" type="dom:org.w3c.dom.Document" />
> > </message>
> >
> >As you can see, the endpoint takes a single argument in and sends a single
> >argument back - just XML docs.
> >
> >This makes it easy to send pretty complex data structures over the wire.
> >For example, one app we created had an XML element called <Command> that
>we
> >used to implement a 'Command Pattern' for the web service. The <Command>
> >value was passed to a factory class that returned a parser that knew what
> >to expect in that particular XML document. We created upwards ot 20
> >commands for the project - all with widely varying XML content - and we
>had
> >to implement only a single web service endpoint. Plus all the data was
> >readable text when monitored using tcpmon.
> >
> >I know that another department connected to one of the services using some
> >MS technologies - though I don't know the details - and was able to
>process
> >things with no problem.
> >
> >This seems to me to be a much simpler way to build web services than to
> >create a bunch of different services and endpoints and have to have
> >different datatypes (and potentially custom handlers).
> >
> >Kevin
> >
> >
> >
> >
> >
> >
> >James Black <[EMAIL PROTECTED]> on 10/29/2002 01:26:41 PM
> >
> >Please respond to [EMAIL PROTECTED]
> >
> >To: [EMAIL PROTECTED]
> >cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
> >Subject: Re: XML and web services
> >
> >
> >Ricky Ho wrote:
> >
> > > Besides the performance overhead of converting the XML to a byte array
> >and
> > > back, another big minus is the WSDL in this case has lost all the
>schema
> > > definition. In other words, the client and the server has to use
>another
> > > channel to communicate what does the detail of the request and response
> > > look like.
> >
> > That is why one parameter that the client sends is to tell the server
>how
> >to
> >return the data.
> >
> > For my purposes this works well, since the output can vary so much.
>For
> >others it may not be as useful.
> > I am also on a 100Mb network, and so bandwidth is not a concern. <g>
> >
> >
> >
> >
> >
> >
> >
> >
>---------------------------------------------------------------------------
> >This e-mail message (including attachments, if any) is intended for the
>use
> >of the individual or entity to which it is addressed and may contain
> >information that is privileged, proprietary , confidential and exempt from
> >disclosure. If you are not the intended recipient, you are notified that
> >any dissemination, distribution or copying of this communication is
> >strictly prohibited. If you have received this communication in error,
> >please notify the sender and erase this e-mail message immediately.
> >
>---------------------------------------------------------------------------
>
>
>
>
>
>
>
>---------------------------------------------------------------------------
>This e-mail message (including attachments, if any) is intended for the use
>of the individual or entity to which it is addressed and may contain
>information that is privileged, proprietary , confidential and exempt from
>disclosure. If you are not the intended recipient, you are notified that
>any dissemination, distribution or copying of this communication is
>strictly prohibited. If you have received this communication in error,
>please notify the sender and erase this e-mail message immediately.
>---------------------------------------------------------------------------
