ws-wsif-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques-Olivier Goussard" <>
Subject RE: [Axis2] mapping XML/XSD <-> Java [Re: Complex types: do the reverse ?
Date Fri, 06 May 2005 17:35:35 GMT
Thanks Alek, I'll take a look to all of this. If you may, 
this seems however overkill for what most users are asking for
it seems, as most are happy manipulating XML. It seems leaving
XML to Java binding (i.e. XmlBean) in the user hands would
be enough. 
> what if there is no Java Beans - you have XMl Schema with 
> types/elements 
> that you did not see before?
Not sure I follow here. I assumed the XSD in the java-binding case is
based upon introspection (because this is how I build the WSDL
from any class), so if every XML fragment used
as input is a valid XSD type instance, you should not get
into this problem (?). Of course, this implies you do not
use interfaces in the service methods declarations. Or you
need metadata on the service to map those to real classes - 
but not stored in the WSDL then. 

> -----Original Message-----
> From: Aleksander Slominski []
> Sent: Friday, May 06, 2005 11:00 AM
> To:
> Cc:; ''
> Subject: [Axis2] mapping XML/XSD <-> Java [Re: Complex types: do the
> reverse ?
> 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:
> 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)
> and how i do "server-side" WSIF with 
> XService/XmlBeansBasedService/HttpBasedServices/XHandler
> (keep in mind it is experimental API!!!!) in 

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, 



The best way to predict the future is to invent it - Alan Kay


View raw message