J2EE Specs Seek To Align with Non-Java World

As IDN reported earlier, the final J2EE 1.4 spec will be tabled to help developers using SOAP, WSDL and XML make sure their code runs across Java, .Net and Windows/Unix. But, the longer-term impacts for the Java/J2EE developer may reach wider than you might think, and open the Java community to a wide array of not-Java-only technologies. Read IDN's interview with a key Java exec.

Tags: J2EE, Interoperability, WS-I, Windows, Java, Web Services, Basic Profile,

As reported earlier this month, the release of the final J2EE 1.4 specification document will be delayed by several months to include the WS-I's (Web Services Interoperability Organization's) Basic Profile. The move will help ensure developers that when they build to SOAP, WSDL and XML specs, their work will interoperate across Java, .Net and Windows/Unix platforms.

One key take-away from the decison to delay release of the final J2EE 1.4 spec until summer (originally slated for release this month) is this: "Interoperability" with non-Java technologies will grow in importance, Ralph Galantine, group marketing manager for Java Web services at Sun told IDN.

Instead of just caring about portability among J2EE platforms from different vendors, the JCP will now care much more about J2EE's ability to interoperate with non-Java technologies -- notably Microsoft's Windows clients and servers and .Net, he said.

For more in-depth perspective on the near-term process for J2EE 1.4 release, and how the group will move forward, read the IDN interview below.

The IDN interview
Ralph Galantine, Group Marketing Manager
Java Web Services, Sun Microsystems

IDN: The last time we spoke to Sun execs involved in the JCP (Java Community Process) last November, they said it was a bit too late to delay the J2EE 1.4 specification to bring in formal web services work from the WS-I. What's changed in the last two months?

Galantine: The J2EE 1.4 specifications are proposed in final draft, and it's definitely late in the day for a change of this kind. But, because of the importance to the industry of interoperability, we really wanted to deliver interoperability. And, to especially make sure there's no conflict between what's required in J2EE 1.4 and what's in the WS-I Basic Profile, we thought that even though it was late in the day, it was important enough to the industry.

IDN: Who made the decision to delay? Was this simply a Sun decision, or open to the JCP (Java Community Process) members?

Galantine: Primarily, this was done by the "Expert Group" for J2EE 1.4 in the JCP, which includes the vendors who develop J2EE application servers. Many of those companies represented in the expert group are also members of WS-I. So, we very specifically put the question "Is WS-I Basic Profile something that is extremely important for you to support -- and would it be worth a delay in the J2EE 1.4 specification?"

And the answer that came back was pretty overwhelmingly: "Yes, it would. It's something we intend to support in our product, and it would be worth a delay."

IDN: Who suggested that the state of J2EE 1.4 interoperability needed to be revisited?

Galantine: Well, there was a revisiting in Sun joining the WS-I, so that was sort of a repositioning of Sun's position. Then, as we [Sun] learned more about what was going on, and also learned more about what our partners were intending to do with J2EE [1.4] products and WS-I profile, it seemed like it made sense to us. And then there was Sun putting the question to partners: "Does this make sense to you?" I think the basic assumption on everybody's part was that it is late in the game -- in the development cycle where we are. You know, people didn't want to ask.

IDN: But, for all the inconvenience it may cause, it does seem that the JCP and the WS-I were only within weeks of totally lining up?

Galantine: It would have been unfortunate if we hadn't done this, because there would have been the potential for conflict.

IDN: Let's talk about the effects of this decision on the J2EE timetable. First off, as of now, there's a beta J2EE 1.4 available. Will that continue to be available for download?

Galantine: The J2EE 1.4 beta is out, and we can still get a lot of useful info out of it, so it's still useful for people to use it. In J2EE, one of the key things is really the APIs, and the WS-I standards don't represent an API change. So, the beta out there is still a useful thing for developers, but people can't expect the same level of interoperability out of the beta that they should expect in the final products.

IDN: Will it be updated beta?
Galantine: We don't plan to have a second beta because the APIs aren't changing in a big way. What we will do is some basic interoperability testing around the [WS-I] Basic Profile through the WS-I.

