It's taken a little longer than planned due to Liferay's annual company retreat and the engineering retreat we did along with it, but here I am with the third entry in the Liferay's Architecture blog series. I also plan to write a fourth one and schedule it for publication next week while I'm on vacation. 

My last entry explored how Liferay's code is organized around the concept of services which are used from the frontend (portlets, servlets, ...) but that can also be used by third party or custom plugins using the available Java API. The goal of this entry is to show how the remote services layer is also exposed through several web services protocol for remote consumption.

This layer is built automatically by that wonderful tool called Service Builder based on the remote service interface and annotations left in the implementation by its developers. One of the benefits of automatic generation is that it is easy to support many protocols with little extra effort. However I'm only going to mention the two most significant and used protocols:

• JSON Web Services: This is a new way of accessing Liferay's web services that was added in 6.1 thanks to the lead of Igor Spasic. It provides a lightweight RPC-based protocol that uses JSON as the data exchange format. This protocol is specially useful when invoking the services from JavaScript (including from the browser) or other non-Java languages. It can also be useful for mobile apps. In fact Liferay Sync Mobile App (guide) for iOS and Android uses this protocol to communicate with Liferay. One very nice and not so widely known feature of JSON Web Services is that it comes with an API browser included. You can access it by going to the URL http://your-host-name/api/jsonws (don't forget to secure it for production). For more information check the JSON Web Services chapter in the Developer's Guide.
• SOAP: The good old XML-based protocol that has declined in popularity lately but is here to stay. One of the main benefits of SOAP is the amount of tooling available as well as the out of the box integration offered by some software packages. If you need to use SOAP to communicate with Liferay (and it still happens often), it is supported for you. For those curious about the implementation we use Apache Axis 1.4 to handle the protocol aspects. We don't use Apache Axis 2 for a variety of reasons including the fact that it is distributed as many JARs, some of which are already provided by some app servers out of the box which makes support across all app servers quite harder.  For more information check the SOAP Web Services chapter in the Developer's Guide.

One last important aspect you should know is that all web services in Liferay will be invoked using Liferay's permission system. The client applications need to provide the credentials of the user they want to execute the methods as. The simplest option to do it is using HTTP Basic Authentication. That means that if you are accessing web service through an unsafe network (which will be most probably the case) you should use HTTPS to avoid sending the passwords on clear. An alternative coming in 6.2 (which is much nicer in many ways) is to use the OAuth protocol.

That's it for now. I'll use this opportunity to wish you all a Merry Christmas (or for those who don't celebrate Christmas, Happy Holidays! :))