Webservices - WS Addressing and Asynchronous Invocation, or CXF

[Monica Valverde，修改在8 年前。]

I'm currently working on webservices to integrate with a system that uses ws-addressing for asynchronous communication. However I couldn't find any documentation where I could configure Service Builder and Liferay for that, so I ended up trying to figure out how to use CXF to create webservices without Service Builder. I've found an old post here, but it was already outdated.

Anyone has any idea for this? I'm currently using 6.2. Thank you.

[Chandan Sharma，修改在8 年前。]

You can do that in easy way if you don't want to use servicebuilder services.
1. Simply create a portlet project but don't add any portlet with that project(this is because if you create a portlet project then you will have the access of all the liferay libraries)
2. Add the Apache cxf libraries to the lib.
3. Configure the apache cxf to the web.xml and create your services.
4. Deploy the war file as you deploying your portlet.
5. Your services will be available on your portlet context so the wdsl url will be "http://<host>:<port>/<portlet-context>/<your service path>.wsdl

Note: you have to manage all the webservice configuration, security and classes. but good thing is you can use all the liferay services or class within your service class.

Thanks
Chandan

[David H Nebinger，修改在8 年前。]

Service builder is not necessary for web services, but using SB you get access to the Liferay permissioning system, access to the current user, etc.

There are solid reasons to use SB, hopefully you're not just discarding SB because you don't know how to use it.

[Monica Valverde，修改在8 年前。]

Chandan Sharma:

You can do that in easy way if you don't want to use servicebuilder services.
1. Simply create a portlet project but don't add any portlet with that project(this is because if you create a portlet project then you will have the access of all the liferay libraries)
2. Add the Apache cxf libraries to the lib.
3. Configure the apache cxf to the web.xml and create your services.
4. Deploy the war file as you deploying your portlet.
5. Your services will be available on your portlet context so the wdsl url will be "http://<host>:<port>/<portlet-context>/<your service path>.wsdl

Note: you have to manage all the webservice configuration, security and classes. but good thing is you can use all the liferay services or class within your service class.

Thanks
Chandan

Thank you for the instructions. I've been trying to use CXF in Liferay but there were errors in the way (why can't things work right in the first attempt??). Thought I've finally figured them out, and I've made a blog post tutorial for creating webservices using CXF in Liferay here (in case anyone needs): Liferay - Webservices With CXF Tutorial

David H Nebinger:

Service builder is not necessary for web services, but using SB you get access to the Liferay permissioning system, access to the current user, etc.

There are solid reasons to use SB, hopefully you're not just discarding SB because you don't know how to use it.

I wanted to see if there's a way to configure webservice specifications with Liferay as Service Builder can generate webservice code, but I guess that it's easier to simply build webservices outside it.

[David H Nebinger，修改在8 年前。]

Monica Valverde:

I wanted to see if there's a way to configure webservice specifications with Liferay as Service Builder can generate webservice code, but I guess that it's easier to simply build webservices outside it.

Really? It's really easier than adding "remote-service='true'" to your service.xml and then adding methods to the generated XxxServiceImpl class?

Um, no I don't think so.

Especially not if you want to plug into the Liferay permissioning system, access Liferay entities, etc.

[Monica Valverde，修改在8 年前。]

David H Nebinger:

Monica Valverde:

I wanted to see if there's a way to configure webservice specifications with Liferay as Service Builder can generate webservice code, but I guess that it's easier to simply build webservices outside it.

Really? It's really easier than adding "remote-service='true'" to your service.xml and then adding methods to the generated XxxServiceImpl class?

Um, no I don't think so.

Especially not if you want to plug into the Liferay permissioning system, access Liferay entities, etc.

Of course that using Liferay's "remote-service=true" is easy but as I said, I need ws-addressing specifications.

[David H Nebinger，修改在8 年前。]

Monica Valverde:

Of course that using Liferay's "remote-service=true" is easy but as I said, I need ws-addressing specifications.

Oh, snap, I just re-read the original post, you're building a client, not a service. I'd leave SB out of the discussion altogether. Build your client in whatever tech makes it easier to implement your web service client.

[Jack Bakker，修改在8 年前。]

I also recommend Service Builder approaches for server side to provide the service. As for client side consuming the service... well there are options...

[Monica Valverde，修改在8 年前。]

David H Nebinger:

Monica Valverde:

Of course that using Liferay's "remote-service=true" is easy but as I said, I need ws-addressing specifications.

Oh, snap, I just re-read the original post, you're building a client, not a service. I'd leave SB out of the discussion altogether. Build your client in whatever tech makes it easier to implement your web service client.

I have to build from server side, however the other system uses assynchronous webservice communication and ws-addressing specification. I'm not sure how to do so with Liferay's SB to generate code for that, so I'm ending up using CXF.

[David H Nebinger，修改在8 年前。]

You're mixing terminology, I think.

Just because you're doing it on the server, it's still a web service client and SB doesn't apply. Don't try to overcomplicate things or you'll have trouble completing the task.

Build out your web service client to get the data from the other system. Once you have the data, then you probably already have requirements for how to use it.

