Simon Brown's Blog

JSP Tag Library for Web Services

A new JSR has been created that proposes to build a JSP Tag Library for Web Services...

A JSP tag library for Web Services is a happy union of the two technologies that will help JSP page authors integrate Web Services into their web applications with minimal effort and quick turnaround times. In addition to existing standards for both Web Services and JSP technologies, there is industry wide acceptance and widespread usage of both the technologies. All of these facts make a compelling case for creating a standard for this tag library.

While I think that standard tag libraries are great, I'm not convinced about the need to access web services directly from JSP pages. The existing JSP Standard Tag Library includes support for accessing data sources via JDBC and it's a widely accepted view that you'd only do this for small/simple web applications. Accessing the database from your JSPs will eventually lead to complex applications that are hard to understand and maintain. In addition to this, your JSPs are not isolated from changes to the database schema and you have few places to go if you come up against performance problems later on. Moving data access further back in the architecture provides more scope for aspects such as reuse, maintainability, caching and so on. I think that these points are equally valid to a standard taglib that accesses web services.

Of course, like the JSTL database tags, people will use them. Not everybody has the luxury of being able to design, influence or modify the architecture of an application and lots of people just want to build a system that works. There's nothing wrong with this and standardizing on a way to access web services from JSP can only be a good thing in these situations. So, rather than just bile the idea, I'd like to offer some suggestions, perhaps for a future version of the JSR.

• Caching : For performance reasons it would be nice if you could specify that the results from a particular web service are cacheable and specify the timeout of those cached results. The temperature service in the JSR is a good example. Specifying, through an attribute or an enclosing tag, that the results of this web service can be cached for a few minutes could substantially reduce the number of calls to the web service, increasing performance and scalability. Of course, developers could wrap the web service taglib with something like OSCache, but this adds complexity into simple solutions.
• Other protocols : I know that the taglib is aimed at accessing standard web services (i.e. SOAP, WSDL, etc), but there could be some scope here to build something that provides a generic mechanism for accessing other types of "web services" - there are a lot of people using lightweight XML-RPC and REST approaches for remote APIs and system integration.

If a standard web services taglib is available, people will use it. I guess that this is our chance to have an input into its future.

Comments

• 
  I appreciate the concern about this library, but can't help feeling this is a natural reaction to the over-engineering that often goes on in Java enterprise applications.

  Personally, I like the idea of these tags. Sure, it won't scale to large apps but it does make JSP more competitive with scripting-style approaches where a few lines of code can achieve a lot of functionality.

  Ian.
  

  Posted by: ifairman on January 14, 2005 at 03:42 AM

• I agree with Simon on this one. This functionality shouldn't be made available at this level. Also, if you are implementing a small application that would benefit from a scripting style approach, why not just use Php.

  Posted by: jgchristopher on January 15, 2005 at 09:10 AM

• If you can define a JSP fragment/tag that encapsulates those queries in a reusable manner, then I don't necessarily see how much different that is from doing so in Controller/Model layers.br/br/ I think the underlying issues is that developers should be able to seperate the competancies of their application, what requirements serve the view and what requirements serve the business model and need to be testable. For those requirements that purely serve the view, then I suggest pursuing tag-based technologies or components from JSF-- either I create an URI-bound action to grab data in an exclusive manner or a tag that can be used in conjuction with other requirements (e.g. ListEmployees.do versus ListEmployeesTag).

  Posted by: jhook on January 15, 2005 at 10:34 AM

• I think taglib could be useful. Do you know how many times SOAP tag was downloaded from our JSP suite
  http://www.servletsuite.com/jsp.htm ?

  Posted by: dnamiot on January 15, 2005 at 02:47 PM

• No, we don't. Could you reveal that info?

  -- Felipe
  

  Posted by: felipeal on January 16, 2005 at 01:05 PM

• I've been hitting the job market bricks lately, along with reading all the stuff in Dr. Dobbs, etc, and it doesn't matter whether its Java or MickeySoft, it seems corps like web services, and anything that will make it easier to plug and play with them is most probably a good thing. Its not so much a matter if we've GOT to have the helper tags, its more a matter of why should those C# wussies get all the easy stuff. :)
  

  Posted by: mezmo on January 16, 2005 at 03:31 PM

• The sad thing is that on one hand you will have JSP tags to easily query web services while it seems as if you have to jump through hoops on the Java side to do anything with web services.

  Posted by: jhook on January 16, 2005 at 03:47 PM

• I'd have to agree with jhook. The focus of the effort should be on developing an easier API and then write a tag library to complement that. Once that's done people can hack something up using the tags and then bring it back into Java when they need to without having to worry too much.

  Posted by: enygma on January 17, 2005 at 02:20 AM

This work is licensed under a Creative Commons License.