Sun’s Glassfish technology will get featured play at the upcoming JavaOne. In fact, the company plans a CommuityOne day that will highlight its open-source efforts. That includes GlassFish. Read more »

Written by Scott Balmos [Posted by Jack Vaughan] I’ve got to admit, Visual Studio 2005 is a nice IDE. But when it comes to working with complex SOAP-based applications which have multiple endpoints and shared core, it can be a downright pain. I’m specifically referring to the Web References system, which transparently manages the annoyance of generating type stub and proxy classes from a WSDL file. It is, unfortunately, another classic case of Microsoft’s thought process behind trying to help developers work more efficiently - the common cases are very easy, but the hard things are very hard.

When it comes to Web Services, more and more systems are becoming increasingly complex. Many of them offer multiple endpoints - commonly one per major sub-application - while sharing a common core endpoint for initial authentication, session management, etc. Likewise, these endpoints share a common set of core datatypes, again usually a User, Session, and other such types. But trying to use these complex endpoints with Visual Studio is a downright pain. The Web References function insists on creating separate .Net namespaces for each different endpoint, even if the WSDL files for the two endpoints share a common XSD file that defines the shared core datatypes. Consequently, .Net refuses to acknowledge that a User or Session object retrieved from the core authentication endpoint really is the same User object that is supposed to be passed as a parameter in the billing, or personnel management, or other such sub-application endpoint.

No true explanation, nor any true answer to this dilemma has been given. The best I’ve seen are some people succumbing to the pain of manually changing the namespaces around in the auto-generated stub files. But that fix is short-lived, as the stub files are regenerated (separate namespaces and all) the next time the Web Reference is updated - a major pain for early-access developers to a web service whose WSDL file is still possibly in flux.

I don’t know about you, but I tend to see this as more and more of a thorn in the side of Visual Studio (and, by inference, .Net) developers as more complex SOAP services are built. For as much as Microsoft is trumpeting XML this and Web Services that, to believe that the Visual Studio and .Net groups didn’t seriously consider the use case of a complex service having multiple service endpoints is frustrating at best.

As I constantly continue building my one major JEE 5-based system (12 sub-applications and SOAP endpoints, with probably over 400 SOAP methods defined across those endpoints), and writing test SOAP clients in C#, I know I’ll be constantly bitten hard by this oversight. I’ll keep you updated if I find any more permanent answer, and let me know if you know of anything better.

I also, of course, welcome any vague ideas you may have for future blog entries. And I am not limited to SOAP/XML only, or specifically .Net and J2EE interoperability. In the coming weeks, I’ll be commenting on using J2EE systems with PHP, Ruby, and various other systems.

I’ll close off my blog entry with one of my favorite, and most poignant, lines from The Red Green Show (for you Canadians and Americans that watch PBS): “Remember, I’m pullin’ for ya… We’re all in this together”.