[Monica Valverde，修改在8 年前。]

David H Nebinger:

You're mixing terminology, I think.

Just because you're doing it on the server, it's still a web service client and SB doesn't apply. Don't try to overcomplicate things or you'll have trouble completing the task.

Build out your web service client to get the data from the other system. Once you have the data, then you probably already have requirements for how to use it.

I'm implementing webservices on the server side and the other system is the client that intends to invoke my webservices asynchronously. They use ws-addressing for that, and expect my webservices to be able to reply asynchronously.

The problem was that my exiating webservices generated with SB are only synchronous, and I'm not sure how to allow async response with them.

[Jack Bakker，修改在8 年前。]

Does anyone have a clear idea of what Monica is challenged with here ?

[Monica Valverde，修改在8 年前。]

Jack Bakker:

Does anyone have a clear idea of what Monica is challenged with here ?

I apologize if I was not being too clear in my question. What I intended to do was to create webservices that enables WS-Addressing in my portal. I was not sure how to use SB for that, so I ended up using CXF.

[Jack Bakker，修改在8 年前。]

Monica Valverde:

Jack Bakker:

Does anyone have a clear idea of what Monica is challenged with here ?

I apologize if I was not being too clear in my question. What I intended to do was to create webservices that enables WS-Addressing in my portal. I was not sure how to use SB for that, so I ended up using CXF.

I think you were clear but thought I'd poke a bit. There are many who read these forums and think: wow cool, I can use CXF and then in heading down that road miss out benefits of Service Builder as a more comprehensive approach all considered.

[Tomas Polesovsky，修改在8 年前。]

Hi,

portal uses Axis 1.4 for Service Builder generated SOAP services - lib/versions.xml:1072

First you need to find a way how to configure WS-Addressing to work with Axis 1.4. You will probably need probably to update server-config.wsdd generated by service builder, I guess SB will rewrite it each time you run build-wsdd so you may need to configure your build.xml to preserve the content after rebuild.

Otherwise use CXF, it just works.

[Monica Valverde，修改在8 年前。]

Tomas Polesovsky:

Hi,

portal uses Axis 1.4 for Service Builder generated SOAP services - lib/versions.xml:1072

First you need to find a way how to configure WS-Addressing to work with Axis 1.4. You will probably need probably to update server-config.wsdd generated by service builder, I guess SB will rewrite it each time you run build-wsdd so you may need to configure your build.xml to preserve the content after rebuild.

Otherwise use CXF, it just works.

Thank you for the advice. I was not sure where to configure WS-Addressing with SB so I ended up using CXF (created a portlet project and used CXF to create webservices).

[Jack Bakker，修改在8 年前。]

Tomas Polesovsky:

Hi,

portal uses Axis 1.4 for Service Builder generated SOAP services - lib/versions.xml:1072

First you need to find a way how to configure WS-Addressing to work with Axis 1.4. You will probably need probably to update server-config.wsdd generated by service builder, I guess SB will rewrite it each time you run build-wsdd so you may need to configure your build.xml to preserve the content after rebuild.

Otherwise use CXF, it just works.

and would seem Liferay 7 still using Axis 1.4 lib/versions.xml:1154

overall tho seems a bit of work to try and mod SB in v6.2 somehow ... wondering if in v7 OSGI approaches might embrace the CXF option better

[Tomas Polesovsky，修改在8 年前。]

Hi Jack,

For 7.0 we keep Axis 1.4 in portal-impl for backwards compatibility.

However, you are right, there is already built-in support for JavaEE 6 JAX-WS and JAX-RS based on CXF, using OSGi

If you (or anybody else reading this - btw. welcome! ) look at https://github.com/liferay/liferay-portal/tree/master/modules/portal and search for portal-cxf*, portal-rest* and portal-soap* modules you can see a framework prepared to be used.

It works based on Configuration objects that must be manually or programatically configured:
1. CXFEndpointPublisherConfiguration to create a new WS endpoint (CXF servlet) to listen there on a specific contextPath, with optional portal auth and CFX extensions.
2A, For JAX-RS then RestExtenderConfiguration with OSGi filters to wire JAX-RS applications, providers and filters together and using contextPaths map onto the CXF WS endpoint above. Requires the application to publish the services to OSGi environment.
2B, For JAX-WS then JaxWsApiConfiguration for publishing endpoints using JAX-WS API (Endpoint.publish(...)) or SoapExtenderConfiguration for wiring SOAP applications published to OSGi.

I don't want to write a full documentation here, there are portal-rest-extender-test and portal-soap-extender-test modules in https://github.com/liferay/liferay-portal/tree/master/modules/portal that can be used as examples. Basically they create the configuration objects above, publish their services (REST/SOAP) and then test themselves inside the container.

[Jack Bakker，修改在8 年前。]

Hope and sharing riddles/solutions. That's all I've got in response currently... Thanks Tomas

[Konrad Szeromski，修改在8 年前。]

Sometimes also "rpc/encoded" style of Liferay-generated WS can be real pain and force people to deploy own implementations