Discussions

News: J2XB v1.1 Released

  1. J2XB v1.1 Released (15 messages)

    J2XB v1.1 has been released, with Apachev Axis2 integration (http://j2xb.sourceforge.net). J2XB is a data binding framework taking the approach of Java to XML Schema and Java to WSDL. It allows a Java developer to write pure Java code from which both the data binding process is defined, the XML Schema / WSDL are generated (WSDL if using the Axis2 module). No code generation is involved and no writing of configuration files is required. Features of the J2XB Axis2 integration: * Java to WSDL style web service creation * Full control over the WSDL type part (XML Schema of the service) using the J2XB annotations - XML Constraints, Validations, Facets, Substitution Groups, etc. * Publish POJO objects with methods including any set of parameters as Web Service. Supported method parameters include: o Any J2XB mapped bean o Any primitive type or Value Objects supported by J2XB (Using J2XB property editors) o Any collection (Array, List or Set) of the above o Method exceptions Some of the features of J2XB: * Complete XML Schema generation from the Java code, including all Schema features. o XML validations (Facets, such as minLength and patterns). o Substitution Groups o Full control of the XML document structure, including flattening Java structures and introducing grouping XML elements. o Support all XML Simple types o XML Union Types o XML List Types * Bind any Java object to XML. o No requirement for inheriting from a common ancestor. o No requirement to implement any interface. o No requirement to have a default constructor. o No requirement to even have a public constructor, if a factory is provided o Full support for factories (static factories, instance factories) o Support for Java built in collection types (Set, List, Array) * Complete support for inheritance o Mapped as Substitution Groups o Complete and accurate XML Schema generation of the Substitution Groups o Mapping of generic atomic properties (of type Object and Number) to XML Unions. * Completely decoupled from Xml Parsers. Support for two parsers are available (Apache Axiom and Apache XmlBeans). o We have plans to add a 3rd parser - based on SAX for optimal performance.

    Threaded Messages (15)

  2. Maybe I'm missing something here, but why would I use this instead of JAXB? Thanks, Dan
  3. Maybe I'm missing something here, but why would I use this instead of JAXB? Thanks,
    Dan
    JAXB is a great data binding framework. In fact, it is faster then other frameworks such as Apache XmlBeans and Apache Axiom. However, JAXB is built for XML Schema to Java generation (or WSDL to Java, contract first style). It does not support annotating existing Java classes and producing XML Schema with things like Facets (or constraints). In addition, some features of JAXB require (for instance substitution groups) the use of specific JAXB classes that are unlikely to be used directly in hand-written Java code. J2XB on the other hand takes the Java to XML Schema (or code first style) to the extreme - write any Java code with no constraints, and J2XB will allows you to expose it as any XML structure you like, including things like substitution groups and Facets, only by annotating Java code. In some way, JAXB and J2XB complement each other - JAXB is the best Schema (or WSDL) to Java solution, where J2XB is the best Java to Schema (or WSDL) solution.
  4. Maybe I'm missing something here, but why would I use this instead of JAXB? Thanks,
    Dan


    JAXB is a great data binding framework. In fact, it is faster then other frameworks such as Apache XmlBeans and Apache Axiom.
    AFAIK, JiBX is the fastest popular XML->Java binding tool. It's much faster than JAXB according to all of the benchmarks I've found. It allows for very customized binding to existing Java objects. I use it to bind the same XML to different objects in different contexts.
  5. However, JAXB is built for XML Schema to Java generation (or WSDL to Java, contract first style). It does not support annotating existing Java classes and producing XML Schema with things like Facets (or constraints).
    Actually, JAXB does supports annotating existing Java classes and producing XML Schema. It certainly lacks support for some XML Schema constructs, but it is not limited to contract first style.
  6. Actually, JAXB does supports annotating existing Java classes and producing XML Schema. It certainly lacks support for some XML Schema constructs, but it is not limited to contract first style.
    As I have stated above, JAXB does support XML Schema generation form annotated Java classes. However, JAXB is limited in three important ways - 1. Some XML Schema features are not supported by JAXB, like constraints (Facets). J2XB supports most XML Schema features (all except key and keyRef). 2. JAXB always assumes a 1:1 correspondence between a Java Class and an XML element. J2XB allows to map a single class to a tree of XML elements which includes "logical grouping" XML elements. It also supports flattening trees of Java classes to a single XML element (with the restriction that a collection of beans cannot flattened). 3. Some of the JAXB features require writing special Java code using special JAXB classes (for instance, substitution groups). J2XB has no similar issue - you only write pure Java code and J2XB annotations.
  7. In some way, JAXB and J2XB complement each other - JAXB is the best Schema (or WSDL) to Java solution, where J2XB is the best Java to Schema (or WSDL) solution.
    The above is a rather bold statement considering there are solutions like MOXy also available. MOXy is the object-to-XML component of EclipseLink (Oracle TopLink has been open sourced as EclipseLink). We have been demonstrating the features you mentioned plus others using TopLink/EclipseLink for the past few years (including JavaOne 2006). EclipseLink MOXy even includes a JAXB implementation that allows meet-in-the-middle mapping. In this way users only need to learn MOXy specific concepts when they need to extend JAXB. By extending JAXB we ensure the ability to work with JAX-WS. In addition to JAXB we also offer an SDO implementation. Both implementations are thin layers on top of EclipseLink MOXy, and can leverage all of MOXy's meet-in-the-middle mapping support. -Blaise Doughan Team Lead, EclipseLink MOXy
  8. From you long response I had expected to find another Java XML binding framework which I did not know about (this MOXy). However, when I have looked at MOXy at the eclipse website, all I could find was a thin layer on top of JAXB. it appears that MOXy IS NOTHING BUT ANOTHER IMPLEMENTATION OF JAXB (OR IS IT A LAYER OVER THE REFERENCE IMPLEMENTATION)? see at: http://wiki.eclipse.org/Category:XML and http://wiki.eclipse.org/EclipseLink/UserGuide/Developing_XML_Projects_%28ELUG%29 Given that what you are doing is just JAXB, you inherit all the advantages and disadvantages of JAXB. You claim to be doing all that J2XB does - please show references. Some examples are: 1. XML Schema generation with Facets / constraints 2. Support for mapped classes without default constructors 3. XML Schema generation with substitution groups, without requiring use of specific JAXB classes (only with annotations). 4. Flattening Java object tree into one XML element with a set of child value elements (or attributes) Shell I continue with additional things that JAXB does not support?
  9. However, when I have looked at MOXy at the eclipse website, all I could find was a thin layer on top of JAXB.

    it appears that MOXy IS NOTHING BUT ANOTHER IMPLEMENTATION OF JAXB (OR IS IT A LAYER OVER THE REFERENCE IMPLEMENTATION
    MOXy is a full object to XML binding solution complete with JAXB and SDO implementations (I represent Oracle on both these expert groups). We are not based on the reference implementation, but do share many common components with object-relational EclipseLink/TopLink, a very respected ORM tool. MOXy has the same Instantiation Policies as object-relational EclipseLink/TopLink allowing you to use constructors or factories. Substitution groups are handled through our XML Choice Mapping: http://wiki.eclipse.org/Introduction_to_XML_Mappings_%28ELUG%29#XML_Choice_Object_Mapping Flattening Java object tree into one XML element can also be done, we call it mapping to the parent record: http://wiki.eclipse.org/Introduction_to_XML_Mappings_%28ELUG%29#Mapping_into_the_Parent_Record We do not generate XML schemas with Facets/Constraints, but we have also not seen this as a customer requirement. Some other things we offer (that customers have asked for): - XPath based mappings to break the 1-to-1 relationship between XML elements and objects. - A user interface to graphically create the mappings (see the link below for an example) http://www.oracle.com/technology/products/ias/toplink/technical/tips/ox/index.htm (TopLink has been open sourced as EclipseLink) - Support for binary attachments, necessary to serve as a web service binding layer. - Complete parser independence, only requires a JAXP compliant parser, allowing MOXy to work in any application server environment. - A persistence level component when using data stores that communicate via XML messages. - Events and converters at both the object and XML level. - MOXy is also available as an OSGi bundle. - Document preservation, this feature is used to implement the Binder concept in JAXB allowing the user to work against either the objects or DOM and then apply the changes to the other. We have added extra options to control how this binding takes place. As I mentioned before, we offer a JAXB implementation as part of our complete object-to-XML mapping layer. When users are confined by a restriction in JAXB they use one of the many MOXy extensions. For more information see: http://www.eclipse.org/eclipselink/ http://www.oracle.com/technology/products/ias/toplink/oxm/index.html -Blaise
  10. Interoperability?[ Go to top ]

    The Java to WSDL instead of a contract first (WSDL to Java) approach led to many interoperability problems because Java naming and other conventions made their way into the generated XML. Similar tools from .NET had the same kind of problem so for awhile many .NET and Java web services created this way (language to WSDL) did not interoperate. Once folks went contract first and created language neutral XML, that problem faded away. So, wouldn't a Java to XML data binding lead to the same kinds of interoperability problems?
  11. Re: Interoperability?[ Go to top ]

    The Java to WSDL instead of a contract first (WSDL to Java) approach led to many interoperability problems because Java naming and other conventions made their way into the generated XML.
    Do you have any examples of this interoperability problems?
  12. Re: Interoperability?[ Go to top ]

    Do you have any examples of this interoperability problems?
    Go back to 2003 and 2004 and you'll see a lot of articles. They mostly stemmed from how the naming conventions used by the .NET and Java tools when generating code for converting to and from XML. They tended to create names (in the schema and WSDL) that would break the corresponding code in the other language. There were type issues as well. I also read of problems between services created with different Java-based tools. By 2004, Microsoft had a guy who finally figured out the problem and he began blogging on their site about how contract first helped prevent these problems. I talked to him over the phone. He was the first person from MS who understood the problem. I'm sure if you googled for it you'd find some discussions about this on Microsoft's and the O'Reilly sites. (I was in a mixed J2EE/.NET shop and I was trying to convince others not to generate WSDL's or schemas from code for this reason.) I've always done contract first and I've stayed away from "magical" tools, so I didn't run into the problem myself.
  13. I had the same experience[ Go to top ]

    Yes I also had the same interoperability issues around 2003-4 frame and I was also working with a situation where we we were hosting Java web services and the client side were using .NET web services. They were using WSDL from code approach and since I was leading the web services development, I took WSDL first approach and was able to convince the client to do the same and could solve most of the interoperability issues we were having. My suggestion would be - for external facing web services ALWAYS prefer WSDL first approach and for intranet (internal) web services either approach would work. - Vijay
  14. Re: I had the same experience[ Go to top ]

    My suggestion would be - for external facing web services ALWAYS prefer WSDL first approach and for intranet (internal) web services either approach would work.

    - Vijay
    This is a valid suggestion. For the internal web services, if you do not really care about the WSDL (or service interface), you can use J2XB as a tool to gain overcome limitations of Axis2 binding options (J2XB does not require any code generation as does XML Beans and supports more features compared to the Axis2 internal binding framework). For external services, J2XB allows you to tailor the WSDL as you like by simply annotating the Java service interfaces. This approach gives you the same level of control over the WSDL you are used too. Do note that SOA frameworks like SCA define the service interface in WSDL or Java - J2XB annotated interfaces are a service definition in Java. SOA Services with published interfaces as Java interfaces are still considered contract first services - the fact that the contract is written in Java is not a problem for frameworks like SCA. J2XB complements this approach by allowing the service interface to include more information (using annotations) that tells how the service can also be represented as WSDL.
  15. Re: I had the same experience[ Go to top ]

    Yes I agree with you from the SCA perspective for the service definition in either Java or WSDL. From what I read so far J2XB looks more promising than JAXB/XMBeans and seems to be making the correct use of java annotations for their true intended use in tools like J2XB. Also this approach is likely to save on maintaining sync between the WSDL and the generated code or visa versa. I am definitely going to give J2XB a try. Thanks. - Vijay
  16. Re: Interoperability?[ Go to top ]

    Hi William, The interoperability problem you talk about did exist with the first implementations of Web Services because of the Java naming and similar issues you mentioned. However, the J2XB Axis2 module does not introduce those issues because J2XB allows (almost) full control over the generated types section of the WSDL. You can define, for a given Java class, the name and namespace of the class, which properties are mapped to XML and by which names, their order, Facets (or constraints), substitution groups, choice constructs, etc. The implementations that introduced the interoperability issues where those that tried to do everything automatic, generate the WSDL from the code using default mappings that cannot be customized. This is not the case with J2XB - you can customize almost every aspect of the XML simply by annotating the Java classes.