SOA / Web Services / Java

A Technology Blog

Archive for March, 2009

When to use REST based web services?

Posted by Vivek on March 11, 2009

REST expose a much simpler interface than SOAP, with some limitations. Development with REST is easier and quicker and this is the reason why most famous web APIs are REST-based.
 
The limitations are related to the protocol: with REST you are bound to HTTP. So it is difficult to handle different transports like MQ or JMS. So if you are designing an application to be used exclusively on the web, REST could be the option. If you are designing a SOA for an Enterprise, that needs to interconnect to multiple systems using multiple transport/channels and having sophisticated transactions to be modeled with BPMs, then it is better to go with SOAP.
Note than you are going to pay SOAP’s flexibility with development complexity: SOAP interfaces are described by the WSDL standard which looks really complicated and is not supposed to be read by humans.

RESTful applications simply rely on the built-in HTTP security (the HTTPS protocol), with SOAP you can have more sophisticated choices, like WS-Security that lets you encrypt only portions of the messages and moves the security handling from the transport layer to the message layer.

REST is younger than SOAP, so it is not as well supported by commercial products (both BPM and ESB products). However new versions of the major ESBs support REST (ex mule, openesb).

RESTful services do not have a strict describtor, they tried to define something simmilar to WSDL, it’s called WADL (https://wadl.dev.java.net/). The WADL is currently not a common standard the adoption is very low and mostly not wanted for RESTful services.

Even for ESB’s most of the vendors where lacking the support some month ago. But now nearly each big ESB vendor (commercial or open source) supports the RESTful protocol. From the usage of an ESB it is currently not a problem to run RESTful services.

If you plan to run a very big deployment with many data interfaces, you will get great benefits using RESTful Services. REST is based 100% on the HTTP rfc (http://www.w3.org/Protocols/rfc2616/rfc2616.html). Many of the RESTful Interface which you see currently on the internet do not fully support HTTP specification, the result is that they could not benefit from it in terms of performance, caching, content negotiation and security. 
One great reason is to use RESTful interfaces is it can easily support different content-types/mime-types. First you think about, vendor specific XML with a xsd definition, later you would like to support AJAX Mashups and even later you think about to support text formats, reports in PDF, and so on. This is very easy to implement with REST because you query always with the same data query but the requested content type is just different.
Another reason why people are using RESTful interfaces is to be scalable like the web (www) and google. This is possible when you are using plain and simple HTTP protocol. You have support from so many standard product like web proxy caches (like SQUID) or other to scale your application a very low effort. For Social Communities you have have now a new Standard for RESTful Service Security. It is called Oauth (http://oauth.net/) which makes authentication over HTTP very easy.

Some other examples where RESTFul Services are dominant:
Amazon AWS: E.g. they offer Services for Storage (S3) and they have SOAP and REST interfaces but over 90% of the clients are using REST
Google Maps is using RESTful uris to provide cachable map tiles
yahoo API’s are mostly build with RESTful interfaces
RESTful Services are very dominant in lighweight web 2.0 API’s for Mashups like OpenSocial
API.

REST design is good for the database driven applications and when client wants quick integration.

Advertisements

Posted in Web Services | Tagged: | 12 Comments »

Some Web Services Best Practices

Posted by Vivek on March 7, 2009

1. Start designing web service with WSDL and schema i.e., follow Top-Down approach.If already have classes or EJBs that need to be exposed as web services,then bottom-up approach is the only choice and the resulting WSDL will be generated by Web Services toolkit. It is easy to design a Web Service from exisiting classes but then it offers less flexibility when reuse of definitions are desired. Also, the WSDL will contain a format that is specific to the web services toolkit being used and it will not be possible to add extra information or annotations in the WSDL by including the documentation element of WSDL.

2. In RPC style of web services, the job of marshalling and unmarshalling is performed by SOAP engine. This may lead to significant performance degradations if complex operations are involved. However, RPC style web services are better suited for implementing fine-grained functionalities.

3. Implemention of Document style web services is complex and time-consuming. Document-style Web Services can handle large documents without any performance trade-offs. If coarse-grained functionality is required then Document style web service is the right choice. These are also suitable when asychronous operations are involved.

4. Using “encoding” requires both sides to have prior knowledge of the encoding style. It is the responsibility of SOAP engine to perform encoding adn decoding, which is an overhead. It is not preferred for complex data structures.

5. When use is set to “literal”, XML schema directly defines the data types. It is preferred when complex and custom data types are involved and better performance is desired.

6. To decide what style and use from available choices: RPC-encoded, RPC-literal, Document-literal and Document-encoded, should be used, following link that gives detailed explanation can be referred:
 
 http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ 

7. SOAP with attachment or SwA is useful for documents that conforms to schema in languages not supported by web service end point.Sending information as attachments rather than in SOAP body results in smaller body and faster processing. However, writing a SOAP handler can be tedious. Care should be taken while using Message Queues to transmit the message as the message queue capacity may be less and the message may require chopping.

8. Though services can maintain state whenever there is a high volume of related requests and responses and responses need to sent in pieces. Maintaning state is not desired when trying to implement Service Oriented Architecture though.

9. As XML is verbose and takes up considerable size, solutions like binary-XML can be used to zip or compress the message. Both client and server should be able to access the compression technique.

10. Use message oriented middleware (MOM) to handle asynchronous communication and where sensitive data are transmitted. This is a good choice to achieve Reliable Messaging.

11. Data binding specific to a SOAP engine is switched off in case of Document –literal style web service. Custom binding mechanisms like castor, xmlbeans, JAXB, JaxMe can be used by applications to offload the job of marshalling and unmarshalling from SOAP engine and handle custom data types.

12. SOAP engines use parsing mechanisms internally. Parsing is an overhead and it can lead to performance issues. Axis 2.0 uses a new mechanism called AXIOM (AXis Object Model) which is a StAX-based, XML Infoset compliant object model which supports on-demand building of the object tree.

13. Use WS-Security for transmitting sensitive data. However, always secure part of message and not the entire message. Usage of HTTPS for transport level security is desired. SAML should be used for identity management.

14. Use a test harness tool like SOAPUI for testing the web services client by creating mock or simulated web services. Use TCP/IP monitor for tracing the SOAP messages.

15. XML security gateways and proxies can be used to prevent Denial of Service (DoS) attacks.

16. ESB or Enterprise Service Bus can be used when there is lot of integrating logic and activities like message routing, validation, enrichment, transformation, monitoring, logging and event management need to be deferred. ESB is the underlying infrastructure for implementing SOA. Canonical applications can be exposed as web services using adapters and current world ESBs are equipped with adapters for such applications.

17. Use UDDI-based registry to maintain a system of record, increase visibility of services and manage lifecycle and versioning of services.

18. Use a workflow language like BPEL to orchestrate services and provide Business Process Management (BPM). This is important for facilitating agility and hiding technical complexities.

19. Check if your web service is WS-I basic profile compliant and conforming to all the rules. http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

Posted in Web Services | Tagged: , | 1 Comment »

WSRR Installation Issues

Posted by Vivek on March 6, 2009

WSRR or Websphere Service Registry and Repository is IBM’s answer to a robust SOA Governance solution framework. Every complex product brings some issues along with it and when its an IBM product, it is obvious.

If you are installing WSRR 6.1, make sure you have followed the below mentioned steps:

1. Installed Websphere Application Server (WAS) 6.1.0.13 or later.  If not, first install Update Installer in WAS Installation Directory.

2. Install Websphere Application Server fix pack using Update Installer on top of existing Websphere Application Server installation.

3. Install IBM SDK SR6 using Update Installer from here

4. Install Oracle or DB2 database and create database schema.

5. Install Websphere Service Registry Repository

6. Deploy WSRR on WAS using “deploywizard” or “installall” batch/shell scripts (Located under WSRR_HOME/install directory).

To download Update Installer, interim fix and Fix Packs 13 for windows, Click Here

Note: Web Service feature pack is not required for WSRR. If you have already installed Web Services feature pack, please install interim fix and Fix Pack for Web Services feature pack before following step 3. (Not Recommended)

Chances are that deployment of WSRR ear on WAS may fail. In such cases, make sure that

1. you have correctly specified server and profile details of WAS on one of the deployement details screens.

2. If you are on database details screen, choose “Preload the database” option rather than “Reuse an existing database” option. If not, you may end up getting only configuration perpective of WSRR. Administrator and User perspective may not be visible. Though, you can go to Configuration –> Manage Configuration Profile –> Configuration Profiles from your WSRR Homepage, Select Load Configuration Profile, Browse to $REGISTRY_HOME/samples, select SamplesProfile.zip, select OK and Restart server.

3. If you have opted for Oracle database, make sure you have set Oracle_JDBC_Driver_Path. If not, go to WAS Administrative Console –> Environment –> Websphere variables. Set the value for Oracle_JDBC_Driver_Path and restart server.

Posted in SOA Governance | Tagged: , | Leave a Comment »