Michael Nascimento Santos's Blog

Web Services and XML Archives

Stop the hype about webservices!

I know, I have never been really aggressive in any of my posts. The problem is that, even though there are some wise people - I am not wise, I am just reasonable - telling people they are doing bad things, they keep on doing it. I ought to speak out, then. I have no choice. I can't see people doing something so irrational and still remain silently. Sorry folks, if this entry offends you, but this time it is necessary. It is for your own good. It's like taking medicine that tastes horrible; you don't like it, but it is for your own good.

So, what are webservices for? No, I am _not_ talking about technical definitions here. The real question is: what are webservices meant to be used for? That's hard to answer. So, I'll explain to you what most are missing by answering the simpler question, in my opinion: what are webservices not meant for? Let's go for a couple of examples:

• Webservices are generally not the right technology for integrating two systems written in Java. Yep, that is a fact. If that is what you are using webservices for, you probably should forget about it. It is very likely you are just wasting time: CPU time and development time; you are also wasting network bandwidth. Why do you insist on using webservices for that? If two people can speak English fluently but are very bad at Japanese, so bad that if they see anything in Japanese they have to translate it to English word by word in order to understand it and if this process takes a considerable amount of time, do you really think they should talk in Japanese, even knowing they will never improve their ability to speak in Japanese by doing so? It may surprise you that most people using web services are, in effect, doing just this double translation every day. If you are one of those, please, explain it to me. I don't get it. So, maybe you intend to keep your systems loosely coupled. I understand that. But let me ask you some questions:
  1. Should they be loosely coupled in first place? Sometimes two systems are so tightly coupled that they should be just one system, to begin with. This usually happens in big companies, where political reasons force two groups to buy two solutions from two different vendors to solve two parts of the same indivisible problem that cannot be addressed separately. A sad reality, though.
  2. Doesn't plain old RMI solve your problem? Think about it and tell me why it does not. If you come up with a good answer that is not "RMI limits me to using Java" and that cannot be applied to webservices, maybe you have a point.
• Webservices are generally not the right technology for integrating two systems for which there are better forms of integration. I am totally in favour of maintainability. I am not telling you to use plain sockets for anything not extremely simple. Have you ever heard of RMI/IIOP? J2EE containers support it; so, you have intrinsic support for CORBA in J2EE. Generally, the "other side" also supports it. It has been there for a very long time, its implementations are very stable, its a binary protocol. Why not using CORBA? Just because it isn't hype?

In my own experience - and what my friends have been telling me just proves me I am not wrong -, XML processing takes from 25% to 95% of the total processing time for most usages people are making of it. It is perfectly ok to use XML for configuration; it is generally parsed while your application is starting up, so, there is no real overhead to the end user if it's correctly implemented. But people are using XML - not just webservices - for a lot of reasons; they are using it for generating HTML when JSPs, Velocity or whatever would be faster and simpler by far. Then, they say: "it is easier, because designers don't have to deal with Java". Is it really a good reason? Let me see: you have to convert all your objects to XML - a slow marshalling operation, in most cases -, then someone has to write XSL - if it is the designer who writes it, I am sure s/he would get JSP, JSTL and Velocity; if it is the developer, s/he has to constantly rewrite it as page design/flow changes - and a big bloated XSLT processor has to run - don't tell me that just because now you can compile xsl it is better than plain old Java code. Are there any advantages if you are using Java in both ends? Don't tell me about future uses; future uses may require overhead. I am talking about the system you are writing right now.

There are some situations where using webservices might be wise; if you are integrating with .NET, they might be a good choice - note that they might; it does not automatically mean they are the only technology for the job. There are some other uses, which I am not going to talk about here - as I said, this post is about when not to use webservices. There are some binary formats for webservices, but as far as I could use them and heard people talking about them, the only impression I get is they are still slower than RMI. Webservices might be a good choice for situations where you don't know in what language your clients will be written. Even in such cases, it won't hurt if you expose some plain old interfaces and maybe RMI interfaces too. In fact, a lot of systems will perform better. No, there is no maintainance nightmare here because RMI interfaces and WSDL should be automatically generated. Period.

