IBM Websphere Exec Says Sun is "Blocking Innovation"

Last week, IBM released Websphere 5, the latest upgrade to its J2EE-based application server, with several key supports for web services. Even so, a key IBM exec says Sun and current JCP rules are "blocking innovation," making it tough for J2EE vendors to push the web services envelop. See what's latest in Websphere 5, and why IBM thinks Sun may be putting a drag on J2EE web services innovations.

Tags: App Server, Websphere, Web Services, J2EE, Certification, Developers, Support,

with Stefan Van Overtveldt,
Program Director, IBM Websphere

by Vance McCarthy
Even as IBM releases its latest version of its J2EE-based Websphere application server with several key supports for web services, a key IBM Websphere exec says it's tough for J2EE vendors to push the web services envelop because Sun and current JCP (Java Community Process) rules are "blocking innovation."

On the heels of last week's release of Websphere 5, Integration Developer News spoke with Stefan Van Overtveldt, program director for IBM's Websphere technical marketing. IDN asked about how IBM expects the Java community to deal with coming changes in the J2EE app server sector -- on technical, political and developer-driven fronts.

In the bargain, IDN got one of the best drill-down briefings yet in print on just what web services technologies are in the full-blown version of Websphere, which ones have the support of Java and Microsoft app server vendors, and which the JCP won't certify.

IDN: So, what is the status of Websphere 5 right now? Are you Java or JCP certified?

Van Overtveldt: Websphere version 5 is fully J2EE 1.3 compatible and certified. In our network deployment or clustering version, it actually includes a large number of J2EE 1.4-specified technologies. For instance, Websphere includes the J2EE 1.4-defined SOAP parser, embeds a WSDL web services description language for Java as defined by J2EE 1.4, and includes security support as defined by the Java Security Model (JSM).

IDN: Does that mean you're getting ready for J2EE 1.4 certification?

Van Overtveldt: We are not ready to be J2EE 1.4 certified since the full spec is not out yet. We expect that in the 1rst or 2nd quarter of next year. So, I'm not going down the path of claiming compatibility

IDN: But there is an important difference between "compatibility" versus "certification" for J2EE, is that right? .

Van Overtveldt: Since J2EE 1.4 has more capabilities than J2EE 1.3, it obviously needs more tests. [When Sun introduced a second level of tests, the process to be certified means you had to pass some 15,000 CTS tests. That will go up to 20,0000 tests in J2EE 1.4]. In [J2EE] 1.3, Sun introduced two levels of testing. The Certification Test Suite (CTS) will test the app server for capabilities defined in the J2EE 1.3 spec. Passing that test gives you full compatibility. To get certification, you also need to pass the Signature Test Suite, which tests for functions NOT defined by J2EE 1.3, and you only pass if they're not present. So support for workflow, for instance, that is not already specified in J2EE 1.3 will not pass certification.

IDN: So, for features that go over and above what is specified in J2EE 1.3 mean that the whole product -- not just those features -- fail certification?

Van Overtveldt: If you go past [J2EE] 1.3, you won't pass certification. Sun is blocking innovation in the J2EE space. To catch up, it would not seem unreasonable. The IBM and BEA [the other leading J2EE app server provider] recourse is that we certify only our base levels of application server. That means for IBM our foundation Websphere application server has its core services certified -- that means without running all our web services or integration features.

IDN: So, you've certified a "dumbed down" Websphere, even though some developers may want to know these newer features, like web services support, are certified?

Van Overtveldt: It's because if you add functionality you cannot pass the Signature test. So, we certify the base application server

IDN: [So, in light of these restrictive rules on J2EE app server certification], what do you think about Sun bundling its SunOne [J2EE] Application Server with the Solaris operating system?

Van Overtveldt: I think it's a desperation move. I would argue that that is probably the only thing left to do if you have been completely unsuccessful with two previous app server product lines. Sun is a hardware company heart and soul, and all this is geared around selling more Solaris boxes. In a way, it's sad that Sun has been unable to take their leadership [in the Java community] and convert it into a software business.

IDN: What is the impact on Websphere product development from such a practice?

Van Overtveldt: We are not going to stop applying innovation in app server space, Websphere 5 has more innovation than any other app server out there. We're also driving those functions into the certification process.

IDN: How are you doing that?

Van Overtveldt: As an example, there is JSR 109, which specifies an embedded SOAP parser for the Java programming model -- something Java programmers have been increasingly asking for absent native SOAP support in Java. That is the one we submitted to both the Java Community Process and the Apache Axis group as the Axis Parser. The fact that Axis SOAP parser has matured to offer superior performance and that will get included as a clear.

IDN: So, is there change, or pressure for change, coming inside the JCP?

