Checklist for developing a strategy for web services

In his book titled Loosely Coupled, Doug Kaye has offered a checklist for developing a strategy for web services. After going through it, I found it useful as a starting point for making road-map for SOA adoption. This checklist has got more than 80 items grouped into into four categories: Inventory, Project Requirements, Planning and Evangelism. You can find this checklist as a free chapter download (without giving out email address!) from the book web site.

QoS requirements for web services development project

Many a times a question comes up about which Quality-of-Service (QoS) requirements should be gathered for web services development project. Let me share my answer to this question.

QoS requirements are not so much different from the non-functional requirements that we gather for any typical software development project. Let me list them down with some explanation:

• Availability in terms of probability of service being available
• Accessibility in terms of probability of success in accessing the service
• Performance in terms of throughput (number of successful service requests made per given time period) and latency (aka response time)
• Reliability in terms of failures per give time period
• Security (this requires a detailed explanation as given below)

Security Requirements come as a top requirement for web services. I
have come across many people who believe that web services are
inherently insecure. It's far from true! With a release of WS-Security
specification from OASIS and subsequently release of Basic Security
Profile from WS-I should help eradicate this wrong perception. Now, gathering security requirements for web services is a tricky job. Everybody wants to have web services to be
as much secure as possible and no less. But then there are trade-offs
to be considered with other QoS requirements, particularly the
performance requirements. So it makes sense to ask for only essential
security requirements. Further the security requirements for web
services should be broken down into the following:

• Authentication
• Authorization
• Message Integrity
• Non-repudiation

A note should be made that all security requirements except
non-repudiation requirements can be met by using the WS-Security
specifications. If there are non-repudiation requirements then a
non-standard way will need to be adopted.

A good news is that service development per se need not take into account these QoS requirements. These QoS requirements can very well be externalized and can be handled independent of service implementation. However, if there are some very peculiar or critical QoS requirements then the high-level design of the service implementation needs to get influenced.

Any comments?

When to use REST and when to use SOAP

There are so many pages and blogs on REST vs SOAP that a person like me who wants to know which one to use where, simply gets confused. These blogs and pages talk more about pros and cons of REST and/or SOAP, while I believe every such thing has a place in a particular scenario. In other words, REST will be applicable (please note I am not saying better!) in some cases, while SOAP will be applicable in some other cases. Fortunately, I found this article by Sameer Tyagi, which gives good advice on when to use REST and when to use SOAP. Let me quickly outline my understanding of Sameer's article in this blog.

A RESTful design may be appropriate when

• Completely stateless web services are needed.
• A caching infrastructure can be leveraged.
• The requirement is for point-to-point integration. This means both service consumer and provider have mutual understanding of the context and content being passed.
• Limited bandwidth exists between service consumer and provider; e.g. having mobile device as a consumer.
  
• Front-end technologies such as AJAX and DWR are being used.

A SOAP-based design may be appropriate when

• A formal contract is needed for a service (to be provided as WSDL).
• Complex non-functional (aka QoS) requirements are present and need to be handled in a standardized way.
• Requirements for asynchronous service invocation are present.

Now this kind of information comes handy when a solution is to be proposed for a particular case.

WSDL Viewer

While surfing, I came across this web page that provides a fantastic XSL that translates the WSDL to a format, which can be read and understood by a human user. I really liked this tool!

Thanks Tomi Vanek for providing such wonderful tool!

Get it at http://tomi.vanek.sk/index.php?page=wsdl-viewer

Tradeoffs in web services design

While designing web services, we encounter many trade-offs. A good discussion of these trade-offs is provided in a report prepared by Web Services and Practices working group at National Information Standards Organization (NISO). This report, named Best Practices for Designing Web Services in the Library Context discusses following trade-offs:

• Complexity levels vs. expandability
• Amount of data returned levels vs. performance speed
• Audience levels vs. service interface size
• Performance levels vs. number of operations

The report also discusses different models involved in fully describing or documenting a web service interface and provides some useful best practices.

Open source software for web services frameworks

For one of our customers, I recently investigated availability of open source software for web services frameworks. I was amazed to see that not only there are many options but also there is a good amount of competition among them to prove to be the best option. Obviously, I am evaluating them on the basis of our customer requirements. I have short-listed following five options, which you may also consider if you need to evaluate and select an open source software for web services framework.

1. Apache Axis2: Currently available in its version 1.3, Apache Axis2 is complete rewrite of Apache Axis.

2. Apache CXF: A merger of XFire and IONA-backed Ciltrix, CXF has released its version 2.0 recently. This project is currently in incubation at Apache.

3. JBossWS: It is part of JBoss Application Server.

4. Metro: As part of GlassFish project, Metro is actually a reference implementation for JAX-WS. It was earlier known as JWSDP.

5. Spring Web Services: Developed by Spring community, Spring-WS is made for developing web services by using contract-first principle. As I am fan of this development principle, exploration of this software is very much on my agenda now. It has just released its version 1.0.

A good comparison among first four options and few more is available at http://wiki.apache.org/ws/StackComparison.