Java Execs Eye This Week's J2EE 1.4 Beta Release

This week, Sun makes the beta release of the J2EE 1.4 specification available for download. The key to this release is Java's support for web services standards (SOAP, XML and WSDL), and with this upgrade Java developers should be looking at their development in a new, more highly-integrated way. To find out just how J2EE 1.4 will shape the future of Java developers in a web services world, Integration Developer News spoke in depth with two of Sun's leading voices on J2EE: George Grigoryev, J2EE senior product manager, and Glen Martin, senior marketing manager for J2EE and web services.

Tags: J2EE, Developers, Web Services, Java, Standards, IDN, Portability,


This week, Sun makes the beta release of the J2EE 1.4 specification available for download. While the core spec sports many enhancements, the key to this release is Java's support for web services standards SOAP, XML and WSDL. With this version, Java developers should get ready to be looking at their development projects in a new way, say Java professionals -- both from Sun and at a variety of independent ISVs and consulting firms.

While J2EE 1.4 continues to eye standards for Java-wide consensus on portability for Java applications, this latest upgrade sends another message to Java-centric developers. It's time for Java developers to care more about learning ways to interoperate and integrate with the non-Java technologies and applications (Windows, .NET, ERP, messaging, etc.) that "touch" their Java-based applications.

To give developers a sense for how J2EE 1.4 will shape the future of Java developers in a web services world, Integration Developer News spoke in depth with two of Sun's leading voices on J2EE: George Grigoryev, J2EE senior product manager, and Glen Martin, senior marketing manager for J2EE and web services.

