JAXB Transformation Quickstart

[antollinim]

Hello,

I have just implemented a JAXB quickstart following Tom Fennelly's screencast.

I have it working now (using SOAP binding) but I wanted to discuss some things before pushing the code.

1 - My biggest concern is that, when using JAXB, I had to modify both the signature of the operations and, thus, the internal implementation of the service.

In concrete, before using JAXB the Service looked like this:

@Service(OrderService.class)
public class OrderServiceBean implements OrderService {
    
    @Override
    public OrderAck submitOrder(Order order) {
        // Create an order ack
        return new OrderAck()
            .setOrderId(order.getOrderId())
            .setAccepted(true)
            .setStatus("Order Accepted");
    }

}

Now, with JAXB, it looks like this:

@Service(OrderService.class)
public class OrderServiceBean implements OrderService {
    
    @Override
    public SubmitOrderResponseType submitOrder(SubmitOrderType order) {
        // Create an order ack
        OrderAckType orderAck = new OrderAckType();
        orderAck.setOrderId(order.getOrder().getOrderId());
        orderAck.setAccepted(true);
        orderAck.setStatus("Order Accepted");
        SubmitOrderResponseType sort = new SubmitOrderResponseType();
        sort.setOrderAck(orderAck);
        return sort;
    }

}

Am I doing something wrong or is it intended to work this way? I am asking cause I think JAXB is being too invasive here. If the databinding of a running service needs to be changed in the future, the signature will need to change as well.

2 - One minor issue was that during the execution of wsconsume.bat, the source files were generated OK, but the compilation failed with this error: 

.\org\switchyard\quickstarts\transform\jaxb\OrderService_Service.java:60: cannot find symbol
symbol  : constructor Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
location: class javax.xml.ws.Service
        super(WSDL_LOCATION, SERVICE, features);
        ^
.\org\switchyard\quickstarts\transform\jaxb\OrderService_Service.java:67: cannot find symbol
symbol  : constructor Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
location: class javax.xml.ws.Service
        super(wsdlLocation, SERVICE, features);
        ^
.\org\switchyard\quickstarts\transform\jaxb\OrderService_Service.java:74: cannot find symbol
symbol  : constructor Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
location: class javax.xml.ws.Service
        super(wsdlLocation, serviceName, features);
        ^
3 errors
Failed to invoke WSDLToJava
org.apache.cxf.tools.common.ToolException: Failed to compile generated code
        at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:115)
        at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:262)
        at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:138)

The source files compiled ok when integrated in my project.

3 - A minor bug showed up in Windows. In wsconsume.bat, there is a "\" at the end of line 22 which should be replaced by "/" (otherwise it fails to run). I do not know whether this belongs to Switchyard's or AS7's team.

Any thoughts?

Thanks,

Mario

[kcbabo]

Hey Mario,

Thanks for blazing the trail here.  Can you post a link to your quickstart branch which contains the new quickstart?  That will help sort some of this out.

One of the issues I think you are probably running into here is that the existing Orders quickstart uses a WSDL that we created from scratch vs. using web service generation tooling.  This means that the default naming for objects and XML types will not match what we have in the quickstart, hence the requirement to change the interface definition.  If you're going to use the orders quickstart as the basis for your JAXB quickstart, then you should be able to annotate the existing Order and OrderAck objects with JAXB annotations and not mess around with any of the generation tooling.  On the other hand, if you want to start from scratch, then you could take a WSDL, generate the appropriate objects, then use those in your service interface.

cheers,

keith

[antollinim]

Hey Keith,

this is my topic branch: https://github.com/antollinim/quickstarts/tree/SWITCHYARD-333

So, are you saying that names for the generated classes are taken from the WSDL?  For example, the submitOrder parameter type was called "SubmitOrderType" instad of "Order" in the WSDL? That makes sense...

I will try that then.

Thanks for your help!

Mario

[tfennelly]

Hey Mario.

Maybe I'm looking at this wrong, but when I think of JAXB I don't really think in terms of taking something that was hand crafted earlier and is already working and then trying to impose JAXB on top of it.  Sure you can take existing Java classes and annotate them with JAXB annotations (manually cross ref between the java types and the xsds.... adding JAXB annotations appropriately) but that seems like it would be a total pain to get working.  I know when I tried this in the past it drove me insane.

When I think JAXB I think of taking an already defined xml schema (or wsdl) and generating a set of annotated POJOs from it and then building your service... not the other way around.  Maybe I shouldn't have based that screencast on the existing orders demo wsdl and operations.

T.

[kcbabo]

Maybe I'm looking at this wrong, but when I think of JAXB I don't really think in terms of taking something that was hand crafted earlier and is already working and then trying to impose JAXB on top of it.  Sure you can take existing Java classes and annotate them with JAXB annotations (manually cross ref between the java types and the xsds.... adding JAXB annotations appropriately) but that seems like it would be a total pain to get working.  I know when I tried this in the past it drove me insane.

I agree that there is a definite YMMV element to this, but it's still an important use case that we should make sure works.  If you have a set of domain objects and you plan to have an XML representation of those objects, adding JAXB annotations seems like a reasonable way to do that.  You can then generate a schema for those objects and that can be referenced from any WSDLs that you create.

[tfennelly]

Keith Babo wrote:

I agree that there is a definite YMMV element to this, but it's still an important use case that we should make sure works.  If you have a set of domain objects and you plan to have an XML representation of those objects, adding JAXB annotations seems like a reasonable way to do that.  You can then generate a schema for those objects and that can be referenced from any WSDLs that you create.

I agree it should be totally possible and I've no reason to think it's not, so long as you manage to apply the annotations properly.  That's the trick imo - anything more than a trivial model would be a tedious, error prone head wrecker

Anyway... just trying to highlight where the possible frustrations for Mario may be coming from.

[antollinim]

Thanks Tom,

Tom Fennelly wrote:

Hey Mario.

Maybe I'm looking at this wrong, but when I think of JAXB I don't really think in terms of taking something that was hand crafted earlier and is already working and then trying to impose JAXB on top of it.  Sure you can take existing Java classes and annotate them with JAXB annotations (manually cross ref between the java types and the xsds.... adding JAXB annotations appropriately) but that seems like it would be a total pain to get working.  I know when I tried this in the past it drove me insane.

When I think JAXB I think of taking an already defined xml schema (or wsdl) and generating a set of annotated POJOs from it and then building your service... not the other way around.  Maybe I shouldn't have based that screencast on the existing orders demo wsdl and operations.

T.

you are right, that was my first misconception. I was expecting JAXB to magically do the data binding for an existing Service.

Mario

[antollinim]

Hi Keith,

Keith Babo wrote:

Hey Mario,

Thanks for blazing the trail here.  Can you post a link to your quickstart branch which contains the new quickstart?  That will help sort some of this out.

One of the issues I think you are probably running into here is that the existing Orders quickstart uses a WSDL that we created from scratch vs. using web service generation tooling.  This means that the default naming for objects and XML types will not match what we have in the quickstart, hence the requirement to change the interface definition.  If you're going to use the orders quickstart as the basis for your JAXB quickstart, then you should be able to annotate the existing Order and OrderAck objects with JAXB annotations and not mess around with any of the generation tooling.  On the other hand, if you want to start from scratch, then you could take a WSDL, generate the appropriate objects, then use those in your service interface.

cheers,

keith

I updated the WSDL to have the names I was expecting. The operation signatures remain the same now. However the internal implementation still depends on JAXB's bindings. I guess this is expected, right?

I pushed the new version in the same topic branch: https://github.com/antollinim/quickstarts/commits/SWITCHYARD-333

Does it look better now?

Mario