Expose a Webservice on CQ

[shanflex]

Hi,

I have a requirement to expose a SOAP WebService on CQ to be consumed by external client.  I ran into many materials around consuming web services, but no luck on finding write-ups/docs around hosting one.  Any pointers/references to blogs will be of great help.

Thanks!

[smacdonald2008]

That is an interesting use case. I know we have spent a lot of time consuming web services using OSGi bundles. However, I am not aware of anyone writing app logic to expose a WSDL from within CQ. I will add this to our community list of how to articles. As a start however -- i would recommend looking at Apache web services: http://ws.apache.org/. 

[Former Community Member]

smacdonald2008 wrote...

That is an interesting use case. I know we have spent a lot of time consuming web services using OSGi bundles. However, I am not aware of anyone writing app logic to expose a WSDL from within CQ. I will add this to our community list of how to articles. As a start however -- i would recommend looking at Apache web services: http://ws.apache.org/. 

Whilst I am new to CQ, application integration is a subject that I am very familiar with. So wouldn't exposing content stored in the repository via a REST (could use SOAP but I would have thought REST is a more natural fit to a resource oriented repository) service be a common way that a client application could/would use CQ ? ...where that content might be delivered via one of the supported representations indicated in the request. Isn't this a fairly typical data access pattern ?

We certainly have a requirement where an application (in this case a .Net web app) wants to be able to access content that is stored in CXF. Would you suggest a different approach for that ?

Regards

Fraser

[smacdonald2008]

That is a good point -- you can get at JCR content  from non-Java apps (ie - .NET) or submit data using a Restful request. As a matter of fact -- there is a community article on that use case:

http://scottsdigitalcommunity.blogspot.ca/2013/06/submitting-data-to-adobe-cq-jcr-using.html

However -- if you wanted to write a Java-based CQ service like this:
 

//This is a component so it can provide or consume services

@Component

@Service

public class FooServiceImpl implements FooService {

    public int getFooCount() ; 

//....

The question is can I consume the FooServiceImpl service using a WSDL. Out of the box -- CQ does not expose a WSDL. 

[Former Community Member]

smacdonald2008 wrote...

That is a good point -- you can get at JCR content  from non-Java apps (ie - .NET) or submit data using a Restful request. As a matter of fact -- there is a community article on that use case:

http://scottsdigitalcommunity.blogspot.ca/2013/06/submitting-data-to-adobe-cq-jcr-using.html

However -- if you wanted to write a Java-based CQ service like this:
 

//This is a component so it can provide or consume services

@Component

@Service

public class FooServiceImpl implements FooService {

    public int getFooCount() ; 

//....

The question is can I consume the FooServiceImpl service using a WSDL. Out of the box -- CQ does not expose a WSDL. 

Thanks for your response. I suspect that since CQ exposes resources via REST its not altogether surprising that there isn't OOTB support for SOAP/WSDL (although one might ask if WADL is provided as an alternative - but I guess not many start from that point with REST).

To be honest I would be wary of starting out from a 'code-first' perspective for service design since that has a tendency to lead to undesirable coupling of the technical implementation and leak those details through the service interface (which should of course be agnostic). So for SOAP support I would probably expect a service designer to create the abstract parts of the WSDL (everything up to the portType). I guess this could be provided 'out of band' to the service consumer(s) or possibly stored in the CQ repository and made available via a REST request ? For those that *really* want to do SOAP, it would be helpful for CQ to emit a WSDL based on a the XML representation of a resource but that still leaves plenty of potentially important meta-data absent and in reality only gets you to a bare-bones spec in most cases. As for implementation it isn't too difficult to create your own JAX-WS provider endpoint which you could then route thru to CQ/CRX.

Kind regards

Fraser.

[shanflex]

Thanks for the responses. For the time being, we got things moving by having an intermediate SOAP endpoint (guess something along the lines of what @Fraser mentions) that routes the request to CQ as required (we are in Dev/POC phase). It is certainly not the way we would like to keep (having two different applications/deployment etc), so will continue exploring possibility of developing in CQ itself.  Request folks to continue update in case they have any interesting findings/experience around such integration.

Thanks again!

[smacdonald2008]

An update on this issue. You can write an OSGi that exposes a WSDL by using Apache CXF. See: http://cxf.apache.org/distributed-osgi-reference.html.



 

[smacdonald2008]

An update on this -- i ran through the quick start here: http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html.

I was hoping to get a WSDL after uploading the  OSGi Compendium Specification interface bundles as discussed and the bundle. However -- i did not get a WSDL - even through my bundle contains the correct Java Distributed OSGi application logic:

public class Activator implements BundleActivator {

    private ServiceRegistration registration;

    public void start(BundleContext bc) throws Exception {

        Dictionary props = new Hashtable();

        props.put("service.exported.interfaces", "*");

        props.put("service.exported.configs", "org.apache.cxf.ws");

        props.put("org.apache.cxf.ws.address", "http://localhost:4502/greeter");

        registration = bc.registerService(GreeterService.class.getName(), new GreeterServiceImpl(), props);

    }

    public void stop(BundleContext bc) throws Exception {

        registration.unregister();

    }

}

I do not think Adobe CQ suports this as it just did not work as specified in this Apache topic. I asked the product team to confirm if this is supported and looks like its not. If i hear an update  - i will post an update.  

[Sainath_Appam]

Hi smacdonald2008,

I also followed same url shared by you ( http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html), i created all the setup which was discussed in the article. after the configuration my felix console will look like the one in attachment.

but when i try to build CXF Distributed OSFi Greeter Demo Service Implementation Bundle(which will consists Activator.java) i am getting java.lang.RuntimeException: Soap 1.1 endpoint already registered on address http://localhost:9090/greeter and hitting  http://localhost:9090/greeter( i configured port as 9090) is giving blank screen. i uninstalled the bundle and tried once again but the problem is same.

So can you please help me what i am missing and you told after the successful configuration also,you did not get wsdl and you are in touch with product team. so do you have any update on that? and  please share if you have any other approaches on this.

Thanks in advance.

Regards,

Sainath

[smacdonald2008 · Accepted solution]

I asked the Dev team - but CQ does not support CXF Distribute APIs. I ran into the same issue as you. 

[__96]

Hi,

Even I tried for implementing restful webservice hosting in CQ5 jersey based but couldn't. Does anyone here has any idea on this ?

Thanks.