Hi Oliver, re: serialization
We do serialization of "basic" types (primitives, strings, URI/URL, QName, EPR, arrays) in muse-core, and leave serialization of complex types to the user's preferred data binding or serialization framework. I actually prefer xstream, which isn't a data binding framework (it doesn't do XSD -> Java) - it simply provides XML representations of Java objects (and vice versa). The reason I like it is that it doesn't require any artifacts, files, boilerplate, or generated code - it's a simple fromXML/toXML API. Whether you need a data binding framework or a serialization utility like XStream depends largely on your development style. Web services purists will certainly say "WSDL first" and use data binding tools to create Java classes for their schema types; however, I imagine there are many cases (manageability interfaces is one) where many of the existing message parameter/return types are already defined in Java. In the case of existing Java APIs, you can either use a DB tool to create Java->XSD/XML mappings or use something like XStream to generate the proper XML. I guess the point here is that for simple types, it should be possible to use the serializers in muse-core without any problems, and for complex types, the Serializer interface does not preclude the use of any data binding or serialization API to do the Java->XML conversions. re: SOAP engines This is mainly an exercise in copying the proper deployment artifacts for Axis2, OSGi, etc.; the Muse code was designed to be independent of the underlying SOAP engine, so the programming model (and user code) doesn't change when you move from one to another. The only difference is the way the code is packaged (WAR vs bundle) and some of the SOAP engine XML artifacts, which are usually static for Muse. Hopefully generating for different engines can be confined to a step towards the end that selects the proper packaging of a set of common files. Dan Dan Jemiolo IBM Corporation Research Triangle Park, NC +++ I'm an engineer. I make slides that people can't read. Sometimes I eat donuts. +++ "Oliver Waeldrich" <[EMAIL PROTECTED]> wrote on 07/03/2006 11:39:12 AM: > Hi, > > after dealing with the legal issues (I have sent in the contributors agreement > today) I started to get our code to get our code to run with = the new code > base. Since the code generation was originally based on Apache = WSRF there > are (of course) some problems to port it to the new code base. > > Andrew, since you would like to work on the code generation too, I think = we > should start to discuss whether we want to port the code from Apache = WSRF to > muse or we just re-develope the parts from WSRF (I would tend to the = first, > so we have to identify the needed parts and perhaps put it into a new module). > What is your opinion to this? Do you think it makes sense to = put our Apache > WSRF extensions to the jira? Furthermore we have to think = about a concept to > deal with different SOAP-Engines (at least Axis 1/2 - and = what about OSGi?). > Another point is that we have to decide how we want to = deal with different > xml schema compilers (if we want to support more than one :o). In my opinion > we should at least support XmlBeans, since they are = quite good in compiling > complex schemas. > > Dan, I saw that you are also dealing with the (de-)serialization in the = core > module. I don't know whether this is good or not, I had a lot of = problems > with Axis using their own (default) de-/serializiation and code = generation > mechanisms when dealing with wsdl-files that include complex = xml-schemas. I > think there will be some dependencies to the code generation parts that = we > have to clarify.=20 > > Regards, > Oliver > > -- > > > Echte DSL-Flatrate dauerhaft für 0,- Euro*! > "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
