Which Java SOAP XML object serialization library would you recommend for Java object exchange with other platforms / languages (.NET, Delphi)?
Communication scenarios could look like this:
Java object writer -> SOAP XML text -> .NET or Delphi object reader
.NET or Delphi object writer -> SOAP XML text -> Java object reader
I know there is the XStream XML serialization library and JSON as alternative solutions, however since Delphi and .Net have built-in support for SOAP XML serialized objects, this would offer a 'standardized' way with support for advanced features like nested objects, arrays and so on.
Edit:
Meanwhile, I found JAXB - (https://jaxb.dev.java.net/), JAXMe, and JiBX - Binding XML to Java Code(http://jibx.sourceforge.net/). But they do not generate SOAP serialized XML by default.
A possible solution would be a web service library which is able to run without a HTTP server, and offers a simple file interface for the SOAP XML content (not a complete request, just a serialized object). Axis 2 and CXF look very interesting.
I prefer JAX-WS (with JAXB 2.1 databinding) over the other liberaries I've used (JAX-RPC, Axis 1 and 2, but not XFire). The JAXB 2 databinding uses generics, which makes for a pleasant mapping of properties with a maxoccurs > 1. JAX-WS itself is reasonably well documented and provides a reasonably good API. The method and parameter annotations can get a bit out of hand in some cases - XML hell in annotation form. It usually isn't so bad.
One of the nice aspects of the JAX-WS stack is project Metro, which Sun co-developed with Microsoft and interoperates well with the web service support .NET 3.0, going so far as to implement MTOM in a workable fashion.
I would recommend CXF. It is a very good services stack and includes JAXB data binding and JAX-WS support. You may want to look at an open source integration platform like Mule that includes CXF (also supports Axis and XStream) if you need more advanced transformation and routing of your messages. It is lightweight and can be embedded or run without an app server.
In addition to Axis2 which works ok, Sun's JAX-WS (version 2) and Apache CXF (nee XFire) are worth checking out, it Soap is your thing. CXF may be the most mature of the 3, so that's my favorite, but all 3 are pretty good.
The standard library for this would probably be Apache Axis1. I would advise using axis2 instead of axis 1.4- though it works pretty well.
Bearing in mind that the all of the SOAP extensions make the dream of interoperability just that... a dream.
I think you have answered your own question.
XStream (outputting as JSON) is a nice clean solution. If you alias types you get a clean output format. After that it doesn't matter which SOAP stack you use so long as it is nice and interoperable with Delphi/.NET.
Related
I need to work with a REST service that has a relatively simple and fixed (meaning predictably not very variant structure), yet I can't find a WADL anywhere on their site. I have previously worked with SOAP services, which had a decent WSDL and I used it to generate my Java classes to which my client app was marshalling the service data using Axiom2.
My question is: is there an easy way to reverse engineer a WADL with which to easily generate corresponding Java classes if the site is lacking one, using some implementation of JAX-RS (e.g. Jersey)? Another way to ask it is: given only a REST service, no WADL, and some form of JAX-RS, what is the easiest way to generate marshalled classes on the client side?
Currently, as the structure is simple, I do it the hard way of using straight DOM from Java SE (org.w3c.dom) to parse the document. It works fine but I do not like all the traversing I have to do within the document structure and I feel like I reinvented the wheel. I am sure there is a more elegant way.
If you're just doing this once why not just do it by hand? If you need to do this regularly then you may be out of luck wrt WADL (as an aside see: https://softwareengineering.stackexchange.com/questions/133145/should-i-use-wadl-to-describe-my-restful-api).
Are you just trying to generate Java classes for the DTOs from the service? In this case you could take some sample XML from the service and use this to generate a possible XSD (maybe using trang). Then use XJC to generate the corresponding Java classes.
If the REST service is implemented in Jersey, Jersey should auto generate the WADL at runtime. The default location is http://server:port/appcontextroot/application.wadl. If the REST service uses other implementation such as RESTEasy, you are out of luck. https://issues.jboss.org/browse/RESTEASY-166
I need to query XML out of a MarkLogic server and marshal it into Java objects. What is a good way to go about this? Specifically:
Does using MarkLogic have any impact on the XML technology stack? (i.e. is there something about MarkLogic that leads to a different approach to searching for, reading and writing XML snippets?)
Should I process the XML myself using one of the XML APIs or is there a simpler way?
Is it worth using JAXB for this?
Someone asked a good question of why I am using Java. I am using Java/Java EE because I am strongest in that language. This is a one man project and I don't want to get stuck anywhere. The project is to develop web service APIs and data processing and transformation (CSV to XML) functionality. Java/Java EE can do this well and do it elegantly.
Note: I'm the EclipseLink JAXB (MOXy) lead, and a member of the JAXB 2 (JSR-222) expert group.
Does using MarkLogic have any impact on the XML technology stack?
(i.e. is there something about MarkLogic that leads to a different
approach to searching for, reading and writing XML snippets?)
Potentially. Some object-to-XML libraries support a larger variety of documents than other ones do. MOXy leverages XPath based mappings that allows it to handle a wider variety of documents. Below are some examples:
http://blog.bdoughan.com/2010/09/xpath-based-mapping-geocode-example.html
http://blog.bdoughan.com/2011/03/map-to-element-based-on-attribute-value.html
Should I process the XML myself using one of the XML APIs or is there
a simpler way?
Using a framework is generally easier. Java SE offers may standard libraries for processing XML: JAXB (javax.xml.bind), XPath (javax.xml.xpath), DOM, SAX, StAX. Since these standards there are also other implementations (i.e. MOXy and Apache JaxMe implement JAXB).
http://blog.bdoughan.com/2011/05/specifying-eclipselink-moxy-as-your.html
Is it worth using JAXB for this?
Yes.
There are a number of XML-> Java object marshall-ing libraries. I think you might want to look for an answer to this question by searching for generic Java XML marshalling/unmarshalling questions like this one:
Java Binding Vs Manually Defining Classes
Your use case is still not perfectly clear although the title edit helps - If you're looking for Java connectivity, you might also want to look at http://developer.marklogic.com/code/mljam which allows you to execute Java code from within MarkLogic XQuery.
XQSync uses XStream for this. As I understand it, JAXB is more powerful - but also more complex.
Having used JAXB to unmarshal xml served from XQuery for 5 years now, I have to say that I have found it to be exceptionally useful and time-saving. As for complexity, it is easy to learn and use for probably 90% of what you would be using it for. I've used it for both simple and complex schemas and found it to be very performant and time-saving. Executing Java code from within MarkLogic is usually a non-starter, because it runs in a separate VM on the Marklogic server, so it really can't leverage any session state or libraries from, say, a Java EE web application. With JAXB, it is very easy to take a result stream and convert it to Java objects. I really can't say enough good things about it. It has made my development efforts infinitely easier and allows you to leverage Java for those things that it does best (rich integration across various technologies and platforms, advanced business logic, fast memory management for heavy processing jobs, etc.) while still using XQuery for what it does best (i.e. searching and transforming content).
Does using MarkLogic have any impact on the XML technology stack?
No. By the time it comes out of MarkLogic, it's just XML that could have come from anywhere.
I need to query XML and marshal it into Java objects.
Why?
If you have a good reason for using Java, then we need to know what that reason is before we can tell you which Java technology is appropriate.
If you don't have a good reason for using Java, then you are better off using a high-level XML processing language such as XSLT or XQuery.
As for JAXB, it is appropriate when your schema is reasonably simple and stable. If the schema is complex (e.g. the schema for articles in an academic journal), then JAXB can be hopelessly unwieldy because of the number of classes that are generated. One problem with using it to process XQuery output is that it's very likely the XQuery output will not conform to any known schema, and the structure of the XQuery results will be different for each query that gets written.
All
I am looking for some method to show metadata info about RESTful webservice,
e.g. operations, parameters and so on.
Do u know any ?
One popular solution is to use Atom and AtomPub
I hear HTML is popular for representing end point meta data. You have link refs, you have forms for payloads, lots of room for english text to explain things, the format is well documented with a well known processing model.
Some rest endpoints support WADL.
WADL to REST is similar as WSDL to JAX-WS (SOAP).
You can find more about wadl at: http://wadl.java.net/ (including specification link).
Jersey (http://jersey.java.net) is a Oracles JSR-311 Reference implementation and it also have some additional features, like automatic WADL generation, which was recently (version 1.9) improved - it includes XSD schema for transmitted types (that can be used for far better client code generation).
In general, if you want to use some standard, please use WADL and don't reinvent the wheel..
The jax-doclets package can generate javadoc-like documentation from your JAX-RS or JAXB annotations.
http://www.lunatech-labs.com/open-source/jax-doclets
On our projects we currently generate documentation by hand but we are beginning to evaluate this tool.
Now, working with Spring-WS, I sometimes miss the simplicity of working with axis, where you just call a tool on the WSDL and XSD, and it creates the java objects and marshaller configurations, an interface that represents the information in the WSDL, a complete webservice client that implements this interface, and a server stub. Within minutes you can start writing the actual code for the webservice.
With Spring-WS you have much more configuration work to do - you have configure a marshaller, an endpoint, code all the information in the WSDL manually, and using the soap faults from the WSDL in form of java Exceptions seems difficult. Is there any tool that simplifies this work to a similar degree? I understand and appreciate that Spring-WS is flexible and whatnot, but sometimes you just want to whip up a quick webservice.
If you want the quick-and-easy tooled approach, then Spring-WS is not for you. It emphasises flexibility, small footprint and runtime simplicity, at the expense of having a bit more to do at first.
If this isn't what you want, then stick with the more heavyweight stacks like CXF or Axis2.
It's explained on this page: Why Contract First?. Basically, since there are problems to be solved when starting from a WSDL, they have chosen to drop the ball. If you want to work from a WSDL and keep being integrated with Spring, then choose CXF.
I am creating a WCF Service that will be consumed by both .NET and Java client applications.
We do not have any Java experience in the team, so are looking for guidelines or rules to follow to ensure that we do not accidentally include any types in our WCF Service interface or do anything else that would preclude it from being consumed by a Java client application.
Are our worries well-founded? If so, what should we be wary of?
Edit
One example of a concern is whether a .NET DateTime value is represented in the service interface in a manner that can be correctly understood by a Java client.
Edit2
A second example of a concern is the use of any nullable value types (bool?, int? etc).
Edit3
At present some of our development teams are hand-writing .xsd files to define the various objects that the WCF interface methods will take as arguments and return as return values. They are then using xsd.exe to auto-generate C# classes from these.
The rationale behind this is that it guarantees that the generated classes won't contain anything that is .NET-specific.
The downside is that this adds a development burden and also precludes us from documenting these classes using <summary> tags (.NET equivalent of javadoc comments).
The recommendation to start with XSD is a good one. That will not guarantee compatibility on each side, as XML Schema is really big and no web services stack supports all of it. (Example: lists).
So, start with XSD, but confine yourself to mainstream types. Primitives, complextypes composed of primitives, arrays of same. You can safely nest complextypes and arrays. (arrays of complextypes, complextypes that contain arrays or complextypes, etc).
Stay away from restrictions, substitution groups, lists, derivations, and any other XSD esoterica. Even XSD enumerations should be avoided.
About dateTime:
It's not enough to use a nullable datetime. There are formatting concerns as well. The .NET DateTime is a higher resolution quantity than a Java Calendar and as a result, shipping a .NET time to Java can result in de-serialization exceptions on the Java side. (EDIT: using the DataType="dateTime" decorator in the XmlElement attribute on the .NET side can make sure you serialize properly)
Some old advice on that.
Finally, it is not true that you cannot use in-code XML doc on the classes that get generated. With C#'s partial classes, you can write separate code from the generated classes with the in-code doc you want. Even if you re-gen the code, your partial class code will remain unchanged. EDIT: When you compile, the doc will appear on the classes.
EDIT: Someone asked, if using XSD-first is not enough to guarantee interop, why use it? My answer: it is not a guarantee but it is a good step, it helps. It keeps you away from designing interfaces in code (either Java or C# or VB, etc) that expose platform-specific things like .NET DataSets, generic Dictionaries, Java ResultSets, etc, all of which present interop problems. There are still pitfalls in the more marginal parts of XSD, but you can usually avoid those with thoughtful design.
I should have mentioned in my original answer that you can apply an iterative process to the development of the interface. Design in XSD, then generate (client) stub and (server) skeleton code from the XSD+WSDL, then adjust and do it again.
Using basicHttpBinding endpoint will guarantee that any SOAP 1.1 compatible client will be able to consume your service.
Use DateTime?, i.e. a nullable struct. Java does not have the notional of complex value types (i.e. structs). I believe there are ways to specify in the WSDL not to allow nulls, but I think WCF doesn't do it out of the box.
Use arrays instead of collections. If I recall correctly, the collection types do not translate very well over SOAP, but array types do quite well.
You should get a copy of Eclispe or Netbeans. After you create a prototype WCF service, run the web service wizard to create your proxies. Examine the object model for any major defects with particular emphasis on complex objects or non-primitive types (treat string as a primitive).
The learning curve to do that with Netbeans or Eclipse is pretty flat, so it's not a huge burden.
Edit: The other potential problems are with the bindings. If you stick with HTTP(S), you should be good... start going to the alternatives like TCP or MSMQ, you'll have to do a lot of work in Java. Also, some of the security features don't interop in all cases, such as using NTLM tokens... Take an iterative approach. Start with a simple HTTP w/SOAP binding with no security and go from there.
Does WCF provide standard SOAP interfaces? If it does, getting Java to talk to it should be a doddle.
Re: Edit1: The WSDL / XSD will use a standard date time format (Calendar at the Java end, a formatted datetime string in the SOAP, DateTime in .NET), or you could force it into a string format of your own choosing.
Read up on the Apache Axis (1.4 and 2.0) documentation for Java web services. It's very easy to use to get a Java web service client set up from the wsdl/xsd that your web service will provide.
Edit3: In Java you would define a Java model (with all your favoured documentation), then run Java2WSDL (preferably as an ANT/Maven task) to create your WSDL (however I have found you need to hand-reorder the fields in it). Axis 2 supports Collections and Enums just fine, Axis 1.4 likes Arrays and hand-rolled Java 1.4 style enumerations. From this WSDL you would create a server-side skeleton using WSDL2Java in which the only thing you need to do is implement your business logic.