Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 93708 invoked from network); 6 May 2005 19:40:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 May 2005 19:40:50 -0000 Received: (qmail 39553 invoked by uid 500); 6 May 2005 19:42:23 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 39470 invoked by uid 500); 6 May 2005 19:42:21 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 39417 invoked by uid 99); 6 May 2005 19:42:20 -0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=HTML_20_30,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from whale.cs.indiana.edu (HELO whale.cs.indiana.edu) (129.79.246.27) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 06 May 2005 12:42:20 -0700 Received: from [127.0.0.1] (rainier.extreme.indiana.edu [129.79.246.105]) by whale.cs.indiana.edu (8.12.11/8.12.11/IUCS_2.65) with ESMTP id j46JdRDs017509; Fri, 6 May 2005 14:39:28 -0500 (EST) Message-ID: <427BC7E5.2060905@cs.indiana.edu> Date: Fri, 06 May 2005 14:39:17 -0500 From: Aleksander Slominski User-Agent: Mozilla Thunderbird 1.0+ (Windows/20050422) MIME-Version: 1.0 To: wsif-dev@ws.apache.org CC: "'axis-dev@ws.apache.org'" Subject: Re: [Axis2] mapping XML/XSD <-> Java [Re: Complex types: do the reverse ? References: <7DE7C4EF3B7C8B4B82955191378290D80131BE78@mtb1exch01.nuance.com> In-Reply-To: <7DE7C4EF3B7C8B4B82955191378290D80131BE78@mtb1exch01.nuance.com> Content-Type: multipart/alternative; boundary="------------050802020902030207010103" X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --------------050802020902030207010103 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jacques-Olivier Goussard wrote: >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. > there is nothing preventing you from reading XML directly (to DOM etc) without XmlBeans (and later using XmlBeans or other databinding), compare client with XmlBeans mapping conveniently available (2) and the same client that uses WSIF API to construct XML directly (1): (1) http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/sample_decoder/src/decoder/client/LightweightDecoderClient.java LightweightDecoderStub stub = (LightweightDecoderStub) WSIFRuntime.newClient(wsdlLoc) //.addHandler(new PasswordInvokerHandler("password-invoker")) .generateDynamicStub(LightweightDecoderStub.class); XmlElement in = builder.newFragment(NS, "runDecoder"); in.addElement("Topic").addChild(args[1]); in.addElement("InputFile").addChild(args[2]); in.addElement("OutputDirectory").addChild(args[3]); XmlElement el = builder.parseFragmentFromReader( new StringReader("Arg1Arg2")); in.addElement(el); String s = Util.safeXmlToString((XmlContainer)in); System.out.println("sending message =\n"+s); XmlElement result = stub.run(in); System.out.println("result=\n"+Util.safeXmlToString(result)); (2) http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/sample_decoder/src/decoder/client/DecoderClient.java WSIFClient wcl = XmlBeansWSIFRuntime.newClient(wsdlLoc); DecoderPortType stub = (DecoderPortType)wcl.generateDynamicStub(DecoderPortType.class); DecoderRunInputParamsDocument inputMsg = DecoderRunInputParamsDocument.Factory.newInstance(); DecoderRunInputParamsType params = inputMsg.addNewDecoderRunInputParams(); params.setTopic(args[1]); params.setCorrelationId(args[2]); params.setInputFile(args[3]); params.setOutputDirectory(args[4]); String[] arr = new String[]{"argA", "argB"}; params.addNewStringArr().setItemArray(arr); params.setNproc(77); //override default DecoderRunOutputParamsDocument outputMsg = stub.run(inputMsg); DecoderRunOutputParamsType result = outputMsg.getDecoderRunOutputParams(); System.out.println("outputUrl="+result.getOutputURL()); however it is difficult if you want to do XSD validation and databinding to WSDL that is known/discovered only *during* runtime - it seems to me simpler to have two groups of clients/services: those created from known (abstract) WSDL and those that need to deal with any WSDL. > It seems leaving >XML to Java binding (i.e. XmlBean) in the user hands would >be enough. > > it depends what you need to do. if you need to implement or access service described in (abstract) WSDL then it is convenient to generate java interfaces from WSDL:portType/interface and databinding code (XmlBeans) from XSD inside WSDL. then writing client and service implementation is very easy. for dynamic clients i do not see any real need to do actual Java<->XML databinding - such client deals with any WSDL/XSD so even if you do databinding then how users are supposed to use it? using Java reflection? wouldn't it be simpler (and less of leaky abstractions) to have XML Schema introspection and then use XML directly? >>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), > this is pretty strong assumption - do you assume all services you use are java based and have their WSDLs built by Java introspection? what if you have external services and/or services written in other languages (mapping Java Beans <-> XSD may be very difficult) thanks, alek >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. > > /jog > > >>-----Original Message----- >>From: Aleksander Slominski [mailto:aslom@cs.indiana.edu] >>Sent: Friday, May 06, 2005 11:00 AM >>To: wsif-user@ws.apache.org >>Cc: wsif-dev@ws.apache.org; 'axis-dev@ws.apache.org' >>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: >> >>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 objectImplementingPortTypeDescribedInWsdl) > >HTH, > >alek > > > -- The best way to predict the future is to invent it - Alan Kay --------------050802020902030207010103 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Jacques-Olivier Goussard wrote:
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.
there is nothing preventing you from reading XML directly (to DOM etc) without XmlBeans
(and later using XmlBeans or other databinding), compare client with XmlBeans mapping
conveniently available (2) and the same client that uses WSIF API to construct XML directly (1):

(1) http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/sample_decoder/src/decoder/client/LightweightDecoderClient.java

        LightweightDecoderStub stub = (LightweightDecoderStub) WSIFRuntime.newClient(wsdlLoc)
            //.addHandler(new PasswordInvokerHandler("password-invoker"))
            .generateDynamicStub(LightweightDecoderStub.class);
        
        XmlElement in = builder.newFragment(NS, "runDecoder");
        in.addElement("Topic").addChild(args[1]);
        in.addElement("InputFile").addChild(args[2]);
        in.addElement("OutputDirectory").addChild(args[3]);
        XmlElement el = builder.parseFragmentFromReader(
            new StringReader("<StringArr><item>Arg1</item><item>Arg2</item></StringArr>"));
        in.addElement(el);
        String s = Util.safeXmlToString((XmlContainer)in);
        System.out.println("sending message =\n"+s);

        XmlElement result = stub.run(in);
        System.out.println("result=\n"+Util.safeXmlToString(result));
 
(2) http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/sample_decoder/src/decoder/client/DecoderClient.java

        WSIFClient wcl = XmlBeansWSIFRuntime.newClient(wsdlLoc);
        DecoderPortType stub = (DecoderPortType)wcl.generateDynamicStub(DecoderPortType.class);
        DecoderRunInputParamsDocument inputMsg = DecoderRunInputParamsDocument.Factory.newInstance();
        DecoderRunInputParamsType params = inputMsg.addNewDecoderRunInputParams();
        params.setTopic(args[1]);
        params.setCorrelationId(args[2]);
        params.setInputFile(args[3]);
        params.setOutputDirectory(args[4]);
        String[] arr = new String[]{"argA", "argB"};
        params.addNewStringArr().setItemArray(arr);
        params.setNproc(77); //override default
        DecoderRunOutputParamsDocument outputMsg = stub.run(inputMsg);
        DecoderRunOutputParamsType result = outputMsg.getDecoderRunOutputParams();
        System.out.println("outputUrl="+result.getOutputURL());

however it is difficult if you want to do XSD validation and databinding to WSDL
that is known/discovered only *during* runtime
- it seems to me simpler to have two groups of clients/services: those created from
known (abstract) WSDL  and those that need to deal with any WSDL.
 It seems leaving
XML to Java binding (i.e. XmlBean) in the user hands would
be enough. 
  
it depends what you need to do. if you need to implement or access service
described in (abstract) WSDL then it is convenient to generate java interfaces from
WSDL:portType/interface and databinding code (XmlBeans) from XSD inside WSDL.
then writing client and service implementation is very easy.

for dynamic clients i do not see any real need to do actual Java<->XML databinding
- such client deals with any WSDL/XSD so even if you do databinding then
how users are supposed to use it? using Java reflection? wouldn't it be simpler
(and less of leaky abstractions) to have XML Schema introspection and then
use XML directly?

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), 
this is pretty strong assumption - do you assume all services you use are java based and
have their WSDLs built by Java introspection?

what if you have external services and/or
services written in other languages (mapping Java Beans <-> XSD may be very difficult)

thanks,

alek
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. 

	/jog
  
-----Original Message-----
From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
Sent: Friday, May 06, 2005 11:00 AM
To: wsif-user@ws.apache.org
Cc: wsif-dev@ws.apache.org; 'axis-dev@ws.apache.org'
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:

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
--------------050802020902030207010103--