You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Eran Chinthaka <ch...@opensource.lk> on 2005/08/19 07:37:04 UTC

Re: [VOTE] Dennis Sosnoski for Axis2 committer

+1. (Can I add more :)).

Dennis, it's nice to have someone like you with us working for Axis2.
Welcome aboard. 

-- Chinthaka

> -----Original Message-----
> From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
> Sent: Friday, August 19, 2005 10:25 AM
> To: axis-dev@ws.apache.org
> Subject: [Axis2] Re: [VOTE] Dennis Sosnoski for Axis2 committer (Re:
> [Axis2] Better Java-XML mapping)
> 
> +1
> 
> if Dennis is interested then it would be great addition to Axis2 team!
> 
> alek
> 
> chathura@opensource.lk wrote:
> 
> >here is my +1
> >Chathura
> >
> >
> >
> >>+1,
> >>welcome Dennis :-)
> >>
> >>- Ruchith
> >>
> >>On 8/19/05, Davanum Srinivas <da...@gmail.com> wrote:
> >>
> >>
> >>>Team,
> >>>Dennis has been a long time contributor to Axis...Let's welcome him
> >>>with open arms to Axis2.
> >>>
> >>>Here's my +1 to Dennis for Axis2 committer.
> >>>
> >>>thanks,
> >>>dims
> >>>
> >>>
> >>>On 8/18/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >>>
> >>>
> >>>>I've been having some off-list email exchanges on the issues of better
> >>>>tools for going between Java and XML. This is relevant to both
> >>>>start-from-Java approaches to web services, and handling schema
> >>>>versioning. Since these issues are important for Axis2 I'll get this
> >>>>thread going here, assuming nobody objects to us using the Axis2 list
> >>>>for this purpose. I'm copying the jibx-devs list on my own emails on
> >>>>this topic just so that people monitoring that list are also aware of
> >>>>the discussion.
> >>>>
> >>>>While we have a number of tools for generating Java object models to
> >>>>(more or less) match a schema, most of these tools either cannot work
> >>>>with pre-existing Java classes or can only work with existing classes
> >>>>using their own built-in correspondences. This limitation makes it
> >>>>
> >>>>
> >>>very
> >>>
> >>>
> >>>>difficult for users to take a start-from-Java approach to developing
> >>>>
> >>>>
> >>>web
> >>>
> >>>
> >>>>services, since the users then have little or no control over the
> >>>>schemas used by the web service (as seen with the JAX-RPC 1.0-style
> >>>>doc/lit mapping). It also makes it very difficult for users to work
> >>>>
> >>>>
> >>>with
> >>>
> >>>
> >>>>evolving schemas, since their data model will need to be regenerated
> >>>>every time the schema changes. Because of this, users often end up
> >>>>writing a translation layer into their applications to take the data
> >>>>from the schema-centric model and convert it into structures actually
> >>>>used by their main application code.
> >>>>
> >>>>There are some libraries which provide more flexible conversions
> >>>>
> >>>>
> >>>between
> >>>
> >>>
> >>>>Java and XML, including Betwixt as well as my own JiBX framework. JAXB
> >>>>2.0 is also taking steps in this direction. The subject of the email
> >>>>exchanges has been the desirability of better GUI tools for working
> >>>>
> >>>>
> >>>with
> >>>
> >>>
> >>>>frameworks which support such flexible conversions.
> >>>>
> >>>>Betwixt seems to offer very good support for starting from basics and
> >>>>refining the mapping as you go. It basically offers defaults for
> >>>>everything, then lets you override the defaults. JiBX takes almost the
> >>>>opposite approach, requiring the user to specify everything (though
> >>>>there is a tool which will generate a default binding automatically,
> >>>>with a variety of overrides). I can certainly see the benefits to
> >>>>providing a tool that allows an interactive approach to building a
> >>>>
> >>>>
> >>>JiBX
> >>>
> >>>
> >>>>binding, basically starting with Betwixt-like defaults and allowing
> >>>>overrides at every step of the way down to a detailed JiBX binding.
> >>>>
> >>>>
> >>>The
> >>>
> >>>
> >>>>way I envision it this should show sample XML output (or the current
> >>>>schema, for those developers able to understand schemas) at every step
> >>>>of the way - when you change the binding, you immediately get the
> >>>>
> >>>>
> >>>change
> >>>
> >>>
> >>>>reflected in the schema/sample XML. Ideally you should even be able to
> >>>>go the other way - modify the schema, and have the binding
> >>>>
> >>>>
> >>>automatically
> >>>
> >>>
> >>>>reflect the change (or replace the schema with a new version, and have
> >>>>the binding adjust as best it can and then flag the mismatches). I've
> >>>>been adding hooks to JiBX for some time with the intent of moving it
> >>>>
> >>>>
> >>>in
> >>>
> >>>
> >>>>this direction.
> >>>>
> >>>>Much of the off-list discussion has revolved around the possibility of
> >>>>building a generic tool of this type, one able to work with different
> >>>>frameworks. On thinking it over, it seems to me that at least the
> >>>>general framework of the tool should be reusable - say the IDE
> >>>>integration and XML/schema display and manipulation. That would leave
> >>>>the need to write plugins for each binding framework to handle XML
> >>>>instance and schema generation from a binding and set of classes, and
> >>>>
> >>>>
> >>>to
> >>>
> >>>
> >>>>handle editing the actual binding definition (in whatever form that
> >>>>takes - an XML file for Betwixt and JiBX, annotations for JAXB, etc.).
> >>>>
> >>>>What do people think of this? Anyone want to jump right in and start
> >>>>putting this together? ;-)
> >>>>
> >>>>  - Dennis
> >>>>
> >>>>
> >>>>
> >>>--
> >>>Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
> >>>Platform
> >>>
> >>>
> >>>
> >>--
> >>Ruchith
> >>
> >>
> >>
> >>
> >
> >
> >
> 
> 
> --
> The best way to predict the future is to invent it - Alan Kay
>