You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsif-user@ws.apache.org by Jacques-Olivier Goussard <jo...@nuance.com> on 2005/05/06 15:52:43 UTC
Complex types: do the reverse ?
Hi all
With all the discussions around complex types support
in WSIF, I was wondering if really WSIF approach to it
was the one that it should take.
If really WSIF aims at representing all sorts of services
through the WSDL description, then it appears to me
that all types should be instances of the XSD types.
In this approach, a SOAP-based service would simply
take and return XML DOMs (or other representation) - thus
addressing the complex type issue in the most flexible
way. A java-based service would internaly populate the
needed beans from it's knowledge of the API and the XSD.
So no type mapping would be necessary in the java-binding
WSDL description.
And the client side would not need any knowledge of
the underlying implementation - currently a java-binding user
must know if the method takes a int[] or Integer[] for
example, breaking the design IMHO.
It's a much easier approach, because Java to XML binding
is a much simpler problem than XML to java - but that's a 90
degres change :)
/jog
[Axis2] mapping XML/XSD <-> Java [Re: Complex types: do the reverse
?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Jacques-Olivier Goussard wrote:
>Hi all
>With all the discussions around complex types support
>in WSIF, I was wondering if really WSIF approach to it
>was the one that it should take.
>If really WSIF aims at representing all sorts of services
>through the WSDL description, then it appears to me
>that all types should be instances of the XSD types.
>
>
i agree.
>In this approach, a SOAP-based service would simply
>take and return XML DOMs (or other representation)
>
i prefer to think about it as XML Infoset and DOM as one possible API.
> - thus
>addressing the complex type issue in the most flexible
>way. A java-based service would internaly populate the
>needed beans from it's knowledge of the API and the XSD.
>So no type mapping would be necessary in the java-binding
>WSDL description.
>
>
what if there is no Java Beans - you have XMl Schema with types/elements
that you did not see before?
>And the client side would not need any knowledge of
>the underlying implementation - currently a java-binding user
>must know if the method takes a int[] or Integer[] for
>example, breaking the design IMHO.
>It's a much easier approach, because Java to XML binding
>is a much simpler problem than XML to java - but that's a 90
>degres change :)
>
>
that is approach i taken in Super Dynamic Invoker but
with a little twist to make it more flexible in handling Java objects:
http://www.extreme.indiana.edu/~aslom/bnp/sdi/
i have a special XML infoset API (XB1/XPP3) that allows to store both
XML and any object including
Java Beans as part of XML tree (this API could provide also DOM view)
during serialization XML parts are straightforwardly converted
to XML 1.0 and Java objects goes through type mapping or provide their
own serialization
(if they implement XmlSerializable).
deserialization is opposite: you start with XML events and XML tree is
recreated then it is transformed
to replace parts of tree with Java objects (possibly in pipeline of
handlers).
currently for Java objects i do not use Java Beans instead i used
XmlBeans and that works pretty
well (though also right now transformation is very inefficient but is
*correct* so can be optimized later ...)
and here is how XmlBeans code work check in particular dynamic client
section (based on WSIF API)
http://www.extreme.indiana.edu/xgws/xsul/guide/#client.dii
and how i do "server-side" WSIF with
XService/XmlBeansBasedService/HttpBasedServices/XHandler
(keep in mind it is experimental API!!!!) in DecoderImpl.java
http://www.extreme.indiana.edu/xgws/xsul/guide/#host
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/sample_decoder/src/decoder/service/DecoderService.java
the API is designed to allow hosting any services as long as they are
described in WSDL
(ideally serive is defined as triple <SERVICE_NAME, wsdlLoc,
objectImplementingPortTypeDescribedInWsdl)
HTH,
alek
--
The best way to predict the future is to invent it - Alan Kay
[Axis2] mapping XML/XSD <-> Java [Re: Complex types: do the reverse
?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Jacques-Olivier Goussard wrote:
>Hi all
>With all the discussions around complex types support
>in WSIF, I was wondering if really WSIF approach to it
>was the one that it should take.
>If really WSIF aims at representing all sorts of services
>through the WSDL description, then it appears to me
>that all types should be instances of the XSD types.
>
>
i agree.
>In this approach, a SOAP-based service would simply
>take and return XML DOMs (or other representation)
>
i prefer to think about it as XML Infoset and DOM as one possible API.
> - thus
>addressing the complex type issue in the most flexible
>way. A java-based service would internaly populate the
>needed beans from it's knowledge of the API and the XSD.
>So no type mapping would be necessary in the java-binding
>WSDL description.
>
>
what if there is no Java Beans - you have XMl Schema with types/elements
that you did not see before?
>And the client side would not need any knowledge of
>the underlying implementation - currently a java-binding user
>must know if the method takes a int[] or Integer[] for
>example, breaking the design IMHO.
>It's a much easier approach, because Java to XML binding
>is a much simpler problem than XML to java - but that's a 90
>degres change :)
>
>
that is approach i taken in Super Dynamic Invoker but
with a little twist to make it more flexible in handling Java objects:
http://www.extreme.indiana.edu/~aslom/bnp/sdi/
i have a special XML infoset API (XB1/XPP3) that allows to store both
XML and any object including
Java Beans as part of XML tree (this API could provide also DOM view)
during serialization XML parts are straightforwardly converted
to XML 1.0 and Java objects goes through type mapping or provide their
own serialization
(if they implement XmlSerializable).
deserialization is opposite: you start with XML events and XML tree is
recreated then it is transformed
to replace parts of tree with Java objects (possibly in pipeline of
handlers).
currently for Java objects i do not use Java Beans instead i used
XmlBeans and that works pretty
well (though also right now transformation is very inefficient but is
*correct* so can be optimized later ...)
and here is how XmlBeans code work check in particular dynamic client
section (based on WSIF API)
http://www.extreme.indiana.edu/xgws/xsul/guide/#client.dii
and how i do "server-side" WSIF with
XService/XmlBeansBasedService/HttpBasedServices/XHandler
(keep in mind it is experimental API!!!!) in DecoderImpl.java
http://www.extreme.indiana.edu/xgws/xsul/guide/#host
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/sample_decoder/src/decoder/service/DecoderService.java
the API is designed to allow hosting any services as long as they are
described in WSDL
(ideally serive is defined as triple <SERVICE_NAME, wsdlLoc,
objectImplementingPortTypeDescribedInWsdl)
HTH,
alek
--
The best way to predict the future is to invent it - Alan Kay
[Axis2] mapping XML/XSD <-> Java [Re: Complex types: do the reverse
?
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Jacques-Olivier Goussard wrote:
>Hi all
>With all the discussions around complex types support
>in WSIF, I was wondering if really WSIF approach to it
>was the one that it should take.
>If really WSIF aims at representing all sorts of services
>through the WSDL description, then it appears to me
>that all types should be instances of the XSD types.
>
>
i agree.
>In this approach, a SOAP-based service would simply
>take and return XML DOMs (or other representation)
>
i prefer to think about it as XML Infoset and DOM as one possible API.
> - thus
>addressing the complex type issue in the most flexible
>way. A java-based service would internaly populate the
>needed beans from it's knowledge of the API and the XSD.
>So no type mapping would be necessary in the java-binding
>WSDL description.
>
>
what if there is no Java Beans - you have XMl Schema with types/elements
that you did not see before?
>And the client side would not need any knowledge of
>the underlying implementation - currently a java-binding user
>must know if the method takes a int[] or Integer[] for
>example, breaking the design IMHO.
>It's a much easier approach, because Java to XML binding
>is a much simpler problem than XML to java - but that's a 90
>degres change :)
>
>
that is approach i taken in Super Dynamic Invoker but
with a little twist to make it more flexible in handling Java objects:
http://www.extreme.indiana.edu/~aslom/bnp/sdi/
i have a special XML infoset API (XB1/XPP3) that allows to store both
XML and any object including
Java Beans as part of XML tree (this API could provide also DOM view)
during serialization XML parts are straightforwardly converted
to XML 1.0 and Java objects goes through type mapping or provide their
own serialization
(if they implement XmlSerializable).
deserialization is opposite: you start with XML events and XML tree is
recreated then it is transformed
to replace parts of tree with Java objects (possibly in pipeline of
handlers).
currently for Java objects i do not use Java Beans instead i used
XmlBeans and that works pretty
well (though also right now transformation is very inefficient but is
*correct* so can be optimized later ...)
and here is how XmlBeans code work check in particular dynamic client
section (based on WSIF API)
http://www.extreme.indiana.edu/xgws/xsul/guide/#client.dii
and how i do "server-side" WSIF with
XService/XmlBeansBasedService/HttpBasedServices/XHandler
(keep in mind it is experimental API!!!!) in DecoderImpl.java
http://www.extreme.indiana.edu/xgws/xsul/guide/#host
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/sample_decoder/src/decoder/service/DecoderService.java
the API is designed to allow hosting any services as long as they are
described in WSDL
(ideally serive is defined as triple <SERVICE_NAME, wsdlLoc,
objectImplementingPortTypeDescribedInWsdl)
HTH,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Complex types: do the reverse ?
Posted by Jeff Greif <jg...@alumni.princeton.edu>.
Yes, up to practical issues, this is a reasonable way to proceed. The
practical issues include:
1. Even if you are trafficking in DOMs, the WSIF provider (such as
Axis) may require you to specify trivial serializer/deserializer pairs.
2. This approach is best suited for doc/lit web services where all the
parameters are complex and the XML contains no special encoded forms.
In this case, what I described in previous emails boils down
approximately to trafficking in DOMs.
3. For rpc/encoded web services, particularly those that use
soap-encoded arrays and structures, the XML must be specially
interpreted/manipulated to produce the object structure that was
intended. (For example, sparse arrays may be encoded.)
4. When web service parameters are XSD simple types, such as integers,
dateTimes, etc., some serialization/deserialization must be provided to
convert between xml and java. Note also that derived simple types, such
as limited-range integers must also be recognized and processed
appropriately.
Jeff
Jacques-Olivier Goussard wrote:
>Hi all
>With all the discussions around complex types support
>in WSIF, I was wondering if really WSIF approach to it
>was the one that it should take.
>If really WSIF aims at representing all sorts of services
>through the WSDL description, then it appears to me
>that all types should be instances of the XSD types.
>In this approach, a SOAP-based service would simply
>take and return XML DOMs (or other representation) - thus
>addressing the complex type issue in the most flexible
>way. A java-based service would internaly populate the
>needed beans from it's knowledge of the API and the XSD.
>So no type mapping would be necessary in the java-binding
>WSDL description.
>And the client side would not need any knowledge of
>the underlying implementation - currently a java-binding user
>must know if the method takes a int[] or Integer[] for
>example, breaking the design IMHO.
>It's a much easier approach, because Java to XML binding
>is a much simpler problem than XML to java - but that's a 90
>degres change :)
> /jog
>
>
>
>