(Editor’s note: This is the second part of a continued series of transcriptions from a conversation secretly recorded at a party in San Francisco during JaveOne 2007 between Ted Neward and Adrian Trenaman on the SOAP/REST debate. Ted was just finishing up discussion of SOAP encoding when they were interrupted by a burly black-suited-and-sunglassed “G-man” mumbling “Continue or Cancel?”.) Read more »
by Scott Balmos
About a month ago, I wrote a blog entry here discussing stateful web services, and how EJB3 more or less removed the commonly used J2EE hack, in using the serialized EJB2.1 Stateful Session Bean Handle as a session token of sorts. I mentioned how JAX-WS added support for a WS-Addressing-based stateful SOAP endpoint - the first truly “automated” and SOAP-compliant manner of providing sessions in SOAP. Now… we have sample code! It really is dead-simple, a testament to the WSIT group (Project Tango), working between Sun and Microsoft to make JAX-WS and the Windows Communication Framework in .Net 3.0 play nicely.
First, the client code. This is run under JAX-WS 2.1.2 running in Glassfish v2 Beta 2. As part of the deployment, we won’t run wsgen to build the WSDL file or server artifacts, leaving that to deployment time auto-generation (all hail JEE 5). So, you can also run this example in WebLogic 10, if you updated the JAX-WS components in it to at least 2.1 (WL10 comes with JAX-WS 2.0 if I remember correctly). The JBoss crowd probably will work also under a JBoss 5 beta, as long as you use the JAX-WS libs. JBossWS will not work (at least not as pretty). Read more »
This time in San Francisco for the JavaOne 2007 conference, Adrian Trenneman deliberately tracked Ted Neward down at one of the innumerable “after-parties”–this one hosted by some company whose name sounded something like “oogle”–and started up another conversation, this time on the growing debate between “SOAP” and “Plain Old XML”, or “POX”. Once again, TheServerSide was able to capture the discussion, despite the best efforts of several large men in black suits and sunglasses who kept interrupting the early parts of the conversation with brusque challenges of “Continue or Cancel?”. Rumor has it these “G-Men” are part of a new multinational intelligence organization, but that’s another story for another day.
(Editor’s note: Again, as with the prior conversation, both men had consumed many of the available beverages of questionably moral character, and were still a touch irritated at the “G-Men” trying to display advertising in the background of their conversation. Readers unaccustomed to raucous debate are, again, forwarned.) Read more »
A lot of SOAP activity these days revolves around REST and Axis2, the latest Apache Web services engine. With this mini-guide, writer Brent Sheets gives you a view on a slew of valuable resources about this modular architecture supporting plug-in modules for easier implementation of existing, and future, Web services specifications.
Read the Apache Web Services Mini-Guide
TSS Interoperability Blog Correspondent George Lawton met with Mohammad Akif, Senior Architect, Microsoft, at JavaOne. The discussion centered on Akif’s take on WSIT and related phenomena. Akif said service-oriented architecture is finally taking hold. It used to be a small-scale fancy project within an organization that were involved, but now the industry is seeing wide-scale adoption. Read more »
By George Lawton, TSS Interop Blog Correspondent
SAN FRANCISCO - At the JavaOne Conference, Harold Carr, Lead Architect and Arun Gupta, Evangelist at Sun, gave a presentation showing how easy it was to integrate .NET 3.0 and Sun Glassfish applications using Web Services Interoperability Technology, code named Tango. They said that that these services are now baked into the new open source Glassfish application server, which can be downloaded off the Sun Website. The Tango features not only allow integration, but they enable transactions processing, which is secure, reliable, and trust based. Read more »
Arun Gupta asks JavaOne attendees to come on by if they are interested in learning how an Excel 2007 spreadsheet can invoke a reliable and secure Web service endpoint deployed on GlassFish .
TS-4865 (Takes Two to Tango - Java Web services and .NET interoperability), at JavaOne 2007 this week, will show and give you all the details. Here is a sneak peek of the scenario we are going to show in the talk. Read more »
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.
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.
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.
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.).