Some Web Services Dos and Don'ts





Some Web Services Dos and Don'ts

There is a common set of emotions that go along with adopting any new technology. First, when you begin to hear the buzz about a technology, you start to think that it might be useful in solving your particular problems, and feel positively inclined toward it. As you learn more, your excitement grows—perhaps a short proof-of-concept is successful and leads you to jump in with both feet and adopt the new technology for a big new project. Then, the reality of the state of the technology begins to set in, and you start to find the limitations of the new technology. At this point, you might be able to muddle through and make the project successful despite the technology's limitations, or the project may crash around you amid a shattering of lost hopes and dreams. The old adage "all panaceas become poison" applies to most new technologies, and it applies no less to Web services.

In the past two or three years since Web services have started to be used in practical applications, a number of basic dos and don'ts have emerged about when Web services are practical, and when they are not. Next, we'll examine some of these basic principles, and discuss some situations where disregarding them have made projects go awry.

Principle: Try not to use XML-based Web services between the layers of a logical application.

Web services function best where they complement other J2EE technologies, not replace them. For instance, a wonderful way to use Web services is when connecting from an application client running on the global Internet to business logic written in EJBs inside WAS. Here you get a nice, clean separation of communication between the controller and domain layers of your application. This is the same place in which you would use EJBs (see Chapter 22) and so, if you consider Web services as another object distribution mechanism, then you can see why this would be appropriate. SOAP over HTTP can work in places where RMI over IIOP can't (as we saw in Chapter 22), allowing the XML-based Web services to complement the existing EJBs.

However, where people often go wrong with this is to assume that if this works between one pair of layers, it would work well between another. For instance, a common antipattern that we've seen far too often is a design where a persistence layer is wrapped inside an XML API and then placed in a process separate from the business logic that needs to invoke the persistence layer. In versions of this design, we've seen people actually serialize Java objects into XML, send them over the network, deserialize them, perform a database query with the objects thus sent in as an argument, convert the database result set to XML, then send the result set back across the network, only to be converted into Java objects, and, finally, operated on. There are two major problems with this approach:

  • As we discussed in the chapters on CMP and BMP design, persistent objects should always remain local to the business object that operates on them. The overhead of serialization and deserialization is something you want to avoid whenever possible.

  • There is not yet a workable, fully implemented transaction specification for Web services. In EJBs with RMI-IIOP you have the option of including persistence operations in an outer transaction scope if you use entity beans or session beans with mapper objects if you so choose. If you introduce a layer of Web services between the persistent objects and the business objects operating on them, you lose that ability.

In general, XML Web services aren't appropriate for fine-grained interactions, even less so than RMI-IIOP. For instance, don't put it between the view layer and the controller layer of an application. The overhead of the parsing/XML generation and the garbage generation overhead will kill the performance of your overall application.

Principle: Be very careful when using Web services between application servers

In many ways, interoperability between systems is the raison d'etre of Web services. So, if you're connecting to a system written using Microsoft .NET, the use of Web services is almost a given. While you could use other mechanisms like WAS's COM support, the best solution for interoperability going forward for both the Microsoft and IBM platforms is Web services.

Sometimes using Web Services makes sense as when connecting disparate Java application servers from different vendors, but this is a less common occurrence. It is possible to connect to EJBs written in WebSphere from a JBoss or Weblogic server by using the WebSphere thin application client described in Chapter 22. This would be a much better performing solution than one using HTTP and SOAP-based Web services.

On the other hand, a more common occurrence is when you want asynchronous invocation of business logic written either in another application server or in some sort of legacy server. In this case, sending XML over JMS makes a lot of sense, and if you wrap your document-oriented XML in a SOAP envelope it makes even more sense; you can take advantage of the header structure of SOAP and even possibly gain some out-of-the box features like WS-security support.


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows