Url-pattern differences between OAS and WebSphere
Today I was having a problem with my for a particular working in OAS 10g-9.0.4, but not on WebSphere-5.1. After poking around a bit, it ends up that OAS, OC4J and Tomcat are forgiving/ feature rich when sticking to the Servlet spec and WAS (at least 5.1) is pretty stringent.
The Servlet specification's web.xml DTD provides the to define a particular pattern to match on for particular resources. Usually you just use this for to map a Servlet class to a particular URL and to map a Filter class to a particular URL. You can also use it in security constraints, but I haven't used web.xml for security in many years.
The javax.servlet.Filter was not processing for my STRUTS actions. This was strange as everything was working fine on developers' local workstations and our test environments. Of course the devs use OC4J and the test environments run OAS, so there was some differences that could lead to this problem.
The pattern a developer is trying to use is: "/path/*.do". You would think that the app server would apply the mapped filter to any http request ending with .do in the /path/ path. OAS, Tomcat and OC4J think this as well. However, WAS sees this as not matching the servlet spec and checks for the literal http request "/path/*.do".
It looks like section 11.2 of the Servlet 2.3 spec has the following to say about defining mappings:
- A string beginning with a '/' character and ending with a '/*' postfix is used
for path mapping.
- A string beginning with a '*.' prefix is used as an extension mapping.
- A string containing only the '/' character indicates the "default" servlet of the
application. In this case the servlet path is the request URI minus the context
path and the path info is null.
- All other strings are used for exact matches only.
As it is currently written, an architect has to plan the structure of his application depending on what servlet and request filters he expects to use. This is an unpleasant limitation as the implementation affects the structure and is hard to change several years into a project.
I'm not sure if OAS and Tomcat specifically extended support of the spec, or they were just too lazy to use * for anything other than a string wild card match (a good thing).
So WebSphere is adhering to the letter of the law, but not the spirit. I hope that WAS6 or WAS7 make this change.
I will add a comment to the new JSR for Servlet 2.6 when it is created (jsr154 for 2.4/2.5 just wrapped up in May), as I think this is a bit of useful logic that should be in every servlet container.
Web Service Client Programs
Since my company is rolling out all our web services across our SOA stack I wanted an easy way to test web services using SOAP over HTTP. More specifically, I wanted a tool easy enough to show biz/ analyst people how to execute web services.
My requirements were pretty simple, given a WSDL file, present me with a UI to enter all the fields, then submit the request and show me the response in a relatively pretty view.
I guessed this would be really simple to find as executing web services is a pretty common need. I googled around for a suitable client program and didn't find much. First I found .Net WebServiceStudio
. It presents a basic UI, but given a WSDL url or file it will parse it and give you an input pane for all the request doc fields. It even does basic validation and will give you drop downs if your WSDL schema defines enumerations. This seemed cool, but because .Net sends a Byte Order Mark/ BOM
on its UTF8 request docs, java blows up. Our Service Runtime Engine is implemented in Java so it uses the Java xml libs. This is one of the instances where Microsoft is right and Sun is wrong. Sun decided not to fix this defect in the JRE
because it might mess up backwards compatibility. Hooray Sun! As soon as Java is open source this will get fixed pretty quickly.
Since all the MS consoles were ruled out, I kept googling. Eclipse has some good plug-ins like the Web Services Console Plugin
and a ton of others
that give this functionality. But when I tried to show how to set up Eclipse and plugins to our analysts that didn't work out so well.
There's also a decent plugin
for my preferred Java IDE, IntelliJ, but I can't hand that over to analysts because they don't have IntelliJ licenses.
If you are rich and/or are employed by a rich company you can use Progress Software's Stylus Studio
($150-800 per license) or Altova's XmlSpy
In the end I found Integration Central's Quasar
a best fit mainly because it's cheap (only $90) and simple. The UI is clunky and leaves much to be desired, but since the only feature I want is to submit SOAP document style requests over HTTP, it is good enough for now. Our vendor has committed to adding a work around so MS-based WS clients can invoke our services and when that happens we will switch over to Microsoft's tool kits.
But I really expect a decent, Open Source web service client tool to come out in Java or Python or something any day now. It probably doesn't exist now because nerdy OS guys are probably content to use Eclipse/IntelliJ plugins. One more item I've added to my handy dandy google spreadsheet
of software projects to write.
PS- I find it odd that google spreadsheets doesn't have a public URL to view as HTML or something. This would be pretty useful.