Stateful SOAP and beans

By Scott Balmos
[posted by Jack Vaughan]
Stateful SOAP, EJB3, and SFSB sessions… oh my! A thorny issue with SOAP, with the requisite multiple implementations, has been how to track client sessions. Put more simply, the SOAP equivalent of HTTP sessions… How do you turn an inherently stateless protocol into a stateful one? Read more »

To invoke a WSIT endpoint from WCF

You have built a Web service using Web Services Interoperability Technology  [WSIT], or “Tango,”   using a plug-in in NetBeans 5.5.1 and deploying on GlassFish v2. How easy is it to write to that protocol from the Visual Studio tool kit? Read more »

The Complete Contract-First or Code-First Design Files

Due to popular demand, the entire first season of Contract-First or Code-First Design is now available on a single Web page. You will remember: While in London for a conference, Ted Neward ran into Adrian Trenaman, a fellow Web services geek who’s been working with Web services for some years now …. Read more »

Microsoft interop extensions and Sun GlassFish v.2

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 »

WS-I releases basic security profile

The Web Services Interoperability Organization last month released its Basic Security Profile. Release of the 1.0 version followed a four-month comment period on the final draft.

Read more »

Contract-First or Code-First Design - Part 5

This is the fifth and final of a multi-part series on Web services, in which our hero Ted asserts: “You cannot try to force XML into a “type system” through XSD!” The dynamic duo discusses C++ and its adaptation to Contract-First methods. Ted ends with a paean to messaging.

Contract-First or Code-First Design - Part 4

In the most recent episode of Contract-First or Code-First, Ted and Ade were blithely discussing The Single Source of Truth and The One True Schema  when the London Morality Police descended on the bar and tried to arrest Ted. As we return to our story, Adrian is outlining Reason Three for Contracting First..

Contract-First or Code-First Design - Part 3

In the third of a multi-part series of transcriptions of a conversation between Adrian Trenaman and Ted Neward on Web services in general and code-first/contract-first practices in particular, Adrian asserts that it’s not just changes in the service endpoint interface that can lead to a compatibility issue: a change in any class or interface used by the service interface may lead to an incompatibility issue.

Contract-First or Code-First Design – Part 2

Editor’s note: This is the second part of a continued series of transcriptions from a conversation secretly recorded in a bar in London between Ted Neward and Adrian Trenaman on the code-first/contract-first debate. Adrian was about to launch into the first of four reasons he prefers WSDL and contract-first when a waitress interrupted them to bring more drinks.

(Click to read Part1 of Contract-First or Code-First Design – A Conversation)

Ted: Ahh, good stuff. OK, you said you had four reasons you prefer the evils of WSDL to something else.

Adrian: (Laughter) Evils?

Ted: Toh-may-toh, toh-mah-toh.

Adrian: OK, first: Code-first interfaces may not be well suite for the demands of remote traffic. It’s generally accepted that not all procedures or methods should be made remote: if you’re going to take on the overhead of a network call then you should maximize the amount of data transmitted with each call. Current coding practices often lead to many fine grained methods (for example, get() and set() methods on Java beans) that are unsuitable for remote access. Early Java-to-WSDL tools generated WSDL on a class/interface level, not allowing you to distinguish between those methods you wanted to expose remotely through the WSDL contract and those you want to remain outside of the contract. Newer tooling using JAX-WS and .NET does allow you to specify remoting on a per-method basis, which alleviates this problem somewhat. However, this tooling relies on network-savvy developers and designers - are they always going to be around to make sure someone not so clued in starts adding poorly designed operations to the interface?

Ted: No argument on the substance of your argument: making a network traversal has to be considered one of the most expensive things a developer can force the machine to do. And I agree, lots of developers don’t realize that the cost of one network RPC call can be up to four or five orders of magnitude–

Adrian: Wait, is that ten thousand or a hundred thousand times? I forget.

Ted: Yeah, it’s hard for people to comprehend numbers that big, so I did the math once and tried to put it into real-world terms. If we consider a standard,  non-remoted method call to be equivalent to your morning commute of twenty minutes, then a network call, Web service or otherwise, is roughly the same amount of time as what we’d need, using today’s technology, to go to Pluto, or roughly fourteen years.

Adrian: (Garbled response; detailed analysis suggests a reaction suspiciously like beer coming out of his nose.)

