Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

JAXB 2.0 looks quite good - it supports XML Schema, generates nice POJOs, supports schema extension points and has StAX support. The only downside is its Java 5 specific - and the XJC tool tends to break when you give it a collection of real world WSDLs (like WS-Notification for example).

ActiveSOAP now fully supports JAXB 2.0 as a marshalling layer for REST and SOAP web services; allowing you to use a nice and simple marshalling layer and keep your code based on simple POJOs. To get a feel for how this works see the examples

We've added support to ActiveSOAP for XStream making it easy to expose POJOs over REST or SOAP endpoints using XStream's simple & fast XML serialization. There are some examples here.

So now we've the best of both worlds.

  • if you're starting from the POJO route you can use a tool like XStream to work in a REST/SOAP way
  • if you're given a WSDL / XSD to interact with, you can use XMLBeans to autogenerate XMLBeans from the WSDL/XSD

You can happily mix and match both approaches, together with any other kinds of XML binding tools you wish - all using a simple & lightweight REST/SOAP framework with pluggable transports for HTTP and JMS.

We have added a few examples of using ActiveSOAP and XMLBeans to invoke web services or REST services, which relies on auto-generating a service interface from the WSDL at the same time you generate your XMLBeans interfaces.

If you want to be dynamic, there's also a Dynamic client which allows you to invoke services without code generation.

Its very popular to use a RESTful approach of sending blobs of XML over HTTP or JMS. Using the full SOAP protocol and WS-* is often an unnecessary overhead.

ActiveSOAP now supports both pure REST and one or more SOAP protocols concurrently on the same service endpoint over HTTP and/or JMS (or other transports).

This allows lightweight some clients to use pure REST and then when the use of the SOAP protocol (and other optional WS-protocols) makes sense, to support those too all in the same endpoint.

This is useful as you should only pay for what you need; for many use cases pure REST is fine - its often up to the endpoint to decide whether or not the SOAP protocol is worth the cost and if it is which version of SOAP it wishes to support along with what of the WS-protocols it requires too.

We've added an example to CVS which demonstrates how to bind a POJO service written using XMLBeans generated from a WSDL to both REST and SOAP.

Its easy to map multiple operations on different ports to the same service instance or to separate operations on the same port to different service instances however you see fit.

Confluence RSS Feed
Confluence Syndication Feed
  • No labels