If you are still concerned about loosely coupling, think: What really makes systems loosely coupled? Interfaces. That is it. Integrate your systems using interfaces and provide them for whomever wants to call your code. If you are using EJBs, use local interfaces until something forces you to use remote interfaces. Use business delegates to access them and make each of their methods throw a CommunicationException and have a factory for building their instances. Why? If your backend implementation uses local interfaces, CommunicationExceptions will never be thrown, but your code will have to handle them. When - if necessary - you change to remote calls, your system will keep working, because it was ready for handling those exceptions! Then, if you have to use webservices because someone decided your backend should be written in .NET, you are still safe! Isn't that great? I'll give you one more tip: if you design your systems using naming conventions and standards, you may be able to implement all your factories and business delegates using dynamic proxies! It'll take less than 100 lines of code and your architecture will be prepared for future changes!

To sum up, If you are going to use webservices, think before doing so; it is very likely there are better options.

JXPath to rescue!

Querying a database is no big deal. SQL has been around for a long time and has become the de facto standard for doing that. So has JDBC, even though nowadays it is being used more as the foundation of other solutions and frameworks. But what you do when you have to query objects? Most people wouldn't be able to answer it, really. Three more common ways of querying your objects in Java are custom indexing, OQL and JXPath. This entry is specifically about JXPath.

Jakarta Commons JXPath basically defines a simple XPath interpreter that can be applied to general object graphs: POJOs, Maps, Servlet contexts, DOMs and more. XPath is a W3C standard originally conceived for navigating XML nodes, but can be easily applied to Java.

Let's see it in action. To ilustrate its use and advantages, we will work with the classical Order problem (Order, LineItem and Product). Let's assume all Orders are stored in a Collection which is a property of our OrderHistory object. What if we wanted to get all the Orders which contained more than 5 CDs? In plain Java:

Collection selectedOrders = new ArrayList();
Order order;
LineItem item;

for (Iterator orders = orderHistory.getOrders().iterator(); orders.hasNext(); ) {
    order = (Order)orders.next();

    for (final Iterator items = order.getLineItems().iterator(); items.hasNext(); ) {
      item = (LineItem)items.next();

      if (item.getQuantity() > 5 && item.getProduct().getType().getName().equals("CD")) {
         selectedOrders.add(order);
      }
    }
}

return selectedOrders.iterator();

To avoid being unfair, using 1.5 sintax:

Collection selectedOrders = new ArrayList();

for (Order order : orderHistory.getOrders()) {
    for (LineItem item : order.getLineItems()) {
      if (item.getQuantity() > 5 && item.getProduct().getType().getName().equals("CD")) {
         selectedOrders.add(order);
      }
    }
}

return selectedOrders.iterator();

With JXPath:

JXPathContext history = JXPathContext.newContext(orderHistory);

return history.iterate("/orders[lineItems[quantity = 5 and product/type/name = 'CD']]");

That is it. As simple as that. JXPath becomes more valuable as your queries become more complex, but I am not going to show an example here.

Someone might ask: hey, but when I would like to manipulate objects in memory? There are a lot of occasions, actually. One very common is when you have a small application that needs to persist a small amount of data. If you combine Prevayler - an option to databases, as it keeps everything in memory and performs persistence through serialization and guarantees data integrity - and JXPath, you have a very fast solution with fewer lines of code. Consider using it when you have the chance.

As a final note, JXPath has many powerful features, as compiled expressions and variables - similar to PreparedStatements -, pointer, and many more, but you can find more about these by yourself. Go to the above link, download and start using it. The User Manual in the docs is probably the best one for a Apache Project and is highly recommended reading. Try it as soon as you can: you may become addicted to it...

This work is licensed under a Creative Commons License.