Ted: Yep. And to expect that “newbie” developers are going to have an appreciation for the costs of network calls is definitely a stretch. But here’s my point: What are those newbie developers doing designing remote interfaces in the first place? The same problem exists with CORBA, RMI, EJB, or any other remoting technology, not with Web services in of themselves. In fact, this is probably my biggest concern over POJO-based approaches being applied to communication technologies, that what’s good for POJOs isn’t good for distribution. What’s worse, the WSDL-based approach doesn’t help this at all, particularly given that a lot of devs are designing their WSDL services to be just as “chatty” as they’re going their RMI or EJB or .NET Remoting or any other RPC-based tools. That’s not an issue of technology, that’s an issue of education and experience.

(Editor’s note: At this point in the conversation, both launched into an extended discussion of the evils of clueless programmers and their tendencies to be shunted off into less dangerous places, such as Upper Management.).

Read Part1 of Contract-First or Code-First Design – A Conversation

Contract-First or Code-First Design - Part 1

While in London for a conference, Ted Neward ran into Adrian Trenaman, a fellow Web services geek who’s been working with Web services for some years now, including having written several training courses on several different Java WS-* implementations. Naturally, their conversation swung from the usual “How are you enjoying the conference?” small talk to the more interesting - and heated - discussion of building Web services in general. Fortunately, unknown to either of them, a small digital recorder was capturing their conversation, and in an exclusive, highly-sensitive deal involving no fewer than three countries and two intelligence agencies whose name we’re not even allowed to think about, much less disclose, the transcript of that conversation is now being made public through TheServerSide Interoperability Blog.

[Editor’s note: At this point, both had consumed several beverages of questionably moral character - readers unaccustomed to raucous debate are forewarned.]

Adrian: So I heard you gave a talk on Java/.NET interop…

Ted: Yep.

Adrian: … and that you said something along the lines of “WSDL sucks eggs”.

Ted: (Laughs) I think my actual words were something along the lines of “Learning WSDL is an exercise best reserved for the residents of the Fifth Circle of Hell” or something like that.

Adrian: You’re not a fan of contract-first?

Ted: You are?

Adrian: It’s not that bad.

Ted: Dude, them’s fightin’ words!

Adrian: (Laughter) Seriously, you don’t care for WSDL?

Ted: Nope. But you’re welcome to try to convince me otherwise, if you want.

Adrian: Well, it just seems to me that learning WSDL and XSD can go a long way in improving the quality of the Web services experience.

Ted: OK, opening arguments. Begin.

Adrian: (Laughter) OK, here goes. I used to think that WSDL was pretty ugly; it is certainly verbose and largely non-intuitive to the beginner. When I started with web services using XMLBus in 2001, the support for code-first programming was hugely attractive: you could take a Java class, run a simple “java-to-WSDL” utility, and an appropriate WSDL contract was generated. Today similar approaches exist for JAX-RPC toolkits like Axis, and JAX-WS toolkits, such as Celtix. These approaches allow developers to swiftly web-service-enable their existing code, with little or no need for WSDL design, and seem hugely attractive. Why would a developer want to venture into the “Fifth Circle of Hell” when they just don’t have to? I think the answer to this lies in the context of the service being designed. If this a tactical, short-lived service, then the code-first approach may be appropriate. However, if this service is to be long-lived within an enterprise, and engineered for reuse, then you may want to consider the following reasons to adopt a WSDL first approach.

Ted: Well, you’re not saying anything I don’t disagree with so far: context always matters, no matter the technology. And frankly, I’m not advocating the “code-first” approach, either; I believe in something hybridized between the two, sort of a “code-first/contract-aware” approach. But why in Heaven’s name would you sign developers up to write 50 lines of obtuse XML that can’t be verified until runtime just to specify a contract that can be more succinctly expressed in four lines of Java or C#?

Adrian: Four reasons.

Ted: Cool. You put ‘em up, I’ll knock ‘em down, one at a time.

Adrian: You’ll TRY, you mean. (Laughter) (Editor’s note: There is a pause here in the conversation as the waitress brings more beer and our agent surreptitiously turns up the microphone gain on the recorder cleverly disguised as a floral arrangement on the table.)  

Read Part 2 of Contract-First or Code-First Design