You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by "Crawford, Matt" <MC...@erac.com> on 2002/11/21 18:35:21 UTC
Document style web services
Hello,
Has anyone had experience with document style web services similar to the
one shown below? The users guide indicates that "Document services do not
use any encoding (so in particular, you won't see multiref object
serialization or SOAP-style arrays on the wire) but DO still do XML<->Java
databinding."
I'm looking to leverage this databinding to serialize and deserialize xml
documents in the body, but the samples/encoding (from what I can tell) deals
with rpc style, not document style.
Thanks,
Matt Crawford
Enterprise Rent-A-Car
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" >
<SOAP-ENV:Body>
<SomeXmlElement xmlns="http://www.somUri.org/someClassName"
anAttribute="foo">
<AnotherXmlElement value="X"/>
<AThirdXmlElement value="three"/>
</SomeXmlElement>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Would somehow map to (with appropriate typeMapping entries)
public class SomeXmlService() {
public SomeXmlResponse method(SomeXmlElement arg0) {
return new SomeXmlReponse();
}
}
Re: Document style web services
Posted by Martin Jericho <ma...@jabmail.com>.
Dennis,
My experience is that Java2WSDL in Axis 1.0 has too many bugs to generate
document/literal style WSDL, but if you can generate it by some other means,
the WSDL2Java and bean marshalling seem to work fine.
The reason you can't have multireferencing in document style calls is
because the document is validated against the schema. If you define the
schema to allow IDs and REFs on every element, you can implement the
multirefs yourself, but this would make your schema virtually unreadable,
very complicated, and probably less robust.
Martin Jericho
----- Original Message -----
From: "Dennis Sosnoski" <dm...@sosnoski.com>
To: <ax...@xml.apache.org>
Sent: Friday, November 22, 2002 7:03 AM
Subject: Re: Document style web services
> Hi Anne,
>
> Does Axis support automatic marshalling of document-style messages? I
> was under the impression it does not, which was why I suggested a
> DataBindingProvider might be useful to add this support. I agree that
> document-style is a better approach for the future, though I'd hardly
> call it a "predominant consensus" at this point. AFAIK document style
> interfaces are not as widely supported as RPC style, though, and I'm
> surprised to see your statement that most SOAP implementations support
> automatic marshalling for document style. Can you give me any figures
> for this?
>
> As for "no problem building automatic serializers" I have to disagree. A
> Schema definition does not, in general, provide enough information to
> directly map to Java data structures. If you use an approach where the
> data structures are either pre-generated from the Schema or constrained
> to obey a predefined mapping to and from the Schema you can get around
> this, but that's hardly automatic.
>
> I'm also puzzled by your statement that it's difficult handle
> multi-referencing object structures using document style. Is there a
> reason this can't be handled with ID/IDREF or key/keyref links?
>
> Thanks,
>
> - Dennis
>
> Dennis M. Sosnoski
> Enterprise Java, XML, and Web Services Support
> http://www.sosnoski.com
>
> Anne Thomas Manes wrote:
>
> >Dennis,
> >
> >This is a pretty antiquated view of document style. Document style is no
> >longer used just for XML messaging. Most SOAP implementations support
> >automatic marshalling of both RPC-style and document-style messages. As
long
> >as you have a WSDL description of the message structure, there's no
problem
> >building automatic serializers.
> >
> >The predominant consensus in the industry at this point is to use
> >document-style by default. Document style is much easier to validate,
> >transform, and manipulate. The primary reason to consider using
rpc/encoded
> >is if you need to send multi-referencing object structures. SOAP encoding
> >does a really nice job marshalling these structures. It's much harded to
> >represent them using literal XML Schema. But if you're not using
multi-refs,
> >it's a better practice to use document-style.
> >
> >Regards,
> >Anne
> >
> >
> >
> >>-----Original Message-----
> >>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> >>Sent: Thursday, November 21, 2002 1:25 PM
> >>To: axis-user@xml.apache.org
> >>Subject: Re: Document style web services
> >>
> >>
> >>Hi Matt,
> >>
> >>The whole point of document style is that your application gets passed
> >>the XML message payload as XML document fragments. See the "message"
> >>sample for an example of this. With a document style interface your
> >>class would look like:
> >>
> >>public class SomeXMLService {
> >> public Element[] someXMLMethod(Element[] elems) {
> >> ...
> >> }
> >>}
> >>
> >>If you want to convert the XML into objects you need to do it yourself,
> >>perhaps using a framework such as Castor (http://www.castor.org). I know
> >>there's been some integration of Castor with Axis, though I think this
> >>was for custom serialization with RPC style.
> >>
> >>This brings up an interesting point, though. Why not have a Java
> >>DataBindingProvider as a replacement for the MsgProvider? This should
> >>allow easy use of document style while converting seamlessly between XML
> >>and objects without the application needing any special code. I'm
> >>looking into some data binding code currently, perhaps I'll see if I can
> >>work in this direction.
> >>
> >> - Dennis
> >>
> >>Dennis M. Sosnoski
> >>Enterprise Java, XML, and Web Services Support
> >>http://www.sosnoski.com
> >>
> >>
> >
> >
>
>
Re: Document style web services
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Whoops, in looking at the user manual I see that Axis *does* support
automatic binding for simple bean-like structures. AFAIK the rest of
these comments still apply, though.
Sorry for providing wrong information earlier in this thread, Matt -
check the "Document / Wrapped services" section in the user guide for
some (correct) information on this. Looks like you should be able to do
what you wanted directly.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
http://www.sosnoski.com
Dennis Sosnoski wrote:
> Hi Anne,
>
> Does Axis support automatic marshalling of document-style messages? I
> was under the impression it does not, which was why I suggested a
> DataBindingProvider might be useful to add this support. I agree that
> document-style is a better approach for the future, though I'd hardly
> call it a "predominant consensus" at this point. AFAIK document style
> interfaces are not as widely supported as RPC style, though, and I'm
> surprised to see your statement that most SOAP implementations support
> automatic marshalling for document style. Can you give me any figures
> for this?
>
> As for "no problem building automatic serializers" I have to disagree.
> A Schema definition does not, in general, provide enough information
> to directly map to Java data structures. If you use an approach where
> the data structures are either pre-generated from the Schema or
> constrained to obey a predefined mapping to and from the Schema you
> can get around this, but that's hardly automatic.
>
> I'm also puzzled by your statement that it's difficult handle
> multi-referencing object structures using document style. Is there a
> reason this can't be handled with ID/IDREF or key/keyref links?
>
> Thanks,
>
> - Dennis
>
> Dennis M. Sosnoski
> Enterprise Java, XML, and Web Services Support
> http://www.sosnoski.com
>
> Anne Thomas Manes wrote:
>
>> Dennis,
>>
>> This is a pretty antiquated view of document style. Document style is no
>> longer used just for XML messaging. Most SOAP implementations support
>> automatic marshalling of both RPC-style and document-style messages.
>> As long
>> as you have a WSDL description of the message structure, there's no
>> problem
>> building automatic serializers.
>>
>> The predominant consensus in the industry at this point is to use
>> document-style by default. Document style is much easier to validate,
>> transform, and manipulate. The primary reason to consider using
>> rpc/encoded
>> is if you need to send multi-referencing object structures. SOAP
>> encoding
>> does a really nice job marshalling these structures. It's much harded to
>> represent them using literal XML Schema. But if you're not using
>> multi-refs,
>> it's a better practice to use document-style.
>>
>> Regards,
>> Anne
>>
>>
>>
>>> -----Original Message-----
>>> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
>>> Sent: Thursday, November 21, 2002 1:25 PM
>>> To: axis-user@xml.apache.org
>>> Subject: Re: Document style web services
>>>
>>>
>>> Hi Matt,
>>>
>>> The whole point of document style is that your application gets passed
>>> the XML message payload as XML document fragments. See the "message"
>>> sample for an example of this. With a document style interface your
>>> class would look like:
>>>
>>> public class SomeXMLService {
>>> public Element[] someXMLMethod(Element[] elems) {
>>> ...
>>> }
>>> }
>>>
>>> If you want to convert the XML into objects you need to do it yourself,
>>> perhaps using a framework such as Castor (http://www.castor.org). I know
>>> there's been some integration of Castor with Axis, though I think this
>>> was for custom serialization with RPC style.
>>>
>>> This brings up an interesting point, though. Why not have a Java
>>> DataBindingProvider as a replacement for the MsgProvider? This should
>>> allow easy use of document style while converting seamlessly between XML
>>> and objects without the application needing any special code. I'm
>>> looking into some data binding code currently, perhaps I'll see if I can
>>> work in this direction.
>>>
>>> - Dennis
>>>
>>> Dennis M. Sosnoski
>>> Enterprise Java, XML, and Web Services Support
>>> http://www.sosnoski.com
>>>
>>
>>
>>
>
Re: Document style web services
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Dennis Sosnoski" <dm...@sosnoski.com>
To: <ax...@xml.apache.org>
Sent: Thursday, November 21, 2002 1:03 PM
Subject: Re: Document style web services
>
> Does Axis support automatic marshalling of document-style messages? I
> was under the impression it does not, which was why I suggested a
> DataBindingProvider might be useful to add this support.
It had better, otherwise there would be a lot more interop bugreps vis-a-vis
.net than now, as .net defaults to doc/lit
> I agree that
> document-style is a better approach for the future, though I'd hardly
> call it a "predominant consensus" at this point. AFAIK document style
> interfaces are not as widely supported as RPC style, though, and I'm
> surprised to see your statement that most SOAP implementations support
> automatic marshalling for document style. Can you give me any figures
> for this?
MS soap toolkit: rpc/enc by default, can do doc/lit
.NET ASMX: doc/lit, can do rpc/enc with the loss of the DataSet class that
only goes over as doc/lit
.NET remoting: dont know. May well be rpc/enc
.Axis: rpc/enc is default, can do doc/lit though this needs more work. work
includes documentation
I think the fact that the early toolkits are biased to rpc/enc may be a
historical artifact; in soap0.9, rpc/enc was all there was, and it is only
as XSD support has grown that doc/lit becomes viable. But there are also
some ideological issues, the split between 'SOAP as a verbose RPC
marshalling layer', that JAX-RPC views it, and 'SOAP as asynchronous XML
message exchange', which is really where we should (IMHO) be going on
account of scalability and long-haul benefits. Axis isnt there yet, and Java
code seems biased towards JAX-RPC. Though this is not necessarily a choice
of the developer; unless they get into reading the soap specs, they will
probably go with whatever the toolkit gives them.
RE: Document style web services
Posted by Anne Thomas Manes <an...@manes.net>.
> -----Original Message-----
> From: Steve Loughran [mailto:steve_l@iseran.com]
> Sent: Thursday, November 21, 2002 7:08 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
> At the same time, I cant help treating WS-I mandates with some less
> seriousness than W3C. W3C are laying down the soap1.1 spec, the
> foundations
> of everything. WS-I are reprinting truckloads of specs that are being
> published and mandated without going through the 'working code'
> rigorousness
> of IETF processs.
W3C is doing SOAP 1.2, not SOAP 1.1. SOAP 1.1 will never be standardized.
Unfortunately, we still need to live with SOAP 1.1, with all its
inconsistencies and inadequacies. WS-I is trying to solve the interop
issues that result from the looseness of the SOAP 1.1 spec. And WS-I is
basing their work on "working code". They draw from real implementations
suffering from real interoperability issues, and they're designing a set
of profiles (i.e., constraints) that you can follow to ensure that you
build interoperable Web services. No -- these profiles aren't the
foundation specs. And WS-I doesn't presume to call itself a standards
organization. They are designing best practices.
> It'd be nice if Sun got involved with Axis too.
Not likely. They've got JWSDP.
Anne
Re: Document style web services
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Dennis Sosnoski" <dm...@sosnoski.com>
To: <ax...@xml.apache.org>
Sent: Thursday, November 21, 2002 15:41
Subject: Re: Document style web services
> I think WS-I has serious credibility problems, especially since it came
> out that Microsoft's participation was conditional on Sun being excluded
> from a major role in the organization. To quote from a Bill Gates memo
> in reference to WS-I which was made public during the antitrust trial
> (as reported in http://news.zdnet.co.uk/story/0,,t288-s2110205,00.html,
> for one source): "I can live with this if we have the positioning
> clearly in our favour. In particular, Sun not being one of the
> movers/announcers/founding members." I'm sure that, as a participant in
> WS-I, you're familiar with these issues, Anne. This credibility problem
> is certainly going to influence how WS-I proposals are treated by the
> industry.
To be fair, WS-I isnt that bad a spec, despite its adoption of DIME as the
binary attachment mechanism. Keith and the others did work reasonably well,
and I've only submitted one request for clarification on it so far (whether
clients must handle 302 redirects, or whether it was just a "may" or a
"should"). Have I got a reply yet? Nope.
At the same time, I cant help treating WS-I mandates with some less
seriousness than W3C. W3C are laying down the soap1.1 spec, the foundations
of everything. WS-I are reprinting truckloads of specs that are being
published and mandated without going through the 'working code' rigorousness
of IETF processs.
> If Sun becomes a full coequal participant in the WS-I organization it'll
> go a long way toward establishing WS-I as a bona fide forum for
> supporting interoperability. Given Sun's ownership of Java and control
> over Java standards it's hard to take an organization that excludes Sun
> seriously on these issues.
It'd be nice if Sun got involved with Axis too.
RE: Document style web services
Posted by Anne Thomas Manes <an...@manes.net>.
That's old news.
Sun is now a member of WS-I. WS-I has added two new seats to the board, and
there will be a vote in March to elect the new board members. Let's hope
that Sun gets elected.
http://www.aspnews.com/news/article/0,,4191_1488041,00.html
Anne
> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Thursday, November 21, 2002 6:41 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
>
> Anne Thomas Manes wrote:
>
> >WS-I has just published its Basic Profile
> >draft, which only supports document-style. Pretty much every
> SOAP vendor is
> >involved with WS-I, so it won't be long before all SOAP implementations
> >generate document style by default.
> >
> I think WS-I has serious credibility problems, especially since it came
> out that Microsoft's participation was conditional on Sun being excluded
> from a major role in the organization. To quote from a Bill Gates memo
> in reference to WS-I which was made public during the antitrust trial
> (as reported in http://news.zdnet.co.uk/story/0,,t288-s2110205,00.html,
> for one source): "I can live with this if we have the positioning
> clearly in our favour. In particular, Sun not being one of the
> movers/announcers/founding members." I'm sure that, as a participant in
> WS-I, you're familiar with these issues, Anne. This credibility problem
> is certainly going to influence how WS-I proposals are treated by the
> industry.
>
> If Sun becomes a full coequal participant in the WS-I organization it'll
> go a long way toward establishing WS-I as a bona fide forum for
> supporting interoperability. Given Sun's ownership of Java and control
> over Java standards it's hard to take an organization that excludes Sun
> seriously on these issues.
>
> - Dennis
>
>
>
>
Re: Document style web services
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Anne Thomas Manes wrote:
>WS-I has just published its Basic Profile
>draft, which only supports document-style. Pretty much every SOAP vendor is
>involved with WS-I, so it won't be long before all SOAP implementations
>generate document style by default.
>
I think WS-I has serious credibility problems, especially since it came
out that Microsoft's participation was conditional on Sun being excluded
from a major role in the organization. To quote from a Bill Gates memo
in reference to WS-I which was made public during the antitrust trial
(as reported in http://news.zdnet.co.uk/story/0,,t288-s2110205,00.html,
for one source): "I can live with this if we have the positioning
clearly in our favour. In particular, Sun not being one of the
movers/announcers/founding members." I'm sure that, as a participant in
WS-I, you're familiar with these issues, Anne. This credibility problem
is certainly going to influence how WS-I proposals are treated by the
industry.
If Sun becomes a full coequal participant in the WS-I organization it'll
go a long way toward establishing WS-I as a bona fide forum for
supporting interoperability. Given Sun's ownership of Java and control
over Java standards it's hard to take an organization that excludes Sun
seriously on these issues.
- Dennis
Re: UPNP
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Anne Thomas Manes" <an...@manes.net>
To: <ax...@xml.apache.org>
Sent: Friday, November 22, 2002 18:55
Subject: RE: UPNP
> I haven't heard anything about UPNP for about a year. The only device that
I
> ever heard of that was UPNP certified was the Intel AnyPoint Networking
> Gateway
(http://www.samsungelectronics.com/homenetwork/news/news_005.html).
>
> UPNP definitely predates WSDL.
There is that UPNP stuff in winxp, which means that MS secretly have a fifth
SOAP stack to go with the two .net implementations, MSSTK and ATL server.
But I havent seen any UPNP devices. I could find out what is going on in the
printer area, but then I wouldnt be able to talk about it. From what I
recall, there were issues with UPnPs chattiness counting against its
usability in the office (there were no aggregation of discovery mcasts via
discovery servers, a la SLPv2), leaving the home. But in the home LAN hosted
printers are a rarity, USB to the home PC is the centre of attention.
So I'll ignore Upnp. Its a shame, because if it was real WSDL/SOAP with the
discovery mechanism decoupled from the interaction, a UPNP printer would
just be a printer service on the lan that you could find through discovery,
UDDI (!), hardcoding, etc, and talk direct to it from your app if you so
chose.
-steve
RE: UPNP
Posted by Anne Thomas Manes <an...@manes.net>.
I haven't heard anything about UPNP for about a year. The only device that I
ever heard of that was UPNP certified was the Intel AnyPoint Networking
Gateway (http://www.samsungelectronics.com/homenetwork/news/news_005.html).
UPNP definitely predates WSDL.
> -----Original Message-----
> From: Steve Loughran [mailto:steve_l@iseran.com]
> Sent: Friday, November 22, 2002 9:12 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
>
>
>
>
>
> ----- Original Message -----
> From: "Anne Thomas Manes" <an...@manes.net>
> To: <ax...@xml.apache.org>
> Sent: Friday, November 22, 2002 5:59 PM
> Subject: RE: Document style web services
>
>
> > Yes -- UPNP adopted SOAP a long, long time ago. (I think it was 0.9 --
> those
> > were the days when the only option was rpc/enc.) IIRC, the first
> > implementation of UPNP used SOAP. (although the development work on the
> spec
> > started before SOAP)
> >
> > Anne
>
> I need to find a UPNP service and see what soapscope thinks about it.
>
> I see the technology is still oblivious to WSDL..
>
Re: Document style web services
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Anne Thomas Manes" <an...@manes.net>
To: <ax...@xml.apache.org>
Sent: Friday, November 22, 2002 5:59 PM
Subject: RE: Document style web services
> Yes -- UPNP adopted SOAP a long, long time ago. (I think it was 0.9 --
those
> were the days when the only option was rpc/enc.) IIRC, the first
> implementation of UPNP used SOAP. (although the development work on the
spec
> started before SOAP)
>
> Anne
I need to find a UPNP service and see what soapscope thinks about it.
I see the technology is still oblivious to WSDL..
RE: Document style web services
Posted by Anne Thomas Manes <an...@manes.net>.
Yes -- UPNP adopted SOAP a long, long time ago. (I think it was 0.9 -- those
were the days when the only option was rpc/enc.) IIRC, the first
implementation of UPNP used SOAP. (although the development work on the spec
started before SOAP)
Anne
> -----Original Message-----
> From: Steve Loughran [mailto:steve_l@iseran.com]
> Sent: Friday, November 22, 2002 6:42 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
>
> I've just been looking at the UPNP specs, and lo and behold, UPNP now
> mandates SOAP.
>
> http://www.upnp.org/download/UPnPDA10_20000613.htm
>
> Looks to me from the examples that UPNP devices talk rpc/enc, maybe 0.9 or
> 1.0 soap at that. Which means if they shipped in any quantity, they would
> ensconce rpc/enc as the most widely spread, maybe even widely used soap
> option.
>
> POST path of control URL HTTP/1.1
> HOST: host of control URL:port of control URL
> CONTENT-LENGTH: bytes in body
> CONTENT-TYPE: text/xml; charset="utf-8"
> SOAPACTION: "urn:schemas-upnp-org:service:serviceType:v#actionName"
>
> <s:Envelope
> xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
> s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
> <s:Body>
> <u:actionName xmlns:u="urn:schemas-upnp-org:service:serviceType:v">
> <argumentName>in arg value</argumentName>
> other in args and their values go here, if any
> </u:actionName>
> </s:Body>
> </s:Envelope>
>
> ...the spec looks a bit like SOAP came along half way through it; anyone
> know any more about the history?
>
> -steve
>
Re: Document style web services
Posted by Steve Loughran <st...@iseran.com>.
I've just been looking at the UPNP specs, and lo and behold, UPNP now
mandates SOAP.
http://www.upnp.org/download/UPnPDA10_20000613.htm
Looks to me from the examples that UPNP devices talk rpc/enc, maybe 0.9 or
1.0 soap at that. Which means if they shipped in any quantity, they would
ensconce rpc/enc as the most widely spread, maybe even widely used soap
option.
POST path of control URL HTTP/1.1
HOST: host of control URL:port of control URL
CONTENT-LENGTH: bytes in body
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: "urn:schemas-upnp-org:service:serviceType:v#actionName"
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:actionName xmlns:u="urn:schemas-upnp-org:service:serviceType:v">
<argumentName>in arg value</argumentName>
other in args and their values go here, if any
</u:actionName>
</s:Body>
</s:Envelope>
...the spec looks a bit like SOAP came along half way through it; anyone
know any more about the history?
-steve
RE: Document style web services
Posted by Anne Thomas Manes <an...@manes.net>.
I'm not convinced that the Apache containers are the de facto standard.
Both WASP and GLUE use .NET-compatible containers by default, although they
also support Apache-compatible containers. (I haven't checked, but I suspect
that BEA, Cape Clear, and XMLBus support .NET-compatible containers by
default also.)
See:
http://www.systinet.com/doc/wasp_jserver/messageProcessing/serializationFram
ework.html#messageProcessing.serializationFramework.javaCollections
http://www.themindelectric.com/docs/glue/guide/mapping/collections.html
Anne
> -----Original Message-----
> From: Steve Loughran [mailto:steve_l@iseran.com]
> Sent: Friday, November 22, 2002 1:48 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
>
>
> ----- Original Message -----
> From: "Anne Thomas Manes" <an...@manes.net>
> To: <ax...@xml.apache.org>
> Sent: Friday, November 22, 2002 10:14 AM
> Subject: RE: Document style web services
>
>
> > From what I've seen, most vendors have designed containers that are
> > compatible with .NET. Perhaps Axis should do the same.
>
>
> Are we talking about data types like List and HashTable? I dont think .NET
> puts them on the wire: no serializer, see.
>
> Its actually the Apache SAOP containers that are the de-facto standard...
>
Re: Document style web services
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Anne Thomas Manes" <an...@manes.net>
To: <ax...@xml.apache.org>
Sent: Friday, November 22, 2002 10:14 AM
Subject: RE: Document style web services
> From what I've seen, most vendors have designed containers that are
> compatible with .NET. Perhaps Axis should do the same.
Are we talking about data types like List and HashTable? I dont think .NET
puts them on the wire: no serializer, see.
Its actually the Apache SAOP containers that are the de-facto standard...
RE: Document style web services
Posted by Anne Thomas Manes <an...@manes.net>.
>From what I've seen, most vendors have designed containers that are
compatible with .NET. Perhaps Axis should do the same.
> -----Original Message-----
> From: Steve Loughran [mailto:steve_l@iseran.com]
> Sent: Friday, November 22, 2002 12:37 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
>
>
> ----- Original Message -----
> From: "Anne Thomas Manes" <an...@manes.net>
> To: <ax...@xml.apache.org>
> Sent: Thursday, November 21, 2002 5:21 PM
> Subject: RE: Document style web services
>
>
> > Personally I think one of Axis's most challenging issues is
> > that Axis containers aren't compatible with .NET containers. And I don't
> > think that WS-I really addresses this issue.
>
> That is one of my pet peeves. SOAPBuilders arent looking at it either ...
> hints are that Sun didnt want that group laying down 'standards'.
> One option
> is to write helper classes for .NET so it can import and export the apache
> containers
>
Re: Document style web services
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Anne Thomas Manes" <an...@manes.net>
To: <ax...@xml.apache.org>
Sent: Thursday, November 21, 2002 5:21 PM
Subject: RE: Document style web services
> Personally I think one of Axis's most challenging issues is
> that Axis containers aren't compatible with .NET containers. And I don't
> think that WS-I really addresses this issue.
That is one of my pet peeves. SOAPBuilders arent looking at it either ...
hints are that Sun didnt want that group laying down 'standards'. One option
is to write helper classes for .NET so it can import and export the apache
containers
RE: Document style web services
Posted by Anne Thomas Manes <an...@manes.net>.
> -----Original Message-----
> From: Steve Loughran [mailto:steve_l@iseran.com]
> Sent: Thursday, November 21, 2002 7:11 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
> Must be the 3.0 version of MSSTK that defaults to document,
> right, as it was
> rpc/enc before, I believe.
That's correct.
> I dont think Apache is a member. People who work on the projects may have
> day jobs by members (disclaimer, me too), but that doesnt mean that the
> apache codebase will embrace the WS-I spec wholeheartedly, as that is a
> matter for a democratic vote with the usual apache veto rules.
True. The real question is whether users/customers will demand it, and
whether lack of WS-I conformance will cause users to select a different
implementation. Personally I think one of Axis's most challenging issues is
that Axis containers aren't compatible with .NET containers. And I don't
think that WS-I really addresses this issue.
Anne
Re: Document style web services
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Anne Thomas Manes" <an...@manes.net>
To: <ax...@xml.apache.org>
Sent: Thursday, November 21, 2002 14:25
Subject: RE: Document style web services
>
> Microsoft started the "document style by default" trend. Both MS SOAP
> Toolkit and .NET Framework generate document-style by default.
Must be the 3.0 version of MSSTK that defaults to document, right, as it was
rpc/enc before, I believe.
> Pretty much every SOAP vendor is
> involved with WS-I, so it won't be long before all SOAP implementations
> generate document style by default.
>
I dont think Apache is a member. People who work on the projects may have
day jobs by members (disclaimer, me too), but that doesnt mean that the
apache codebase will embrace the WS-I spec wholeheartedly, as that is a
matter for a democratic vote with the usual apache veto rules.
Re: Document style web services
Posted by Eric Rajkovic <er...@oracle.com>.
Anne,
Just a little addition to your comment on WS-I BP:
"WS-I has just published its Basic Profile
draft, which only supports document-style"
In the current published revision, the profile support both rpc
and document styles. It only restrict the use to literal.
eric
RE: Document style web services
Posted by Anne Thomas Manes <an...@manes.net>.
As you said in a subsequent response, Axis provides rudimentary support for
automatic marshalling of document-style messages (simple beans). This
support is less than what you can find in some of the other Java SOAP
implementations. See, for example, WASP's serialization framework:
http://www.systinet.com/doc/wasp_jserver/messageProcessing/serializationFram
ework.html. WASP provides equivalent serialization capabilities in RPC and
Document styles. And WASP's java2wsdl tool generates document-style by
default.
Microsoft started the "document style by default" trend. Both MS SOAP
Toolkit and .NET Framework generate document-style by default. Most of the
other SOAP vendors followed suit. WS-I has just published its Basic Profile
draft, which only supports document-style. Pretty much every SOAP vendor is
involved with WS-I, so it won't be long before all SOAP implementations
generate document style by default.
I agree with you that it isn't always trivial to map an existing schema to
existing Java objects. When I said "no problem building automatic
serializers", I was referring to a situation where you have the ability to
generate one from the other.
RE: multi-refs.
You can certainly design a schema that includes type=idref or keyref. That's
how soap encoding works (although soap encoding doesn't necessarily conform
to a schema, which is why it so hard to validate.)
Anne
> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Thursday, November 21, 2002 4:04 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
>
> Hi Anne,
>
> Does Axis support automatic marshalling of document-style messages? I
> was under the impression it does not, which was why I suggested a
> DataBindingProvider might be useful to add this support. I agree that
> document-style is a better approach for the future, though I'd hardly
> call it a "predominant consensus" at this point. AFAIK document style
> interfaces are not as widely supported as RPC style, though, and I'm
> surprised to see your statement that most SOAP implementations support
> automatic marshalling for document style. Can you give me any figures
> for this?
>
> As for "no problem building automatic serializers" I have to disagree. A
> Schema definition does not, in general, provide enough information to
> directly map to Java data structures. If you use an approach where the
> data structures are either pre-generated from the Schema or constrained
> to obey a predefined mapping to and from the Schema you can get around
> this, but that's hardly automatic.
>
> I'm also puzzled by your statement that it's difficult handle
> multi-referencing object structures using document style. Is there a
> reason this can't be handled with ID/IDREF or key/keyref links?
>
> Thanks,
>
> - Dennis
>
> Dennis M. Sosnoski
> Enterprise Java, XML, and Web Services Support
> http://www.sosnoski.com
>
> Anne Thomas Manes wrote:
>
> >Dennis,
> >
> >This is a pretty antiquated view of document style. Document style is no
> >longer used just for XML messaging. Most SOAP implementations support
> >automatic marshalling of both RPC-style and document-style
> messages. As long
> >as you have a WSDL description of the message structure, there's
> no problem
> >building automatic serializers.
> >
> >The predominant consensus in the industry at this point is to use
> >document-style by default. Document style is much easier to validate,
> >transform, and manipulate. The primary reason to consider using
> rpc/encoded
> >is if you need to send multi-referencing object structures. SOAP encoding
> >does a really nice job marshalling these structures. It's much harded to
> >represent them using literal XML Schema. But if you're not using
> multi-refs,
> >it's a better practice to use document-style.
> >
> >Regards,
> >Anne
> >
> >
> >
> >>-----Original Message-----
> >>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> >>Sent: Thursday, November 21, 2002 1:25 PM
> >>To: axis-user@xml.apache.org
> >>Subject: Re: Document style web services
> >>
> >>
> >>Hi Matt,
> >>
> >>The whole point of document style is that your application gets passed
> >>the XML message payload as XML document fragments. See the "message"
> >>sample for an example of this. With a document style interface your
> >>class would look like:
> >>
> >>public class SomeXMLService {
> >> public Element[] someXMLMethod(Element[] elems) {
> >> ...
> >> }
> >>}
> >>
> >>If you want to convert the XML into objects you need to do it yourself,
> >>perhaps using a framework such as Castor (http://www.castor.org). I know
> >>there's been some integration of Castor with Axis, though I think this
> >>was for custom serialization with RPC style.
> >>
> >>This brings up an interesting point, though. Why not have a Java
> >>DataBindingProvider as a replacement for the MsgProvider? This should
> >>allow easy use of document style while converting seamlessly between XML
> >>and objects without the application needing any special code. I'm
> >>looking into some data binding code currently, perhaps I'll see if I can
> >>work in this direction.
> >>
> >> - Dennis
> >>
> >>Dennis M. Sosnoski
> >>Enterprise Java, XML, and Web Services Support
> >>http://www.sosnoski.com
> >>
> >>
> >
> >
>
Re: Document style web services
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Anne,
Does Axis support automatic marshalling of document-style messages? I
was under the impression it does not, which was why I suggested a
DataBindingProvider might be useful to add this support. I agree that
document-style is a better approach for the future, though I'd hardly
call it a "predominant consensus" at this point. AFAIK document style
interfaces are not as widely supported as RPC style, though, and I'm
surprised to see your statement that most SOAP implementations support
automatic marshalling for document style. Can you give me any figures
for this?
As for "no problem building automatic serializers" I have to disagree. A
Schema definition does not, in general, provide enough information to
directly map to Java data structures. If you use an approach where the
data structures are either pre-generated from the Schema or constrained
to obey a predefined mapping to and from the Schema you can get around
this, but that's hardly automatic.
I'm also puzzled by your statement that it's difficult handle
multi-referencing object structures using document style. Is there a
reason this can't be handled with ID/IDREF or key/keyref links?
Thanks,
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
http://www.sosnoski.com
Anne Thomas Manes wrote:
>Dennis,
>
>This is a pretty antiquated view of document style. Document style is no
>longer used just for XML messaging. Most SOAP implementations support
>automatic marshalling of both RPC-style and document-style messages. As long
>as you have a WSDL description of the message structure, there's no problem
>building automatic serializers.
>
>The predominant consensus in the industry at this point is to use
>document-style by default. Document style is much easier to validate,
>transform, and manipulate. The primary reason to consider using rpc/encoded
>is if you need to send multi-referencing object structures. SOAP encoding
>does a really nice job marshalling these structures. It's much harded to
>represent them using literal XML Schema. But if you're not using multi-refs,
>it's a better practice to use document-style.
>
>Regards,
>Anne
>
>
>
>>-----Original Message-----
>>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
>>Sent: Thursday, November 21, 2002 1:25 PM
>>To: axis-user@xml.apache.org
>>Subject: Re: Document style web services
>>
>>
>>Hi Matt,
>>
>>The whole point of document style is that your application gets passed
>>the XML message payload as XML document fragments. See the "message"
>>sample for an example of this. With a document style interface your
>>class would look like:
>>
>>public class SomeXMLService {
>> public Element[] someXMLMethod(Element[] elems) {
>> ...
>> }
>>}
>>
>>If you want to convert the XML into objects you need to do it yourself,
>>perhaps using a framework such as Castor (http://www.castor.org). I know
>>there's been some integration of Castor with Axis, though I think this
>>was for custom serialization with RPC style.
>>
>>This brings up an interesting point, though. Why not have a Java
>>DataBindingProvider as a replacement for the MsgProvider? This should
>>allow easy use of document style while converting seamlessly between XML
>>and objects without the application needing any special code. I'm
>>looking into some data binding code currently, perhaps I'll see if I can
>>work in this direction.
>>
>> - Dennis
>>
>>Dennis M. Sosnoski
>>Enterprise Java, XML, and Web Services Support
>>http://www.sosnoski.com
>>
>>
>
>
RE: Document style web services
Posted by Heitzso <he...@bellsouth.net>.
Just want to say thanks for a nice write up. I had been
wondering myself since DAIS-WG's OGSA implementation of
a data mounting web service is document based, though
a competing group named Spitfire is RPC based.
If this could make its way into a FAQ that would be nice
(if it isn't already in one).
On Fri, 2002-11-22 at 16:43, Anne Thomas Manes wrote:
> SOAP supports two different ways to structure messages. A SOAP message can
> be structured as an RPC or a document.
>
> The RPC style simulates an RPC invocation and response. An RPC input message
> specifies the name of the procedure to be invoked, and it contains a set of
> input parameters. An RPC output message contains the return value and any
> output parameters of the procedure. The format of the RPC input and output
> messages can be defined by literal XML schema definitions, or they can be
> structured using a data model called SOAP encoding. This SOAP encoding data
> model allows you to easily map complex object-oriented data structures
> (graphs) to XML. So for example, an RPC message looks something like this:
>
> <env:Body>
> <m:methodName xmlns:m="someURI">
> <m:param1>...</m:param1>
> <m:param2>...</m:param2>
> ...
> </m:methodName>
> </env:Body>
>
> Document style does not impose any particular structure to the message.
> There's no automatic convention for how to specify a method name or a list
> of parameters. The format of the document input and output messages are
> defined by XML schema definitions, which may be defined within the Web
> services WSDL document or within a separate schema. Formatting a SOAP
> message according to a specified schema is called literal encoding. Document
> style can be used for request/response messages or for one-way messages.
> It's up to the SOAP listener to figure out where to direct the message. In
> many cases the method name is specified in the SOAPAction HTTP header rather
> than in the SOAP message.
>
> >From a practical point of view, there's very little difference from RPC and
> document style. Your parameters in RPC style can be as complex as you like.
> For example, you can pass a purchase order as a document or as a parameter
> in a method called placeOrder. It's your choice:
>
> Document style:
> <env:Body>
> <m:purchaseOrder xmlns:m="someURI">
> ...
> </m:purchaseOrder>
> </env:Body>
>
> RPC style:
> <env:Body>
> <m:placeOrder xmlns:m="someURI">
> <m:purchaseOrder>
> ...
> </m:purchaseOrder>
> </m:placeOrder>
> </env:Body>
>
> The bigger difference is how you encode the message. In most circumstances,
> you use literal encoding with Document style and SOAP encoding with RPC
> style. Literal encoding means that the Body contents conform to a specific
> XML Schema. SOAP encoding uses a set of rules based on the XML Schema
> datatypes to encode the data, but the message doesn't conform to a
> particular schema. SOAP encoding is particularly useful is you're passing
> cyclic object graphs. For example, if you have an element which is
> referenced repeatedly within the object graph, when using SOAP encoding, you
> would specify the element once and then reference the element as needed.
> When using literal encoding, you would have to repeat this element each time
> it's referenced.
>
> The advantage of using document or RPC messages structured using a literal
> XML schema definition is that the messages can be validated using the schema
> and transformed using an XSLT stylesheet. RPC messages structured using SOAP
> encoding cannot be validated and transformed using standard XML tools. The
> advantage of using SOAP encoding is that it provides a simpler and more
> efficient method to represent and transfer object-oriented data in XML, but
> it limits flexibility.
>
> Anne
RE: Document style web services
Posted by Paul Faulkner <pa...@wcom.com>.
thank you. I really appreciate the detailed description.
thanks again
Paul Faulkner
Worldcom
paul.faulkner@wcom.com
IM: PF 2004
-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Friday, November 22, 2002 2:44 PM
To: axis-user@xml.apache.org
Subject: RE: Document style web services
SOAP supports two different ways to structure messages. A SOAP message can
be structured as an RPC or a document.
The RPC style simulates an RPC invocation and response. An RPC input message
specifies the name of the procedure to be invoked, and it contains a set of
input parameters. An RPC output message contains the return value and any
output parameters of the procedure. The format of the RPC input and output
messages can be defined by literal XML schema definitions, or they can be
structured using a data model called SOAP encoding. This SOAP encoding data
model allows you to easily map complex object-oriented data structures
(graphs) to XML. So for example, an RPC message looks something like this:
<env:Body>
<m:methodName xmlns:m="someURI">
<m:param1>...</m:param1>
<m:param2>...</m:param2>
...
</m:methodName>
</env:Body>
Document style does not impose any particular structure to the message.
There's no automatic convention for how to specify a method name or a list
of parameters. The format of the document input and output messages are
defined by XML schema definitions, which may be defined within the Web
services WSDL document or within a separate schema. Formatting a SOAP
message according to a specified schema is called literal encoding. Document
style can be used for request/response messages or for one-way messages.
It's up to the SOAP listener to figure out where to direct the message. In
many cases the method name is specified in the SOAPAction HTTP header rather
than in the SOAP message.
From a practical point of view, there's very little difference from RPC and
document style. Your parameters in RPC style can be as complex as you like.
For example, you can pass a purchase order as a document or as a parameter
in a method called placeOrder. It's your choice:
Document style:
<env:Body>
<m:purchaseOrder xmlns:m="someURI">
...
</m:purchaseOrder>
</env:Body>
RPC style:
<env:Body>
<m:placeOrder xmlns:m="someURI">
<m:purchaseOrder>
...
</m:purchaseOrder>
</m:placeOrder>
</env:Body>
The bigger difference is how you encode the message. In most circumstances,
you use literal encoding with Document style and SOAP encoding with RPC
style. Literal encoding means that the Body contents conform to a specific
XML Schema. SOAP encoding uses a set of rules based on the XML Schema
datatypes to encode the data, but the message doesn't conform to a
particular schema. SOAP encoding is particularly useful is you're passing
cyclic object graphs. For example, if you have an element which is
referenced repeatedly within the object graph, when using SOAP encoding, you
would specify the element once and then reference the element as needed.
When using literal encoding, you would have to repeat this element each time
it's referenced.
The advantage of using document or RPC messages structured using a literal
XML schema definition is that the messages can be validated using the schema
and transformed using an XSLT stylesheet. RPC messages structured using SOAP
encoding cannot be validated and transformed using standard XML tools. The
advantage of using SOAP encoding is that it provides a simpler and more
efficient method to represent and transfer object-oriented data in XML, but
it limits flexibility.
Anne
> -----Original Message-----
> From: Paul Faulkner [mailto:paul.faulkner@wcom.com]
> Sent: Friday, November 22, 2002 2:02 PM
> To: axis-user@xml.apache.org
> Subject: RE: Document style web services
>
>
> would you mind explaining what RPC-Style and Document-Style messages are.
> Sorry I'm very new to this technology.
>
> thanks,
>
> Paul Faulkner
>
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Thursday, November 21, 2002 12:41 PM
> To: axis-user@xml.apache.org
> Subject: RE: Document style web services
>
>
> Dennis,
>
> This is a pretty antiquated view of document style. Document style is no
> longer used just for XML messaging. Most SOAP implementations support
> automatic marshalling of both RPC-style and document-style
> messages. As long
> as you have a WSDL description of the message structure, there's
> no problem
> building automatic serializers.
>
> The predominant consensus in the industry at this point is to use
> document-style by default. Document style is much easier to validate,
> transform, and manipulate. The primary reason to consider using
> rpc/encoded
> is if you need to send multi-referencing object structures. SOAP encoding
> does a really nice job marshalling these structures. It's much harded to
> represent them using literal XML Schema. But if you're not using
> multi-refs,
> it's a better practice to use document-style.
>
> Regards,
> Anne
>
> > -----Original Message-----
> > From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> > Sent: Thursday, November 21, 2002 1:25 PM
> > To: axis-user@xml.apache.org
> > Subject: Re: Document style web services
> >
> >
> > Hi Matt,
> >
> > The whole point of document style is that your application gets passed
> > the XML message payload as XML document fragments. See the "message"
> > sample for an example of this. With a document style interface your
> > class would look like:
> >
> > public class SomeXMLService {
> > public Element[] someXMLMethod(Element[] elems) {
> > ...
> > }
> > }
> >
> > If you want to convert the XML into objects you need to do it yourself,
> > perhaps using a framework such as Castor (http://www.castor.org). I know
> > there's been some integration of Castor with Axis, though I think this
> > was for custom serialization with RPC style.
> >
> > This brings up an interesting point, though. Why not have a Java
> > DataBindingProvider as a replacement for the MsgProvider? This should
> > allow easy use of document style while converting seamlessly between XML
> > and objects without the application needing any special code. I'm
> > looking into some data binding code currently, perhaps I'll see if I can
> > work in this direction.
> >
> > - Dennis
> >
> > Dennis M. Sosnoski
> > Enterprise Java, XML, and Web Services Support
> > http://www.sosnoski.com
> >
> > Crawford, Matt wrote:
> >
> > >Hello,
> > >
> > >Has anyone had experience with document style web services
> similar to the
> > >one shown below? The users guide indicates that "Document
> services do not
> > >use any encoding (so in particular, you won't see multiref object
> > >serialization or SOAP-style arrays on the wire) but DO still do
> > XML<->Java
> > >databinding."
> > >
> > >I'm looking to leverage this databinding to serialize and
> deserialize xml
> > >documents in the body, but the samples/encoding (from what I can
> > tell) deals
> > >with rpc style, not document style.
> > >
> > >Thanks,
> > >Matt Crawford
> > >Enterprise Rent-A-Car
> > >
> > >
> > ><SOAP-ENV:Envelope
> > >xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> > >xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" >
> > ><SOAP-ENV:Body>
> > > <SomeXmlElement xmlns="http://www.somUri.org/someClassName"
> > >anAttribute="foo">
> > > <AnotherXmlElement value="X"/>
> > > <AThirdXmlElement value="three"/>
> > > </SomeXmlElement>
> > ></SOAP-ENV:Body>
> > ></SOAP-ENV:Envelope>
> > >
> > >Would somehow map to (with appropriate typeMapping entries)
> > >
> > >public class SomeXmlService() {
> > > public SomeXmlResponse method(SomeXmlElement arg0) {
> > > return new SomeXmlReponse();
> > > }
> > >}
> > >
> > >
> > >
> >
>
RE: Document style web services
Posted by Anne Thomas Manes <an...@manes.net>.
SOAP supports two different ways to structure messages. A SOAP message can
be structured as an RPC or a document.
The RPC style simulates an RPC invocation and response. An RPC input message
specifies the name of the procedure to be invoked, and it contains a set of
input parameters. An RPC output message contains the return value and any
output parameters of the procedure. The format of the RPC input and output
messages can be defined by literal XML schema definitions, or they can be
structured using a data model called SOAP encoding. This SOAP encoding data
model allows you to easily map complex object-oriented data structures
(graphs) to XML. So for example, an RPC message looks something like this:
<env:Body>
<m:methodName xmlns:m="someURI">
<m:param1>...</m:param1>
<m:param2>...</m:param2>
...
</m:methodName>
</env:Body>
Document style does not impose any particular structure to the message.
There's no automatic convention for how to specify a method name or a list
of parameters. The format of the document input and output messages are
defined by XML schema definitions, which may be defined within the Web
services WSDL document or within a separate schema. Formatting a SOAP
message according to a specified schema is called literal encoding. Document
style can be used for request/response messages or for one-way messages.
It's up to the SOAP listener to figure out where to direct the message. In
many cases the method name is specified in the SOAPAction HTTP header rather
than in the SOAP message.
>From a practical point of view, there's very little difference from RPC and
document style. Your parameters in RPC style can be as complex as you like.
For example, you can pass a purchase order as a document or as a parameter
in a method called placeOrder. It's your choice:
Document style:
<env:Body>
<m:purchaseOrder xmlns:m="someURI">
...
</m:purchaseOrder>
</env:Body>
RPC style:
<env:Body>
<m:placeOrder xmlns:m="someURI">
<m:purchaseOrder>
...
</m:purchaseOrder>
</m:placeOrder>
</env:Body>
The bigger difference is how you encode the message. In most circumstances,
you use literal encoding with Document style and SOAP encoding with RPC
style. Literal encoding means that the Body contents conform to a specific
XML Schema. SOAP encoding uses a set of rules based on the XML Schema
datatypes to encode the data, but the message doesn't conform to a
particular schema. SOAP encoding is particularly useful is you're passing
cyclic object graphs. For example, if you have an element which is
referenced repeatedly within the object graph, when using SOAP encoding, you
would specify the element once and then reference the element as needed.
When using literal encoding, you would have to repeat this element each time
it's referenced.
The advantage of using document or RPC messages structured using a literal
XML schema definition is that the messages can be validated using the schema
and transformed using an XSLT stylesheet. RPC messages structured using SOAP
encoding cannot be validated and transformed using standard XML tools. The
advantage of using SOAP encoding is that it provides a simpler and more
efficient method to represent and transfer object-oriented data in XML, but
it limits flexibility.
Anne
> -----Original Message-----
> From: Paul Faulkner [mailto:paul.faulkner@wcom.com]
> Sent: Friday, November 22, 2002 2:02 PM
> To: axis-user@xml.apache.org
> Subject: RE: Document style web services
>
>
> would you mind explaining what RPC-Style and Document-Style messages are.
> Sorry I'm very new to this technology.
>
> thanks,
>
> Paul Faulkner
>
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Thursday, November 21, 2002 12:41 PM
> To: axis-user@xml.apache.org
> Subject: RE: Document style web services
>
>
> Dennis,
>
> This is a pretty antiquated view of document style. Document style is no
> longer used just for XML messaging. Most SOAP implementations support
> automatic marshalling of both RPC-style and document-style
> messages. As long
> as you have a WSDL description of the message structure, there's
> no problem
> building automatic serializers.
>
> The predominant consensus in the industry at this point is to use
> document-style by default. Document style is much easier to validate,
> transform, and manipulate. The primary reason to consider using
> rpc/encoded
> is if you need to send multi-referencing object structures. SOAP encoding
> does a really nice job marshalling these structures. It's much harded to
> represent them using literal XML Schema. But if you're not using
> multi-refs,
> it's a better practice to use document-style.
>
> Regards,
> Anne
>
> > -----Original Message-----
> > From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> > Sent: Thursday, November 21, 2002 1:25 PM
> > To: axis-user@xml.apache.org
> > Subject: Re: Document style web services
> >
> >
> > Hi Matt,
> >
> > The whole point of document style is that your application gets passed
> > the XML message payload as XML document fragments. See the "message"
> > sample for an example of this. With a document style interface your
> > class would look like:
> >
> > public class SomeXMLService {
> > public Element[] someXMLMethod(Element[] elems) {
> > ...
> > }
> > }
> >
> > If you want to convert the XML into objects you need to do it yourself,
> > perhaps using a framework such as Castor (http://www.castor.org). I know
> > there's been some integration of Castor with Axis, though I think this
> > was for custom serialization with RPC style.
> >
> > This brings up an interesting point, though. Why not have a Java
> > DataBindingProvider as a replacement for the MsgProvider? This should
> > allow easy use of document style while converting seamlessly between XML
> > and objects without the application needing any special code. I'm
> > looking into some data binding code currently, perhaps I'll see if I can
> > work in this direction.
> >
> > - Dennis
> >
> > Dennis M. Sosnoski
> > Enterprise Java, XML, and Web Services Support
> > http://www.sosnoski.com
> >
> > Crawford, Matt wrote:
> >
> > >Hello,
> > >
> > >Has anyone had experience with document style web services
> similar to the
> > >one shown below? The users guide indicates that "Document
> services do not
> > >use any encoding (so in particular, you won't see multiref object
> > >serialization or SOAP-style arrays on the wire) but DO still do
> > XML<->Java
> > >databinding."
> > >
> > >I'm looking to leverage this databinding to serialize and
> deserialize xml
> > >documents in the body, but the samples/encoding (from what I can
> > tell) deals
> > >with rpc style, not document style.
> > >
> > >Thanks,
> > >Matt Crawford
> > >Enterprise Rent-A-Car
> > >
> > >
> > ><SOAP-ENV:Envelope
> > >xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> > >xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" >
> > ><SOAP-ENV:Body>
> > > <SomeXmlElement xmlns="http://www.somUri.org/someClassName"
> > >anAttribute="foo">
> > > <AnotherXmlElement value="X"/>
> > > <AThirdXmlElement value="three"/>
> > > </SomeXmlElement>
> > ></SOAP-ENV:Body>
> > ></SOAP-ENV:Envelope>
> > >
> > >Would somehow map to (with appropriate typeMapping entries)
> > >
> > >public class SomeXmlService() {
> > > public SomeXmlResponse method(SomeXmlElement arg0) {
> > > return new SomeXmlReponse();
> > > }
> > >}
> > >
> > >
> > >
> >
>
RE: Document style web services
Posted by Paul Faulkner <pa...@wcom.com>.
would you mind explaining what RPC-Style and Document-Style messages are.
Sorry I'm very new to this technology.
thanks,
Paul Faulkner
-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Thursday, November 21, 2002 12:41 PM
To: axis-user@xml.apache.org
Subject: RE: Document style web services
Dennis,
This is a pretty antiquated view of document style. Document style is no
longer used just for XML messaging. Most SOAP implementations support
automatic marshalling of both RPC-style and document-style messages. As long
as you have a WSDL description of the message structure, there's no problem
building automatic serializers.
The predominant consensus in the industry at this point is to use
document-style by default. Document style is much easier to validate,
transform, and manipulate. The primary reason to consider using rpc/encoded
is if you need to send multi-referencing object structures. SOAP encoding
does a really nice job marshalling these structures. It's much harded to
represent them using literal XML Schema. But if you're not using multi-refs,
it's a better practice to use document-style.
Regards,
Anne
> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Thursday, November 21, 2002 1:25 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
>
> Hi Matt,
>
> The whole point of document style is that your application gets passed
> the XML message payload as XML document fragments. See the "message"
> sample for an example of this. With a document style interface your
> class would look like:
>
> public class SomeXMLService {
> public Element[] someXMLMethod(Element[] elems) {
> ...
> }
> }
>
> If you want to convert the XML into objects you need to do it yourself,
> perhaps using a framework such as Castor (http://www.castor.org). I know
> there's been some integration of Castor with Axis, though I think this
> was for custom serialization with RPC style.
>
> This brings up an interesting point, though. Why not have a Java
> DataBindingProvider as a replacement for the MsgProvider? This should
> allow easy use of document style while converting seamlessly between XML
> and objects without the application needing any special code. I'm
> looking into some data binding code currently, perhaps I'll see if I can
> work in this direction.
>
> - Dennis
>
> Dennis M. Sosnoski
> Enterprise Java, XML, and Web Services Support
> http://www.sosnoski.com
>
> Crawford, Matt wrote:
>
> >Hello,
> >
> >Has anyone had experience with document style web services similar to the
> >one shown below? The users guide indicates that "Document services do not
> >use any encoding (so in particular, you won't see multiref object
> >serialization or SOAP-style arrays on the wire) but DO still do
> XML<->Java
> >databinding."
> >
> >I'm looking to leverage this databinding to serialize and deserialize xml
> >documents in the body, but the samples/encoding (from what I can
> tell) deals
> >with rpc style, not document style.
> >
> >Thanks,
> >Matt Crawford
> >Enterprise Rent-A-Car
> >
> >
> ><SOAP-ENV:Envelope
> >xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> >xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" >
> ><SOAP-ENV:Body>
> > <SomeXmlElement xmlns="http://www.somUri.org/someClassName"
> >anAttribute="foo">
> > <AnotherXmlElement value="X"/>
> > <AThirdXmlElement value="three"/>
> > </SomeXmlElement>
> ></SOAP-ENV:Body>
> ></SOAP-ENV:Envelope>
> >
> >Would somehow map to (with appropriate typeMapping entries)
> >
> >public class SomeXmlService() {
> > public SomeXmlResponse method(SomeXmlElement arg0) {
> > return new SomeXmlReponse();
> > }
> >}
> >
> >
> >
>
RE: Document style web services
Posted by Anne Thomas Manes <an...@manes.net>.
Dennis,
This is a pretty antiquated view of document style. Document style is no
longer used just for XML messaging. Most SOAP implementations support
automatic marshalling of both RPC-style and document-style messages. As long
as you have a WSDL description of the message structure, there's no problem
building automatic serializers.
The predominant consensus in the industry at this point is to use
document-style by default. Document style is much easier to validate,
transform, and manipulate. The primary reason to consider using rpc/encoded
is if you need to send multi-referencing object structures. SOAP encoding
does a really nice job marshalling these structures. It's much harded to
represent them using literal XML Schema. But if you're not using multi-refs,
it's a better practice to use document-style.
Regards,
Anne
> -----Original Message-----
> From: Dennis Sosnoski [mailto:dms@sosnoski.com]
> Sent: Thursday, November 21, 2002 1:25 PM
> To: axis-user@xml.apache.org
> Subject: Re: Document style web services
>
>
> Hi Matt,
>
> The whole point of document style is that your application gets passed
> the XML message payload as XML document fragments. See the "message"
> sample for an example of this. With a document style interface your
> class would look like:
>
> public class SomeXMLService {
> public Element[] someXMLMethod(Element[] elems) {
> ...
> }
> }
>
> If you want to convert the XML into objects you need to do it yourself,
> perhaps using a framework such as Castor (http://www.castor.org). I know
> there's been some integration of Castor with Axis, though I think this
> was for custom serialization with RPC style.
>
> This brings up an interesting point, though. Why not have a Java
> DataBindingProvider as a replacement for the MsgProvider? This should
> allow easy use of document style while converting seamlessly between XML
> and objects without the application needing any special code. I'm
> looking into some data binding code currently, perhaps I'll see if I can
> work in this direction.
>
> - Dennis
>
> Dennis M. Sosnoski
> Enterprise Java, XML, and Web Services Support
> http://www.sosnoski.com
>
> Crawford, Matt wrote:
>
> >Hello,
> >
> >Has anyone had experience with document style web services similar to the
> >one shown below? The users guide indicates that "Document services do not
> >use any encoding (so in particular, you won't see multiref object
> >serialization or SOAP-style arrays on the wire) but DO still do
> XML<->Java
> >databinding."
> >
> >I'm looking to leverage this databinding to serialize and deserialize xml
> >documents in the body, but the samples/encoding (from what I can
> tell) deals
> >with rpc style, not document style.
> >
> >Thanks,
> >Matt Crawford
> >Enterprise Rent-A-Car
> >
> >
> ><SOAP-ENV:Envelope
> >xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> >xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" >
> ><SOAP-ENV:Body>
> > <SomeXmlElement xmlns="http://www.somUri.org/someClassName"
> >anAttribute="foo">
> > <AnotherXmlElement value="X"/>
> > <AThirdXmlElement value="three"/>
> > </SomeXmlElement>
> ></SOAP-ENV:Body>
> ></SOAP-ENV:Envelope>
> >
> >Would somehow map to (with appropriate typeMapping entries)
> >
> >public class SomeXmlService() {
> > public SomeXmlResponse method(SomeXmlElement arg0) {
> > return new SomeXmlReponse();
> > }
> >}
> >
> >
> >
>
Re: Document style web services
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Matt,
The whole point of document style is that your application gets passed
the XML message payload as XML document fragments. See the "message"
sample for an example of this. With a document style interface your
class would look like:
public class SomeXMLService {
public Element[] someXMLMethod(Element[] elems) {
...
}
}
If you want to convert the XML into objects you need to do it yourself,
perhaps using a framework such as Castor (http://www.castor.org). I know
there's been some integration of Castor with Axis, though I think this
was for custom serialization with RPC style.
This brings up an interesting point, though. Why not have a Java
DataBindingProvider as a replacement for the MsgProvider? This should
allow easy use of document style while converting seamlessly between XML
and objects without the application needing any special code. I'm
looking into some data binding code currently, perhaps I'll see if I can
work in this direction.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support
http://www.sosnoski.com
Crawford, Matt wrote:
>Hello,
>
>Has anyone had experience with document style web services similar to the
>one shown below? The users guide indicates that "Document services do not
>use any encoding (so in particular, you won't see multiref object
>serialization or SOAP-style arrays on the wire) but DO still do XML<->Java
>databinding."
>
>I'm looking to leverage this databinding to serialize and deserialize xml
>documents in the body, but the samples/encoding (from what I can tell) deals
>with rpc style, not document style.
>
>Thanks,
>Matt Crawford
>Enterprise Rent-A-Car
>
>
><SOAP-ENV:Envelope
>xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" >
><SOAP-ENV:Body>
> <SomeXmlElement xmlns="http://www.somUri.org/someClassName"
>anAttribute="foo">
> <AnotherXmlElement value="X"/>
> <AThirdXmlElement value="three"/>
> </SomeXmlElement>
></SOAP-ENV:Body>
></SOAP-ENV:Envelope>
>
>Would somehow map to (with appropriate typeMapping entries)
>
>public class SomeXmlService() {
> public SomeXmlResponse method(SomeXmlElement arg0) {
> return new SomeXmlReponse();
> }
>}
>
>
>