In a wide-ranging conversation, IDN asked about the timetable for real J2EE 1.4 products, the complexity of J2EE 1.4, the ability for developers to build web services more easily, the status of Java Community Process (JCP) compatibility and signature testing, plans for interoperating with Microsoft Windows and .NET, and a number of other topics (For clarity, the following Q&A is an aggregation of comments shared by the two Sun J2EE execs.

IDN: What is the timetable for J2EE 1.4 moving forward? Even with the beta coming soon, there still won't be a commercial J2EE 1.4 product until next year, is that correct?

Grigoryev & Martin: Here is the timetable:

  1. We will be releasing J2EE 1.4 beta coming this week. Anybody can get it at http://java.sun.com/j2ee. Our goal is that there will be one beta.

  2. The FCS [First Customer Ship] will come in Q1 next year, when tests are complete. There are 25,000 tests for 1.4, compared to 15,000 for Java 1.3. The FCS includes a binary of the apps [server?] code and a text of the spec. The folks that download will develop little things and try them out, as well as read and review the documentation of the spec.

  3. We also have a separate project to update the Java Pet Store [app] for J2EE 1.4 We don't have a firm date for that.

  4. Based on the launch of 1.3, we'll do the launch for 1.4 for all compatible vendors 4 months after FCS.

IDN: What are the key messages for developers in J2EE 1.4?

Grigoryev & Martin: The portability message is number one.

If a developer has already bought into J2EE, then the key message in 1.4 is portable web service. Web services are on everybody's mind. A lot of people are kicking the tires. There are a bunch of standards being aggressively and competitively pursued by different folks. What we are going to gravitate around is to make sure they are portable and interoperable with other standards proposed by other organizations.

Developers are interested in making sure they avoid a single-source problem. So, one example: If a vendor chooses not to implement a standard, or slows down in that implementation, there is a value developers will get from being able to carry their implementation to another vendor's platform easily -- without the need to write or re-engineer their code base.

IDN: What about interoperability?

Grigoryev & Martin: Interoperability says that if I implement this, then my applications can talk to each other. Portability says I can carry this application around to different vendor stacks.

I think the W3C and the WS-I will do a good job for interoperability. But, what they don't do anything about is portability. There is tremendous value in trying to get an application 95% portable, when trying to move to another application server.

IDN: What about J2EE 1.4's web services support?

Grigoryev & Martin: The purpose of the web services developer pack (WSDP) now being added to J2EE 1.4 is to bring Java developers to J2EE.

In J2EE 1.4, the web service developer pack will have [standard] portability There are a lot of vendors implementing web services now [in advance of J2EE 1.3], but we need a way to retain the portability of those approaches across platforms.

The Java Web Services Developer Pack is designed as an SDK for developers to try technologies, and it is designed to deliver APIs… We're not in a position to be driving protocols. Are we going to come up with a JAX-RPC before SOAP? Of course not.

IDN: Is there a future for the WSDP outside J2EE 1.4? Will it continue to be a stand-alone product?

Grigoryev & Martin: Outside of J2EE 1.4, there will be an ongoing role for what is now called the Web Services Developers' Pack. Moving forward, the goal will be a broader goal: to supply a place for developers to try out the rapidly developing [web services-related] technologies that may not be fully-baked or have status as official standards. We don't know if it will continue to be called the "Web Services Developers' Pack." We're looking at whether we should change the name now.

IDN: What about J2EE 1.4 'alignment' with WS-I? Ed Julson has mentioned that alignment between Java and WS-I is a key goal for joining WS-I.

Grigoryev & Martin: We've just joined WS-I. We can say J2EE 1.4 has been a train in motion for about 18 months, and we're shipping the beta next week and the compatibility test suite is already baked. Any notion of trying to align J2EE 1.4 with WS-I will be difficult. The timing is just uncomfortably tight.

Under Java Community Process rules, we've gone out to beta on J2EE 1.4 specs in final public draft. Prior to becoming final public draft, the JCP "expert groups" have agreed these are the specs they want to go forward. So today, there is agreement within these expert groups that these specs, as written, are how we'd like to go forward. The next step is that the JCP "executive committee" needs to vote the specs as now proposed up and down. This is where all Java companies including BEA, IBM and Borland, Cisco, Apple etc. get a vote.
That takes place in February. It is always possible that someone will believe things should change. But traditionally, there has not been a change this late in the draft process. You must have failed utterly in some important respect for the "final public draft" to be voted down.

IDN: What about other Java interests, like IBM and BEA? Haven't they been able to represent Java's interests?

Grigoryev & Martin: One of the challenges in the standards process is that individuals aren't always completely aligned with all the community's interests.

IDN: What about the JCP compatibility tests?

Grigoryev & Martin: The whole goal of compatibility testing is portability. If you pass the test, your code is portable. If IBM wants to add code over and above what the platform requirements are, they are perfectly capable of doing it in different Java name spaces.

The standard Java classes that implement standards are in the Java.namespace or the JavaX.namespace Other namespaces, such as for Sun the com.sun.whatever the class name is namespace, it is clear to the developer that this is not a standard class, but a vendor-specific class. Clearly, what we're trying to avoid is putting proprietary features in Java and the JavaX.namespaces.

IDN: What does it take to move these classes?

Grigoryev & Martin: It's very simple. It takes one line of code at the original Java.namespace and another few lines of code along with the class in the new vendor-specific namespace. This isn't hard.

IDN: What about the signature tests?

Grigoryev & Martin: Signature says when you implement a class (name and methods in it and particular parameters they require and results they return). The exact patterns of these parameters and the responses is a signature. If you fail a signature test, then the vendor hasn't implemented a required method, added a new method, or changed the parameters of the method or the class. It's also a test of how portable the code is.

There are namespaces reserved for proprietary extensions, and standard namespaces. When they try to make web services add-ons to Java they have to modify the core APIs. And, if you modify the core APIs, then you cannot add web services through better classes, or through the native APIs we'll be adding in with J2EE 1.4. Vendors have a choice whether to truly implement a new feature as an add-on or to modify the core APIs. What IBM is doing is not an add-on. They continue to modify [the core APIs].

IDN: With something this new, how can a developer tell the difference between an add-on and a modification?

Grigoryev & Martin: For web services, there is a JSR (109), that is the key spec. IBM in fact shouldn't find this so difficult since they're the ones that have taken the lead on this work.

IDN: What about the J2EE Connector Architecture.? That's also improved in J2EE 1.4, right?

Grigoryev & Martin: These allow developers to write plug-ins to an application server that will go out to an existing installed application, and it will work with a variety of licensed software and in-house developed applications. These are also meant to be portable, so that the J2EE Connector Architecture is a standard way to develop a gateway so that connectors can be moved from application sever to application server.

In J2EE 1.4, the key enhancement is that these connectors are now bi-directional. With 1.3, you could write code to the back-end application, but there was no way for the back-end application to communicate back to the app server.

IDN: Is it fair to say that the features in J2EE 1.4 underscore the idea that Java developers need to think outside the silo, then. Rather than drop data onto a queue, J2EE 1.4 starts to suggest that developers think more as integrators?

Grigoryev & Martin: It is critical that developers starting thinking more this way. Integration in the enterprise needs to take on a more holistic approach, and in fact our new J2EE blueprints are evolving to reflect this point of view. For instance, we're starting to take on features such as two-phase commit, transaction handling and such, and wrap these services into a single transaction that will reflect a "unit of work."

When standards are more in place, our plan is to make sure our J2EE blueprints [will?] support round-trip transactional semantics. So, for example, when communications protocols like SOAP and other technologies support asynchronous communications, J2EE developers will get these features by default.

Right now, the way SOAP is integrated into J2EE, SOAP will not support an asynchronous transaction. But as soon as SOAP standards are adopted that will support that, and we can identity where the API integration will take place in J2EE, that capability should become available transparently to Java developers.

Connector improvements will also allow J2EE developers to create Java wrappers for APIs in an existing application. The client can use these APIs to call the application.

Connectors are a way for the developer to provide limited exposure to the capability of the application without the need to rewrite any of the legacy code. The API makes a range of behaviors available, so that if a developer doesn't want to expose all features due to security for instance, he doesn't have to.

The purpose of JMS is to enable best-of-breed message queues. Message queuing is absolutely important, but transport capability is not a function of the standard, so applications don't need to be rewritten. But there could be differences in reliability in the transport by which messages will be delivered.

IDN: How will Sun Java support Microsoft in J2EE 1.4?

Grigoryev & Martin: The way we will talk to the Microsoft world will be through web services. APIs will receive SOAP messages and services. It's not directly related to the J2EE 1.4 standard.

IDN: Are there other web services features in J2EE 1.4? What about XML-related support?

Grigoryev & Martin: XSLT is in there someplace, part of the parser JAXP 1.2.

IDN: Other Java Developers Comment on J2EE 1.4

  • J2EE 1.4 is a step in the right direction, with the addition of all the web services support. But if anything, Sun was late in doing this. Every Java provider has been providing a web services port, and it needed to be made official in J2EE. Sun was initially caught off guard by web services, and that left IBM and Microsoft leading the whole effort. By the time they caught up, web services were in full swing and vendors were starting to add extensions to their application servers.

    J2EE 1. 4 needs to add the JAX-B (XML Business Objects) support. That is a very important API to have, especially if web services are going to do something not RPC based, such as document-oriented services where the actual message will be XML-based. These APIs will let Java developers make Java objects from XML schema. It is still in the JCP right now.

    Tarak Modi, a senior developer specialist at North Highland Co., a Java and .NET consultancy in Atlanta, Ga.

  • At the highest level, the new features in the J2EE 1.4 platform make it extremely easy for developers to create web services. The use of industry-standard specifications such as XML, SOAP and WSDL is a good choice in that it lets web services developed for the J2EE platform to be interoperable with web services and clients that reside on other platforms and vice versa The J2EE specification has [also] been extended for database programmers to include new performance-oriented JDBC features.

    Benefits from this are a developer that is not familiar with EJB's can develop web services without learning about EJB's. [On the other hand], it does not simplify much of the functionality that was previously available. So in that light it makes things more complicated because there is more functionality to learn.


    John Goodson, VP of product operations at DataDirect Technologies, a provider of Java and .NET application integration technologies in Rockville, Md.






back