Van Overtveldt: There might be significantly more pressure on Sun to submit Java to a[nother] standards body to really open it up. We have enough leverage to exert some changes with companies like IBM, BEA and others driving for new ways of bringing in new services. It's driven as much by other members of the JCP as it is by Sun. In fact, 70% of the initial J2EE specification is [IP and] technology we donated to Sun and the community. Look at the transaction and messaging and JCA (Java Connector Architecture) is IBM architecture

IDN: So is this approach out of date given the state of the app server market? How do you view the trend of app servers -- both from Java and Microsoft -- as being a platform for more complex services and integration?

Van Overtveldt: As we look at application serves over the past 2-3 years, we see a change in how people are using them. For the first two to three years people were using app servers to build some app logic primarily to front-end and existing applications. Right now, app servers are being used to build new applications and integrate them. So, the role of the app server changed to a next generation.

IDN: IBM has such a background with EAI, how do you see the difference between EAI and app server support for web services-driven integration?

Van Overtveldt: EAI is focused on integration of existing assets. With Websphere, we have focused on building integration capabilities into a new application.

IDN: Sounds like a way to bring developers -- and not just expensive consultants -- into the integration sector?

Van Overtveldt: We look at the integration space in a broader context than the simple middleware approach of the past. Developers are now focused around using integration themselves, and are less and less likely to leave those functions to someone else. Regarding a lot of business process management (BPM) tasks, for instance, to me it looks like you will see different types of developer skills to emerge that will help business people define and implement process models.

That, in turn, will drive down to affect the business analysts who may be empowered to do their own application modeling because it will be the professional developer who will be driving the work on connections into the applications, or linking together different pieces of code.

IDN: So, your view of the app server space is more than simply a brokering server between nodes. Does that mean you expect app servers need to support more business logic directly?

Van Overtveldt: Our model is that base workflow and business rules will be embedded in the Websphere app server, and exposed as services to programmers. More extensive and easy-to-use Business Integration functions on top of this technology will then be available to business analysts. For example, there is significant value to providing a BI [business integration] solution that can deal with end-to-end event management

IDN: There must be other web services and integration aspects of Websphere's enterprise edition that IBM couldn't get certified. You mention workflow? Is that based on MQ Series or other queuing technologies?

Van Overtveldt: We have an embedded JMS in Websphere version 5, so we have Java-to-java messaging with JMS and we have slimmed down MQ Series' queue manager to work on our app sever. We also have full support for EJB 2.0 asynchronous messaging.

IDN: What about supporting more vendor-neutral approaches to messaging or workflow? You have worked with Microsoft and others in WS-I (the Web Services Interoperability Organization) on many proposals, for example. Anything there in Websphere 5?

Van Overtveldt: We have completely prepared the Websphere server runtime to support BPEL4WS and WS-Coordination. We also have support for WS-Transaction.

IDN: Let me get this straight. You have an implementation of these WS-I codesets even before they are in final approval?

Van Overtveldt: To be clear, we have a complete implementation of a runtime perspective to support all three. What we have NOT done, simply because of the point in time we are at with these specs, is to take the workflow engine in Websphere 5 and get it to interpret BPEL4WS. BPEL is really a flow definition language and interface application approach.

IDN: So, do you have some end-to-end workflow support, and if it's not BPEL yet what are you using?

Van Overtveldt: The flow language we support is FDML, which is part of the IBM technology in BPEL. People are not going to write FDML in an editor, but will be using the tool to draw flows and the tool will generate the FDML from that modeling. In the future, our web services developer toolkit will generate BPEL4WS.

Inside Websphere 5, Websphere Studio
A number of key technology highlights developers will see in Websphere 5:

  • Support for Web Services Invocation Framework (WSIF), for invoking and developing Web services across a variety of network and transport protocols (ranging from HTTP to instant messaging), regardless of how the Web service is implemented and accessed;

  • Bundled Axis 1.0, new high-speed Web services technology that processes Web services SOAP requests;

  • Support for Web services workflow, so developers can more easily build networked applications that link multiple business processes -- such as checking approvals, inventory, credit and shipping. This workflow support is where developers will the first bundled app server implementations of several of the WS-I (Web Services Interoperability) proposals for secure cross-platform web services transactions, including WS-Transaction and WS-Coordination. (These WS-I proposals are co-authored and supported by Microsoft and the other leading J2EE app server vendor BEA Systems, among others).

  • An embedded Web Services Gateway, which provides a manageable and secure environment for Web services designed to run beyond a firewall.

  • A private UDDI repository, which allows a company to search for combine Web services within their organization;

  • A range of app server maintenance, management and troubleshooting features, including: (1) Self-configuring features for performance tuning; (2) auto analysis of
    problematic patterns to aid with troubleshooting and real-time diagnostics; (3) optimization to prioritize applications and/or users; and (4) added security to screen out faulty requests and access controls

    Prices for Websphere 5 start at $8,000 (single server configuration).