IDN: FCS (First Customer Ship) will not occur until after all tests are completed. That had been scheduled for this quarter, when there were some 25,000 tests for meeting compliance with the J2EE 1.4 specification. Does this decision change the number or scope of the tests required?

Galantine: I don't think the number of tests significantly change. The scope of the APIs doesn't change. What changes is the specific details of the implementations.

IDN: What would you advise the developer community to look for to make sure they're adopting technologies that conform to your vision of interoperability?

Galantine: On the Java side, all they need to look for is J2EE 1.4 -- that's one of the reasons for this announcement. And it has to be WS-Basic Profile if you want that interoperability. The WS-I Base Profile is designed to be something that can be completely in J2EE 1.4.

IDN: What will be the impact of these changes on Java developers? Are there signs they should keep watch for?

Galantine: J2EE is very strong on the server side. You'll often see J2EE in the server area, and you'll see Windows in the client and in other specific areas, and so the interoperability of making those work together has always been what people have been concerned about. So this announcement ensures a way for that Windows client and Windows area to interoperate well with J2EE on the server side.

IDN: What about the attention to the interoperable client in the base J2EE spec? Early on, Java developers had difficulty getting SOAP tools from the Java vendors and had to go to Microsoft for that support. What do you see about the Java community's interoperability support for Windows and other clients?

Galantine: The interoperability through WS-I gives us an easier way of working with the Windows client -- a particular client that's important in a lot of environments. We've tried to do a number of things to get interoperability there, and a number of things from third parties, but I think in being able to work with Microsoft and the WS-I, we can get a really good interface to that Microsoft client.

IDN: Are you expecting any specific improvements in your efforts to achieve interoperability with Windows based on this decision to support the WS-I Basic Profile?

Galantine: Yes, what we're expecting to happen -- and the commitment Microsoft has made in being part of WS-I -- is that Microsoft will cooperate on interoperability, and they'll participate in tasks -- and if something is broken in Windows that makes it not interoperate, they'll fix it.

IDN: What's entailed in scoping any new tests that might be required in J2EE 1.4?

Galantine: Tests are always drawn from the J2EE specification. So, the first process is looking at the WS-I Basic Profile and the WS-I specifications, and seeing what needs to be done in the J2EE specification to make those align. Then, when that's completed, the compatibility testing needs to look at the new J2EE specifications with those changes and make sure they're both a complete set of tasks and that the new tests test only those things in the new specs.

IDN: Do you think this work will redefine what an API look like, as far as coping with portability and interoperability?

Galantine: It doesn't redefine an API, but what we're talking about is interoperability at the protocol level and the Web Services Definition Language (WSDL) level. Those things we want to take into account, and that's part of what WS-I is doing -- the ability to interoperate with non-Java platforms, to make that smooth.

IDN: What about your timetable? Will you need extra time to test the new tests, so to speak, given this is a new area for the JCP?

Galantine: As far as we've gotten on the timetable is by the summer this year we'll have the whole thing finalized.

IDN: Is it useful or worthwhile to consider whether JCP and WS-I testing, as the specifications move forward to more complex web services tasks, should be done as a joint effort? Or failing that, at least more cooperation and note-checking along the way?

Galantine: Definitely, absolutely. The relevant platforms for web services are J2EE and Microsoft's Windows and the .NET models. Certainly, taking into account what's in J2EE and the J2EE specification is critical for WS-I.

IDN: Are discussions underway now to get better two-way communications and cooperation between JCP and WS-I?

Galantine: There are, through both Sun's membership and the J2EE licensees that are also members of WS-I.

IDN: Do you also expect WS-I to take on a bigger role in interoperability testing or a testing-of-the-tests role to make sure that if anything is "broken" on either side, the Windows and/or Java vendors know about it, and fix it?

Galantine: I think that's part of the very role they were set up to do: to be an interoperability consortium around web services and to be able to do some testing and serve as a forum for the members to test their products to make sure they will interoperate together.