RE: XML and web services
Try changing Document to Element. I've found Axis will serialize this
without throwing exceptions BUT it does so incorrectly, which foobars
other SOAP implementations.
On Wed, 2002-10-30 at 16:07, Barry Lulas wrote:
> I get the following error message when using the Document version:
>
> The class org.w3c.dom.Document does not contain a default constructor, which
> is a requirement for a bean class. The class cannot be converted into an
> xml schema type. An xml schema anyType will be used to define this class in
> the wsdl file.
>
> Any way around this?
>
> -Original Message-
> From: James Black [mailto:jblack@;ieee.org]
> Sent: Wednesday, October 30, 2002 11:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XML and web services
>
>
> Barry Lulas wrote:
>
> > 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);
> > }
>
> This will allow portability, and works, but you may have problems if
> the XML is not well-formed.
>
> > OR
> >
> > public interface IMyInterface
> > {
> > public Document executeQuery(Document query);
> > }
>
> Never tried this, don't know if there is any portability issues
> involved.
>
> > OR
> >
> > public interface IMyInterface
> > {
> > public byte [] executeQuery(byte [] query);
> > }
>
> There is a penalty paid in creating the byte array, but it is portable
> and doesn't create problems if there is a problem with the XML. The file
> may also be larger due to the base64 encoding, though you could have the
> web service same both the string and byte array to a file and see what
> the size difference is.
>
> Your best bet is to try each method, call the client 10-100 times, and
> time it, see if the penalty paid is too high.
>
Re: XML and web services
Barry,
We're not using Java2WSDL. We just write the .wsdd file by hand and then
deploy it using the AdminClient, and let Axis create the WSDL.
Our .wsdd files look like this:
http://xml.apache.org/axis/wsdd/";
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java";>
I don't know whether this fits in with your development process at all,
but it works for us.
In other circumstances, we've also used the other techniques that have
come up in this thread (passing Strings and byte arrays) and both of
these worked for us too. Primarily we do this when we've got a sort of
chain of services and we don't want the overhead of converting to and
from Documents over and over again as the response passes through
intermediate services, or when the XML is coming from a static file.
Steve
Barry Lulas wrote:
Steven,
Thanks for the response. So how do you manage the provider, is this a
parameter in the Java2WSDL class?
Thanks!
-Original Message-
From: Steven Gollery [mailto:
Sent: Wednesday, October 30, 2002 12:00 PM
To: [EMAIL PROTECTED]
Subject: Re: XML and web services
Barry,
We've used services that received and returned Documents before. The
.wsdd for this has to set
provider="java:MSG"
instead of java:RPC. Also -- depending on which version of Axis you're
using -- you may find that you have to pass and return an Element[], but
I think that's not the case in 1.0.
The other thing we ran into is that with message-centric deployment,
there are options you don't have. For instance, we couldn't manage to
get the .wsdd to work if we wanted to deploy some of the methods of a
class as operations: we could deploy one method, or all methods.
We also couldn't figure out how to deploy a service where one method was
message-centric and others were RPC. But both these problems might be
just something we couldn't get right.
Hope this helps.
Steven Gollery
[EMAIL PROTECTED]
Barry Lulas wrote:
> I get the following error message when using the Document version:
>
> The class org.w3c.dom.Document does not contain a default constructor,
> which is a requirement for a bean class. The class cannot be
> converted into an xml schema type. An xml schema anyType will be used
> to define this class in the wsdl file.
>
> Any way around this?
>
> -Original Message-
> From: James Black [ mailto:jblack@;ieee.org ]
> Sent: Wednesday, October 30, 2002 11:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XML and web services
>
>
> Barry Lulas wrote:
>
> > 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);
> > }
>
> This will allow portability, and works, but you may have problems if
> the XML is not well-formed.
>
> > OR
> >
> > public interface IMyInterface
> > {
> > public Document executeQuery(Document query);
> > }
>
> Never tried this, don't know if there is any portability issues
> involved.
>
> > OR
> >
> > public interface IMyInterface
> > {
> > public byte [] executeQuery(byte [] query);
> > }
>
> There is a penalty paid in creating the byte array, but it is portable
> and doesn't create problems if there is a problem with the XML. The file
> may also be larger due to the base64 encoding, though you could have the
> web service same both the string and byte array to a file and see what
> the size difference is.
>
> Your best bet is to try each method, call the client 10-100 times, and
> time it, see if the penalty paid is too high.
>
Re: XML and web services
Barry,
We've used services that received and returned Documents before. The
.wsdd for this has to set
provider="java:MSG"
instead of java:RPC. Also -- depending on which version of Axis you're
using -- you may find that you have to pass and return an Element[], but
I think that's not the case in 1.0.
The other thing we ran into is that with message-centric deployment,
there are options you don't have. For instance, we couldn't manage to
get the .wsdd to work if we wanted to deploy some of the methods of a
class as operations: we could deploy one method, or all methods.
We also couldn't figure out how to deploy a service where one method was
message-centric and others were RPC. But both these problems might be
just something we couldn't get right.
Hope this helps.
Steven Gollery
[EMAIL PROTECTED]
Barry Lulas wrote:
I get the following error message when using the Document version:
The class org.w3c.dom.Document does not contain a default constructor,
which is a requirement for a bean class. The class cannot be
converted into an xml schema type. An xml schema anyType will be used
to define this class in the wsdl file.
Any way around this?
-Original Message-
From: James Black [mailto:jblack@;ieee.org ]
Sent: Wednesday, October 30, 2002 11:05 AM
To: [EMAIL PROTECTED]
Subject: Re: XML and web services
Barry Lulas wrote:
> 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);
> }
This will allow portability, and works, but you may have problems if
the XML is not well-formed.
> OR
>
> public interface IMyInterface
> {
> public Document executeQuery(Document query);
> }
Never tried this, don't know if there is any portability issues
involved.
> OR
>
> public interface IMyInterface
> {
> public byte [] executeQuery(byte [] query);
> }
There is a penalty paid in creating the byte array, but it is portable
and doesn't create problems if there is a problem with the XML. The file
may also be larger due to the base64 encoding, though you could have the
web service same both the string and byte array to a file and see what
the size difference is.
Your best bet is to try each method, call the client 10-100 times, and
time it, see if the penalty paid is too high.
Re: XML and web services
Barry Lulas wrote: > The class org.w3c.dom.Document does not contain a default constructor, > which is a requirement for a bean class. The class cannot be > converted into an xml schema type. An xml schema anyType will be used > to define this class in the wsdl file. > > Any way around this? Probably not. I have never used the Document class in a web service.
RE: XML and web services
Title: RE: XML and web services
I get the following error message when using the Document version:
The class org.w3c.dom.Document does not contain a default constructor, which is a requirement for a bean class. The class cannot be converted into an xml schema type. An xml schema anyType will be used to define this class in the wsdl file.
Any way around this?
-Original Message-
From: James Black [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 30, 2002 11:05 AM
To: [EMAIL PROTECTED]
Subject: Re: XML and web services
Barry Lulas wrote:
> 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);
> }
This will allow portability, and works, but you may have problems if
the XML is not well-formed.
> OR
>
> public interface IMyInterface
> {
> public Document executeQuery(Document query);
> }
Never tried this, don't know if there is any portability issues
involved.
> OR
>
> public interface IMyInterface
> {
> public byte [] executeQuery(byte [] query);
> }
There is a penalty paid in creating the byte array, but it is portable
and doesn't create problems if there is a problem with the XML. The file
may also be larger due to the base64 encoding, though you could have the
web service same both the string and byte array to a file and see what
the size difference is.
Your best bet is to try each method, call the client 10-100 times, and
time it, see if the penalty paid is too high.
Re: XML and web services
Barry Lulas wrote:
> 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);
> }
This will allow portability, and works, but you may have problems if
the XML is not well-formed.
> OR
>
> public interface IMyInterface
> {
> public Document executeQuery(Document query);
> }
Never tried this, don't know if there is any portability issues
involved.
> OR
>
> public interface IMyInterface
> {
> public byte [] executeQuery(byte [] query);
> }
There is a penalty paid in creating the byte array, but it is portable
and doesn't create problems if there is a problem with the XML. The file
may also be larger due to the base64 encoding, though you could have the
web service same both the string and byte array to a file and see what
the size difference is.
Your best bet is to try each method, call the client 10-100 times, and
time it, see if the penalty paid is too high.
RE: XML and web services
Title: RE: XML and web services
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:
> >
> >-
> >
> >
> >-
> >
> >
> >
> >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 that
>we
> >used to implement a 'Command Pattern' for the web service. The
> >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 us
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: > >- > > >- > > > >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 that we >used to implement a 'Command Pattern' for the web service. The >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. > > > > > > > > --- >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. ---
Re: XML and web services
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: > >- > > >- > > > >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 that we >used to implement a 'Command Pattern' for the web service. The >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. > > > > > > > > --- >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. ---
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: - - 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 that we used to implement a 'Command Pattern' for the web service. The 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. --- 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. ---
Re: XML and web services
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: - - 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 that we used to implement a 'Command Pattern' for the web service. The 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. --- 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. ---
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.
Re: XML and web services
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. Rgds, Ricky At 11:39 AM 10/29/2002 -0500, James Black wrote: Barry Lulas wrote: > What does your web service interface look like? I like the idea of > having multiple options I have an input bean where the options are set regarding the graph type that is desired (setting what is on the x, y, z axes and how to group the data). There is also a byte parameter that is used to determine how to return the result. I figure a byte is enough, as I will never have more than that as types to return. - - - - - http://schemas.xmlsoap.org/soap/http"; /> - - http://schemas.xmlsoap.org/soap/encoding/"; namespace="urn:GraphingTools" /> - http://schemas.xmlsoap.org/soap/encoding/"; namespace="urn:GraphingTools" />
Re: XML and web services
Barry Lulas wrote: > i see. what does the java interface look like? public byte[] getGraph(EpicVisitor input, byte retmode)
RE: XML and web services
Title: RE: XML and web services i see. what does the java interface look like? -Original Message- From: James Black [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 29, 2002 11:40 AM To: [EMAIL PROTECTED] Subject: Re: XML and web services Barry Lulas wrote: > What does your web service interface look like? I like the idea of > having multiple options I have an input bean where the options are set regarding the graph type that is desired (setting what is on the x, y, z axes and how to group the data). There is also a byte parameter that is used to determine how to return the result. I figure a byte is enough, as I will never have more than that as types to return. - - - - /> - type="intf:GraphingTools"> transport="http://schemas.xmlsoap.org/soap/http" /> - - encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:GraphingTools" /> - encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:GraphingTools" />
Re: XML and web services
Barry Lulas wrote: > What does your web service interface look like? I like the idea of > having multiple options I have an input bean where the options are set regarding the graph type that is desired (setting what is on the x, y, z axes and how to group the data). There is also a byte parameter that is used to determine how to return the result. I figure a byte is enough, as I will never have more than that as types to return. - - - - - http://schemas.xmlsoap.org/soap/http"; /> - - http://schemas.xmlsoap.org/soap/encoding/"; namespace="urn:GraphingTools" /> - http://schemas.xmlsoap.org/soap/encoding/"; namespace="urn:GraphingTools" />
RE: XML and web services
Title: RE: XML and web services James, What does your web service interface look like? I like the idea of having multiple options Barry Lulas [EMAIL PROTECTED] -Original Message- From: James Black [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 29, 2002 11:12 AM To: [EMAIL PROTECTED] Subject: Re: XML and web services "Weakliem, Gordon" wrote: > If you're doing document/literal, both string and byte[] are bad approaches > anyway. You take a hit on the encoding step, both in the conversion (memory > and processor) and on the wire, because base 64 is bigger, and you take a > hit to zip it if you try to alleviate the extra network traffic, and after > all that, you have to parse the XML again once it's decoded. On top of > that, your wdsdl doesn't reflect what the interface expects - now the > information that a particular parameter is XML is out of band. The right > approach long term is to leave it as XML, you could do String or byte[] as a > temporary workaround, but it's a bad general solution. In my case the byte array is the best choice as I have a web service that can return a zipped file, xml file, png or some other formats, but these are dictated by the client, so the client knows what to expect.
Re: XML and web services
"Weakliem, Gordon" wrote: > If you're doing document/literal, both string and byte[] are bad approaches > anyway. You take a hit on the encoding step, both in the conversion (memory > and processor) and on the wire, because base 64 is bigger, and you take a > hit to zip it if you try to alleviate the extra network traffic, and after > all that, you have to parse the XML again once it's decoded. On top of > that, your wdsdl doesn't reflect what the interface expects - now the > information that a particular parameter is XML is out of band. The right > approach long term is to leave it as XML, you could do String or byte[] as a > temporary workaround, but it's a bad general solution. In my case the byte array is the best choice as I have a web service that can return a zipped file, xml file, png or some other formats, but these are dictated by the client, so the client knows what to expect.
RE: XML and web services
I think what yopu're referring to is the nested CDATA problem, if your content contains a CDATA, you can't just write a DOM into a string and wrap the whole thing w/ a CDATA. The way around this is to either entity encode the XML or break into multiple CDATAs. IIRC, Axis will correctly handle encoding strings without any intervention, if it doesn't, it's a bug. If you're doing document/literal, both string and byte[] are bad approaches anyway. You take a hit on the encoding step, both in the conversion (memory and processor) and on the wire, because base 64 is bigger, and you take a hit to zip it if you try to alleviate the extra network traffic, and after all that, you have to parse the XML again once it's decoded. On top of that, your wdsdl doesn't reflect what the interface expects - now the information that a particular parameter is XML is out of band. The right approach long term is to leave it as XML, you could do String or byte[] as a temporary workaround, but it's a bad general solution. -Original Message- From: James Black [mailto:jblack@;ieee.org] Sent: Tuesday, October 29, 2002 8:28 AM To: [EMAIL PROTECTED] Subject: Re: XML and web services Mike Hearn wrote: > I assume you're referring to character encoding issues here? I don't > understand what problems the soap wrapper could cause.. From what I understand, when using a CDATA element, for example, there can be things that will cause some problems with the XML parser that is trying to figure out the message from the headers. Using a byte array ensures that your xml file will not mess up the parsing. > > > James Black wrote: > >> Barry Lulas wrote: >> >> >> > I realize this is an Axis user group, but I wanted to pick your >> > brains >> > on a related issue. >> > >> > I have a generic web service that I deploy via Axis. The web >> > service >> > takes in an XML file as a request and returns an XML file as a >> > response. My question is what is the best way to pass XML data >> > to/from a web service? Should I simply use strings? >> > >> > Any advise would be appreciated... >> > >> Pass the xml file as a byte array, else you will have problems >> with >> the xml wrapper that soap uses. The byte array is base64 encoded, so >> it >> is a safe way to send it around. >> Also, you may want to zip the byte array before sending the xml >> file, >> to help cut down on size. >> >> >> >> The information in this electronic mail message is sender's business Confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this Internet electronic mail message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. The sender believes that this E-mail and any attachments were free of any virus, worm, Trojan horse, and/or malicious code when sent. This message and its attachments could have been infected during transmission. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective and remedial action about viruses and other defects. Galileo International is not liable for any loss or damage arising in any way from this message or its attachments.
Re: XML and web services
A CDATA section in the XML you're trying to send back and forth? If you try to send invalid XML, or stuff that conflicts with the SOAP wrappers then yeah, I can see that, but what if you just want to send some simple elements with attributes? James Black wrote: Mike Hearn wrote: I assume you're referring to character encoding issues here? I don't understand what problems the soap wrapper could cause.. From what I understand, when using a CDATA element, for example, there can be things that will cause some problems with the XML parser that is trying to figure out the message from the headers. Using a byte array ensures that your xml file will not mess up the parsing. James Black wrote: Barry Lulas wrote: I realize this is an Axis user group, but I wanted to pick your brains on a related issue. I have a generic web service that I deploy via Axis. The web service takes in an XML file as a request and returns an XML file as a response. My question is what is the best way to pass XML data to/from a web service? Should I simply use strings? Any advise would be appreciated... Pass the xml file as a byte array, else you will have problems with the xml wrapper that soap uses. The byte array is base64 encoded, so it is a safe way to send it around. Also, you may want to zip the byte array before sending the xml file, to help cut down on size.
Re: XML and web services
Mike Hearn wrote: > I assume you're referring to character encoding issues here? I don't > understand what problems the soap wrapper could cause.. From what I understand, when using a CDATA element, for example, there can be things that will cause some problems with the XML parser that is trying to figure out the message from the headers. Using a byte array ensures that your xml file will not mess up the parsing. > > > James Black wrote: > >> Barry Lulas wrote: >> >> >> > I realize this is an Axis user group, but I wanted to pick your >> > brains >> > on a related issue. >> > >> > I have a generic web service that I deploy via Axis. The web >> > service >> > takes in an XML file as a request and returns an XML file as a >> > response. My question is what is the best way to pass XML data >> > to/from a web service? Should I simply use strings? >> > >> > Any advise would be appreciated... >> > >> Pass the xml file as a byte array, else you will have problems >> with >> the xml wrapper that soap uses. The byte array is base64 encoded, so >> it >> is a safe way to send it around. >> Also, you may want to zip the byte array before sending the xml >> file, >> to help cut down on size. >> >> >> >>
Re: XML and web services
Barry Lulas wrote: > how do clients pass the xml file as a byte-array? In Java it is pretty easy, just call the getBytes method, and it will return the array of bytes that represents the string.
Re: XML and web services
I assume you're referring to character encoding issues here? I don't understand what problems the soap wrapper could cause.. James Black wrote: Barry Lulas wrote: I realize this is an Axis user group, but I wanted to pick your brains on a related issue. I have a generic web service that I deploy via Axis. The web service takes in an XML file as a request and returns an XML file as a response. My question is what is the best way to pass XML data to/from a web service? Should I simply use strings? Any advise would be appreciated... Pass the xml file as a byte array, else you will have problems with the xml wrapper that soap uses. The byte array is base64 encoded, so it is a safe way to send it around. Also, you may want to zip the byte array before sending the xml file, to help cut down on size.
RE: XML and web services
Title: RE: XML and web services how do clients pass the xml file as a byte-array? -Original Message- From: James Black [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 29, 2002 9:51 AM To: [EMAIL PROTECTED] Subject: Re: XML and web services Barry Lulas wrote: > I realize this is an Axis user group, but I wanted to pick your brains > on a related issue. > > I have a generic web service that I deploy via Axis. The web service > takes in an XML file as a request and returns an XML file as a > response. My question is what is the best way to pass XML data > to/from a web service? Should I simply use strings? > > Any advise would be appreciated... Pass the xml file as a byte array, else you will have problems with the xml wrapper that soap uses. The byte array is base64 encoded, so it is a safe way to send it around. Also, you may want to zip the byte array before sending the xml file, to help cut down on size.
Re: XML and web services
Barry Lulas wrote: > I realize this is an Axis user group, but I wanted to pick your brains > on a related issue. > > I have a generic web service that I deploy via Axis. The web service > takes in an XML file as a request and returns an XML file as a > response. My question is what is the best way to pass XML data > to/from a web service? Should I simply use strings? > > Any advise would be appreciated... Pass the xml file as a byte array, else you will have problems with the xml wrapper that soap uses. The byte array is base64 encoded, so it is a safe way to send it around. Also, you may want to zip the byte array before sending the xml file, to help cut down on size.
RE: XML and web services
Title: RE: XML and web services Thanks Mike, keep me informed as to the status. -Original Message- From: Mike Hearn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 29, 2002 9:02 AM To: [EMAIL PROTECTED] Subject: Re: XML and web services The best way in theory is to simply pass DOMs in whichever languages you are using. The SOAP engine then uses literalXML encoding to make it happen - but this functionality is broken in Axis at the moment it appears, and seems to have been for some time. This is really quite a serious issue if it really is a bug, and I intend to chase the developers about it either this week or next. If/when I find a solution/write a patch I'll let you know. For now you can pass strings back and forth, or use the message form. thanks -mike Barry Lulas wrote: > I realize this is an Axis user group, but I wanted to pick your brains > on a related issue. > > I have a generic web service that I deploy via Axis. The web service > takes in an XML file as a request and returns an XML file as a > response. My question is what is the best way to pass XML data > to/from a web service? Should I simply use strings? > > Any advise would be appreciated... >
Re: XML and web services
The best way in theory is to simply pass DOMs in whichever languages you are using. The SOAP engine then uses literalXML encoding to make it happen - but this functionality is broken in Axis at the moment it appears, and seems to have been for some time. This is really quite a serious issue if it really is a bug, and I intend to chase the developers about it either this week or next. If/when I find a solution/write a patch I'll let you know. For now you can pass strings back and forth, or use the message form. thanks -mike Barry Lulas wrote: I realize this is an Axis user group, but I wanted to pick your brains on a related issue. I have a generic web service that I deploy via Axis. The web service takes in an XML file as a request and returns an XML file as a response. My question is what is the best way to pass XML data to/from a web service? Should I simply use strings? Any advise would be appreciated...
XML and web services
Title: XML and web services I realize this is an Axis user group, but I wanted to pick your brains on a related issue. I have a generic web service that I deploy via Axis. The web service takes in an XML file as a request and returns an XML file as a response. My question is what is the best way to pass XML data to/from a web service? Should I simply use strings? Any advise would be appreciated...
