IBM has announced the availability of Websphere 5, the long awaited J2EE 1.3 certified appserver. The new version includes much of the web services support specified in J2EE 1.4 (from JSR 109), a JMX management interface, new self-healing and self-tuning/configuring features, etc. IBM debriefed TheServerSide on whats new in WS 5, here is what we learned:

Firstly, IBM Websphere no longer comes in 'editions'. Rather, the product has been split into three versions.

The first product is WS Express, which basically websphere with the EJB and clustering features removed. Next comes Websphere applicaiton server 5 (the subject of today's announcement), which has a base version (no clustering or web services) and a 'network deployment' version, which includes clustering and failover support, a Web Services gateway and UDDI server. Finally, Websphere Enterprise adds a realtime application profiler, a sophisticated workflow engine, a rules engine (that can modify the member variables of EJB's in real-time), and new technology called Asych beans (described later in this article).

Webpshere 5 Appserver is fully J2EE 1.3 certified (meaning that it supports EJB 2.0, JSP 1.2, Servlet 2.3 and all those goodies). It also has features lots of features from j2ee 1.4 including implementation of most of JSR 109 (the JSR about how Web Services will be integrated with J2EE), JAXR, JAX-RPC, etc. It supports JAAS and JMX and has a new web-based management console (like Weblogic) that also exposes a JMX management interface that developers can access programmatically.

The Network Deployment version adds strong clustering support. The cluster is self managing, and is partitioned into two replicable entities: the cluster agent (the actual j2ee server) and the cluster manager. The manager is NOT a single point of failure (contrary to recent BEA criticisms), and can be restarted automatically by the other live cluster agents.

Websphere 5 also includes other 'autonomic' features such as self-tuning and self-optimization features, which has the appserver monitor itslf and make configuration changes to itself at runtime or issue recomendations to administrators on how to better tune the appserver. For example, the appserver has a self-optimization feature that allows you to prioritize requests from certain end users over others. So if a request over HTTP or RMI comes in from a 'gold level' customer, the cluster can send those requests to particular nodes in the cluster.

In addition to Websphere's web services API support, it also had a private UDDI server, and a web services gateway. The gateway can be installed in the DMZ and does authentication (managed with a subset of tivoli). The gateway can also parse an incoming Web Service request and convert to a call over another protocol (RMI, etc).

The enterprise version will support Web Services workflow capabilities (not BPML, they were too late) that has full transactional support, with nested workflows. The workflow supports 'human interaction' - it can generate a tasklist for a human/dept to see and interact with.

An interesting item that will be offered in the enteperise version is asych and startup beans.

Async Beans add full support for application controlled threading to J2EE applications. This allows more performant J2EE applications to be built as J2EE applications can now take advantage of multi-processor boxes when performing complex operations as well as start daemon threads to execute long running background application tasks. It also adds full application callback support which allows J2EE components to registers themselves as asynchronous callbacks and be notified of intra JVM asynchronous events. It also adds support for transient alarms and heart beat based remote system availability monitoring. This support allows J2EE applications to behave in a more dynamic manner, dynamically subscribe to JMS destinations, integrate third party middleware, develop very advanced caching subsystems and built more performant applications.

Start up Beans allow J2EE applications to mark one or more session beans as startup beans. These beans can have a start method called when the application is started and a stop method called when the application finishes. The full WebSphere programming model is available in these methods thus allowing any business logic to be executed when an application starts or stops. Combined with async beans, these can be used to start daemon threads, warm custom or option A CMP caches or any application logic that a customer desires.

According to Stefan Van Overtveldt (Director of Technical Marketing), IBM's feels that the role of the application server is changing. Previously, people were using appservers as web front ends to existing apps. Now, appservers are being used as an integration hub within a company. IBM's strategy is to really make the appserver the centre piece of the ebusiness strategy, like the OS on the network.

Read the press release and checkout Websphere Application Server 5, which will be available for download on tomorrow (teusday).

Infoworld has also reported on Websphere 5.

Thanks for the latest news.This would really help us to update ourselves.Infact the GUI which the IBM has provided is the best and the services incorporated now will give boom to the e-commerce applications..

I just downloaded WAS 5.0. I think it will be wrong to say that it is J2EE1.4 ready. I coulkd not find the support for EJB2.1. Also, although in there anouncement, IBM claimes that WAS Developer 5.0 is available but in reality it is not, the web site just allows you to register for it and then says, when it is ready, they will get back to us.

To get WSAD 5.0:

http://www-3.ibm.com/software/pervasive/products/wsdd/download/

Also, those will subscriptions can get it too. Ask and ye shall receive. It is awesome!

Um, that URL's for *Device Developer*, not WSAD...

Well, the Device developer is cool too. :)

Sorry, it is early and I was up late.

Here is one, but you have to be a toolbox subscriber. http://www6.software.ibm.com/devcon/devcon/docs/wsad50wi.htm
It does show that it is available. I do believe previous anouncements for WSAD do say it isn't currently available for General Availability. I don't keep all my newsletters so I can't prove it.

Mark

Too bad WAS 5.0 does not come with the 1.4 JDK ;-)

Common IBM. It's almost been a year.......

Actually, 1.4 is going to be introduced later, WSAD 5.0 is still in Early Availability program, ie. not a full release. When IBM introduces JDK1.4 it will have incremental compiling like in VisualAge....

regards

With respect to JDK availability, the broader question to ask IBM is: Why the hell they are trying to implement their own JVM, instead of using the Sun's? They preach a lot about reuse, but when it comes to their products, they don't follow and make interoperation a nightmare.

How many people have had problems because their client use Sun's JVM and could not lookup an EJB in WebSphere?

I was an IBM'er myself and I like IBM as a company. But, egregious mistakes like this makes me really annoyed.

It is only a question of time before IBM realizes this and starts using Sun's JVM. By that time, it would have destroyed the last bit of faith in achieving true interoperability.

Srini Santhanam
RBC Dain Rauscher
An irritated WebSphere User...

Reason why IBM uses its own JDK is about customer support and IBM stays behind it. If they include SUNs JDK then if something goes wrong, they won't be allowed to fix it. Also, as an ex-IBMer I worked in Hursley where they were developing JDK (and use to test it) for now deceased OS/2 and that was with aproval from SUN. Also, SUN would never release JDK for OS/400, zOS, or AIX PowerPC, so IBM has to do that themselves, and yes WS runs on all of those platforms.

IBM produces its own JVM because they've got a good track record of making releases that perform better than Sun's, and because Sun doesn't produce a JVM for all of IBM's platforms (plus they're able to integrate it deeply into their platforms -- the JVM for iSeries is deeply embedded into OS/400 (kinda sorta kernel level) ). It's probably more the last part, so they can ensure that WebSphere will behave similarly across all platforms.

In my opinion, IBM Application server is stronger than some
other servers in providing the functionality. But it provides tools / procedures with more complexity than simple.

It demands the customers to use IBM JDK, that is one big issue. They should also need to support Sun's JDK with full flexibility.

Kumar,
Aalayance
INDIA

<snip>
With respect to JDK availability, the broader question to ask IBM is: Why the hell they are trying to implement their own JVM, instead of using the Sun's
</snip>
Too bad, then we'll have only one JVM in the world. Sure path to world domination :)

Java is a "startegic" language for IBM. With own
experience with jvm + Apapche + Eclipse IBM
has POSSIBILITY to keep java alive if
something happend to Sun (I wish not).

Similar with Oracle: main admin tools and
Report/Forms are now java-bound. Small news
about Oracle supports Eclipse is (IMHO)
part of a big picture.

I thing it is good for Java in general
to have several big-money-haves to support
it in somewhat concurent way -
no single point of failure.

AlexV.

It seems that's IBM JDK has its own RMI/IIOP implementation (with addons for EJB remote calls); and that's a reason why interoperability between Sun's JDK and IBM's one are impossible.
IBM'ers ? is it right?

No, IBM ships its own CORBA implementation to replace JavaIDL, which in turn gives much better RMI/IIOP performance. While BEA mostly uses T3 not touching IIOP at all, JBoss also uses RMI mostly. In WLS, if you use IIOP, it simply uses ORB in the JDK, and the performance is not well tuned.
In latest JDK1.4, JavaIDL is greatly enhanced to support POA. So potentially, IBM can more gracefully introduce its own CORBA on top of Sun JDK1.4.
Right now, IBM ships Pluggable Java Client technology. So you can install it on top of Sun JDK, and then it replaces JavaIDL.
If you have interest, check out this:
http://ejbinfo.com/WebSphere/01/01/28/0629217.shtml

Java came with the promise: "Write Once, Run Everywhere".

This requires that the java code you write for any JVM vendor should run on any other vendor's JVM untouched.

If one JVM does not interoperate with another, to me, it is a violation of this promise. What then is the difference between multiple OS'es and multiple JVM's? Nothing...

Thanks.
-Srini...

srinivasan: "This requires that the java code you write for any JVM vendor should run on any other vendor's JVM untouched."

Have you written pure Java code according to the 100% Pure Java guidelines and had it fail when you ran it on any other vendor's JVM?

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

IBM is just cool: Take everything BEA does and copy it (but deliver it 2+ years later and cheaper and use that to sell their other stuff). Tough for BEA...

Those "startup beans" == the "startup classes" that BEAS has had since 1998. Way to go IBMer's!

<quote>Those "startup beans" == the "startup classes" that BEAS has had since 1998. Way to go IBMer's!</quote>

Startup classes has been part of WAS for a long time as well...

>> also uses RMI mostly.
Nope.
JBoss uses IIOP.


>> In WLS, if you use IIOP, it simply uses ORB in the JDK, and
>> the performance is not well tuned.

Nope again.
Wls actually doesnt use an ORB at all in their appserver - instead it has multiple protocol handlers. You can access an EJB using RMI/t3, RMI/iiop and RMI/http simultaneously.


-Nick

I think you'll find that IBM wrote RMI/IIOP, so they question is who's being incompatible ;-)

In actual fact the IBM JVM passed the JCK and so does SUN's so they are compatible.

IBM write their own JVM's to:

-Own the whole service stack.

-Guarantee performance and stability.

-Provide cross platform support.

-Have a better skills and technolgy base to develop products on.

-To gain influence in the direction of Java.

-As a stick to beat the competition with.

-and last but not least, they like Java!

Why did the darling BEA buy a JVM writting company?

My views are my own not IBM's

RMI/IIOP Interoperability seems to be mandatory with the J2SE 1.4, and not a requirement with J2SE 1.3.
The J2SE1.4 specification is very clear about the use of IIOP interoperability, and so, the mandatory of a CORBA 2.3 complient ORB.
Perhaps, this requirement is a reason why there is not yet a IBM JDK1.4 shipped with WAS5 ?


From J2SE 1.3 RMI-IIOP Programmer's Guide
<LI>Interoperating with Other ORBs
RMI-IIOP will interoperate with other ORBS that support the CORBA 2.3 specification. It will not interoperate with older ORBs, because these are unable to handle the IIOP encodings for Objects By Value. This support is needed to send RMI value classes (including strings) over IIOP. At present, no other CORBA 2.3 ORBs are commercially available, but it is expected that these will appear soon.

From J2SE 1.4 RMI over IIOP Technology Documentation Home Page

<LI>When Enterprise JavaBeans components are implemented using the RMI-IIOP protocol for EJB component interoperability in heterogeneous server environments, the standard mapping of the EJB architecture to CORBA enables interoperability with multivendor ORBs, other EJB servers, and CORBA clients written in programming languages other than the Java programming language. For an example application that uses an EJB server with a CORBA client, look at Enterprise JavaBeans Components and CORBA Clients.

From Changes in CORBA Features Between J2SE 1.3 and 1.4
<LI>Interoperable Naming Service :
The Interoperable Naming Service (INS) provides the following features:
Capability to resolve using stringified names (e.g., a/b.c/d)
URLs for CORBA object references (corbaloc: and corbaname: formats)
Standard APIs in NamingContextExt for converting between CosNames, URLs, and Strings
ORB arguments for bootstrapping (ORBInitRef and ORBDefaultInitRef)

RMI/IIOP Interoperability seems to be mandatory with the J2SE 1.4, and not a requirement with J2SE 1.3.
The J2SE1.4 specification is very clear about the use of IIOP interoperability, and so, the mandatory of a CORBA 2.3 complient ORB.
Perhaps, this requirement is a reason why there is not yet a IBM JDK1.4 shipped with WAS5 ?


From J2SE 1.3 RMI-IIOP Programmer's Guide
<LI>Interoperating with Other ORBs
RMI-IIOP will interoperate with other ORBS that support the CORBA 2.3 specification. It will not interoperate with older ORBs, because these are unable to handle the IIOP encodings for Objects By Value. This support is needed to send RMI value classes (including strings) over IIOP. At present, no other CORBA 2.3 ORBs are commercially available, but it is expected that these will appear soon.

From J2SE 1.4 RMI over IIOP Technology Documentation Home Page

<LI>When Enterprise JavaBeans components are implemented using the RMI-IIOP protocol for EJB component interoperability in heterogeneous server environments, the standard mapping of the EJB architecture to CORBA enables interoperability with multivendor ORBs, other EJB servers, and CORBA clients written in programming languages other than the Java programming language. For an example application that uses an EJB server with a CORBA client, look at Enterprise JavaBeans Components and CORBA Clients.

From Changes in CORBA Features Between J2SE 1.3 and 1.4
<LI>Interoperable Naming Service :
The Interoperable Naming Service (INS) provides the following features:
Capability to resolve using stringified names (e.g., a/b.c/d)
URLs for CORBA object references (corbaloc: and corbaname: formats)
Standard APIs in NamingContextExt for converting between CosNames, URLs, and Strings
ORB arguments for bootstrapping (ORBInitRef and ORBDefaultInitRef)

I may be wrong, but I don't think the problem is RMI-IIOP interop as such. Wire format interoperability is something that has been required since forever.

The problem is more to do with client side orb bindings. These are orb specific. So, a stub generated for use with the IBM orb may not work with the Sun orb, or any other orb for that matter. If you want stubs that work with the Sun orb youd have to create them using the Sun RMIC tool.

The problem is complicated by the fact that IBM implemets work load balancing in the orb through the use of GIOP LocateRequest messages (I think). Not all orbs use these messages.

The situation is further complicated by the fact that until recently there were no standard ways to add services to an orb for things like transaction or security propagation. That's much better now that technologies such as the OMG Portable Object Adapter and OMG Portable Interceptors are defined, but not all orbs implement these interfaces.

I may be wrong, but I don't think the problem is RMI-IIOP interop as such. Wire format interoperability is something that has been required since forever.

The problem is more to do with client side orb bindings. These are orb specific. So, a stub generated for use with the IBM orb may not work with the Sun orb, or any other orb for that matter. If you want stubs that work with the Sun orb youd have to create them using the Sun RMIC tool.

The problem is complicated by the fact that IBM implemets work load balancing in the orb through the use of GIOP LocateRequest messages (I think). Not all orbs use these messages.

The situation is further complicated by the fact that until recently there were no standard ways to add services to an orb for things like transaction or security propagation. That's much better now that technologies such as the OMG Portable Object Adapter and OMG Portable Interceptors are defined, but not all orbs implement these interfaces.

First, just to make something clear...IBM produced the reference RMI/IIOP implementation that is used in both IBM's and Sun's JDK implementations, as well as tools such as the IDLJ IDL to Java compiler and the "-iiop" option of the RMIC compiler. So it is definitely not a question of the ORB in the IBM JDK being somehow back-level compared to Sun's. They are effectively the same exact ORB. Likewise the format of the generated stub and tie code is exactly the same; actually the APIs used between these artifacts and the ORB implementation have been standardized for awhile; anyone's stubs and ties will run on anyone's ORB implementation.

The main questions in this thread seem to boil down to:

1. Why does IBM produce its own JVM/JDK implementation?

2. Why isn't WebSphere supported on more than one JVM/JDK implementation per platform? (for example, on both the Sun and IBM JVMs for Windows)


First of all, I work for IBM and am part of the WebSphere app server development group (specifically the EJB container) and I've been involved with this JDK and ORB stuff for quite a few years, but must also state that what I write here is my own view, not necessarily IBM's.

Why does IBM produce its own JVM/JDK implementation? There are a number of reasons, some of which were mentioned by a previous post. Certainly for IBM-specific platforms like AIX or OS/400 it should be obvious; it's the same reason that HP produces its own JVM for HP-UX or Sun produces its own JVM for Solaris. Generally the owner of a platform is responsible as a Java licensee for producing the JVM/JDK for that platform. Those implementations must pass a set of stringent compatibility tests before they can be legally stamped with the "Java" brand. (The tests cover a lot of scenarios, but not every possible scenario in the universe. So a JVM that passes the tests can still have bugs, even Sun's JVM.)

For a few platforms that are not owned by a partcular hardware vendor, such as Windows or Linux, there are a number of companies that produce JVMs. Historically Sun produced the JVM for Windows and for awhile was the only source of a Windows JVM. Microsoft and Netscape produced Windows JVMs for awhile but of course neither is still active at it today (each for very different reasons).

Probably one of the main reasons IBM got into the JVM business was because our customers asked us to. Back in the WebSphere 1.0/2.0 timeframe, we used the Sun JVM as the base for WebSphere on Windows. The problem was that customers kept running into application problems that ultimately were caused by some bug in the JVM, and these customers let IBM know *very* clearly that they didn't want to deal with both IBM and Sun when it came to getting their app server "stack" working. And in a lot of cases, the bug that a particular customer was hitting didn't fall very high on Sun's priority list for getting fixed. Understandably, IBM's ability to compel Sun to fix a given JVM bug is limited; Sun is going to do what is in Sun's interest, not necessarily what is in IBM's interest. So in response to customer demand (and improve the overall acceptance of Java as a mission-critical application platform), IBM started producing a JVM/JDK implementation. Besides letting us be more responsive to bugs, it also made it possible to deliver improvements to performance, garbage collection, and to deliver functionality such as RMI/IIOP ahead of the Sun implementations. Customer response to this arrangement has been overwhelmingly positive...there is no longer a need to deal with two vendors when a problem arises, and they get a fully-compliant JDK that will run any code that runs on any other JDK implementation, with excellent performance and high quality. I would guess that BEA bought the company that produces the JRockit JVM for some of the same reasons.

So the next question is why IBM currently doesn't support WebSphere on more than single JVM type per operating system platform, e.g. both the IBM and Sun JVMs for Windows (why not throw JRockit in there too, I suppose). One reason is obviously cost. Each additional JVM type supported incurs additional testing costs (both the standard quality-assurance testing as well as the entire suite of J2EE compatibility tests) and additional support costs (many more combinations of things that can go wrong out in the field). Another reason relates to what I mentioned above: customers have made it very clear that they don't want any multi-vendor "finger pointing" when something in the app server "stack" isn't working right.

Even given the above, I agree there are situations where it would be useful to run WAS on other JVMs than the official supported one for a given OS platform. I'm curious about how people would respond to the following options:

- Publish a procedure to run WAS 5.0 on other JDKs (for experimentation, early development, etc.) but not supported as a production configuration

- Provide support for running WAS 5.0 on other JDKs in production, as a license add-on for an extra charge

Any thoughts?

Randy Schnier
WAS 5.0 architecture and development

Can I get a trial version of Websphere Enterprise (which includes rules engines, work flow supports etc).
Is it availabe for trial download? which URL?

Thanks,
Parag

Randy,

The fact that IBM produce a quality JVM is excellent - FWIW I dont understand at all why anyone would question this.

However, why Websphere is only supported on the IBM JVM on non-ibm hardware has always puzzled me.

I cannot believe that the cost of multi-JVM support is prohibitive to the likes of IBM. If BEA can afford to do it, I am not sure why IBM cant. (IBM can afford to pay us to take 100+ licenses of Websphere...)

While I appreciate that some customers want a single vendor solution, I work for one very large IBM customer - and we want to have the option to switch JVM's. I

If we hit a JVM problem, we want to be able to use another vendor's JVM to keep our application running (until its fixed) and still have our Websphere installation supported. If there is a JVM that offers substantially better performance, we want to be able to use it.

We have actually had a situation where a production application was held back for 6 months due to a problem with the JVM on AIX. It was a complete show-stopper. As it was AIX, we didnt have much choice but to wait until it was fixed. We want to avoid these situations.

I have personally had experience, stress testing an application on Weblogic where we exposed a bug in Sun's JDK 1.3.1_03 (GC problem). I was able to switch to JRockit or JDK1.4.0 and the problem went away. Not only were we able to continue working, but we were also able definatively isolate the problem as being a JVM problem.
(Incidentally, I tried switching to IBM's JVM and the same problem occurred)

I personally think that it is this sort of capability that enterprises need from their software vendors. For us, it is one of the key selling points of J2EE over .Net (good luck if you have a CLR bug)

I think that this level of standards support is to be expected of suppliers of eterprise ready software - however, with reference to your suggestion, I certainly dont think that customers should pay a premium for it.
I dont imagine that all JVM's will be supported immediately, but they should be supported in a timely fashion.

Regards,
Nick

Randy: Many thanks for your explanation.

Nick:
<quote>
The fact that IBM produce a quality JVM is excellent - FWIW I dont understand at all why anyone would question this.
</quote>

We were forced to use Sun's JVM 1.3 on our Windows clients (for lack of production quality IBM's JVM 1.3 for Windows) against the WebSphere Server 5.0 running on AIX. The Java Client was unable to look up an EJB using JNDI. After a lot of reasearch, we found out that it is due to a difference in the implementation of the ORB between the Sun and IBM JVM's.

I have some documentation from an IBM expert (not sure if it was Randy himself) which suggested several workarounds, but all of them failed. I will post the URL in this thread if anyone wants it.

Thanks.
-Srini

Sorry. It was against WAS 4.0 on AIX, not WAS 5.0... Thanks.

Srini,

A while back, we analyzed some of the differences between the IBM and Sun implementations that caused them not to talk to each other over IIOP. IIRC, the IBM client was including more information as part of its connect processing, including security information. (As one example, I believe that WebSphere gets the security credentials for remote EJB calls from the ORB.)

This _can_ work on the Sun JVM, since WebSphere for Solaris runs on the Sun JVM. I don't know why there is no detailed explanation for the behavior (and what you have to do to be "compatible"), because this has been a WebSphere "issue" going back several years.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Srini,

Could you post the work arounds for accessing EJB's running on WAS 4.0 from a client running on different JVM
Thanks,

Narayana

Narayana-

Here is the URL that talks about the workarounds.

http://www.ejbinfo.com/WebSphere/01/01/28/0629217.shtml

Incidentally, the suggestions were from Randy Schnier of IBM, who also posted some information in this thread.

Since we started using Sun's JVM 1.3 on the client, we did not bother to find out if a production ready 1.3 JVM for Windows from IBM is available or not. The page I go to check for JVM availability from IBM is:

http://www-106.ibm.com/developerworks/java/jdk/

From this URL, I could not figure out if a production ready version of 1.3.1 is supplied with the Web Services SDK or not. [May be it is available for quite some time, but we gave up a long time ago!]

Thanks,
-Srini...

Can somebody tell me where can I download trial version of WASD 5.0. On their download page, IBM has registration option.

Srini wrote:
<quote>
We were forced to use Sun's JVM 1.3 on our Windows clients (for lack of production quality IBM's JVM 1.3 for Windows) against the WebSphere Server 5.0 running on AIX. The Java Client was unable to look up an EJB using JNDI. After a lot of reasearch, we found out that it is due to a difference in the implementation of the ORB between the Sun and IBM JVM's.
</quote>

WebSphere 4.0 shipped with a production-quality 1.3 JVM along with the product itself. So, I don't completely understand your comments about having to run the Sun JVM because of a lack of a 1.3 version of the IBM JVM?

The reason that clients to 4.0 (as shipped) won't run on the Sun JVM is because of an oversight by the naming service (used by JNDI) -- they were calling an API that only existed in the WebSphere extensions (things like the object service interceptors -- remember, portable interceptors didn't exist yet) that are layered on top of the base ORB. This was corrected in the "portable WebSphere client" package that's been mentioned earlier in this forum. It's a free download provided for those customers who want to use the Sun JVM on their client machines. The workaround to the naming service problem, which I posted to ejbinfo.com quite a while back, has long since been superceded by the portable client package. The workaround wasn't a complete solution and was somewhat ugly, whereas the portable client package is much better.

Randy

FYI, the pluggable client package can be downloaded from http://www7b.boulder.ibm.com/wsdd/downloads/pluggableclient.html

It works with WAS 3.5.3 and later (which of course includes 4.0). For WAS 5.0, the pluggable client is included as one of the installation options on the clients CD.

Randy

Randy-

Thanks again for the correction and the update. It has been probably over an year and a half and I was not careful about the version numbers when I wrote the note.

1. When we started the project last year, I believe that WAS was in version 3.5 (I think 3.5.3 to be precise. I have to refer back to my documentation which are in my office). That means the IBM JDK was at 1.2.2.

During this time, we had to develop our Swing client application using 1.3 JDK.(again, I am not able to pinpoint the reason as to why 1.3 was needed; I believe that it may be because of Swing performance. I will come up with more details). So, there was a time that we were forced to use Sun's JVM 1.3 on the client against IBM's JVM 1.2.2 on the AIX server. Around this time, when you posted in the ejbinfo forum, you also indicated that this is a fact, when you wrote: "The only officially-supported configuration is where the client and server are each running IBM JDK 1.2.2 at the fix level recommended...".

2. I am not sure when the Pluggable Application Client officially became available or when IBM's 1.3 JVM for Windows became available. It did not matter much to us at that point since we avoided RMI-IIOP completely and used Async Request/Replies over MQ instead. Around this time, IBM's JVM 1.3 was available as a "preview" release and IBM indicated that they will not support this in production. We even tried this preview version at this time, with a "download" available in the IBM site without success. I do have documentation for all these and can provide more information.

3. While it doesn't matter whether we use Sun's 1.3 or IBM's 1.3 on the client now, I was just curious because of some recent serialization issue faced by our developers when sending serialized objects from one JVM to the other - it required the use of "serialVersionUID" and the like.

I was wondering if it would be easy for us to switch to IBM's 1.3 on the client.

Sorry for the confusion with version numbers earlier.

Thanks.
-Srini...

You can run your J2EE client one of two ways on an upgraded JDK.

A) Run your 3.5 client on the 4.0 client container.

Run your 3.5 client on the 4.0 client. This is supported and gets you a 1.3.1 JDK for your client on all platforms. Some tweaking may be needed to get this to work. But, THIS IS SUPPORTED and documented and if you have a problem then you can call us on it.

B) Use the JDK from the 4.0 client on your 3.5 client.

Second and TOTALLY UNSUPPORTED. Install your normal 3.5 client + app. Make sure you're at least 3.5.4. Install the 4.0 client in a different dir. Point the JAVA_HOME env var from your 3.5 startup script to the 4.0 jdk. This isn't supported and if you have a problem then officially you're on your own. If you think you've found a problem then you need to reproduce on a supported JDK before calling support.

Personally, option B is quick and dirty but option A is more attractive as you've got support. Option A is not so difficult and you're on a supported configuration on the latest IBM JDKs (1.3.1) which have a lot of the performance related features from 1.4 already.

Billy
IBM, down the hall from Randy :)

Srini,
Yep, no problem. WAS 3.5 was on JDK 1.2.2 and WAS 4.0 was on JDK 1.3, so I can see your point. By the way, we would have liked to go with JDK 1.4 for WAS 5.0, but for a variety of reasons, partly because some of the JDK dependency dates didn't line up for all of the OS platforms that WAS runs on, the decision was made to go with JDK 1.3.1.

For those customers that have a need to swap out the IBM JDK on the server with a different JDK, I should also mention that an excellent way for customers to get this and other requirements into the product planning process, is to submit them to the WebSphere App Server Feature Request Database, located on the WebSphere Developer Domain website under the "Community" area (the links on the left-hand side of the page). The fastpath is http://www7b.boulder.ibm.com/wsdd/products/fred/fred.html , then select the WebSphere Application Server link (this same page also is the doorway to the WS Studio and WS commerce suite feature request DB's). The requirements submitted to this DB are automatically fed into our planning/prioritization process and the number of "votes" for each feature is used to help assign a priority to the item. Note, there are currently no requirements submitted there for the ability to swap JDKs on the server.

On a different subject, I've noticed, as others have, that the WSAD 5.0 trial download link only lets you register at this time. I have an inquiry in to my WSAD contact on when this trial download might be made available, and will post any news here.

Randy

Randy-

Many thanks for your expert comments. You and your collegue provided a lot of useful information for us.

I wish all the very best for your team, IBM and WebSphere 5.0 / WSAD 5.0.

Thanks.
-Srini...

Thanks a lot for your explanation, Randy!

I know there should have an cartesian explanation for the non compatibility of the WAS stubs on the SUN JVM (in fact JNDI implementation).

Be sure that's the URL (pluggeable app client) you provide is very precious for almost of us.

Actually the stubs themselves run fine on the Sun JVM, you just couldn't retrieve them from the name service. :)

On the other topic...The WSAD folks I spoke with said that although WSAD 5.0 has been announced, it is not yet generally available. The schedule for when the trial download will be available is currently being worked. If you register for the download, you will automatically receive an e-mail when the download becomes available.

Randy

I know I'm about 2 years late, and it's not surprising that the link at:

http://www7b.boulder.ibm.com/wsdd/products/fred/fred.html no longer works, but where can I get the pluggable client for WAS 4.0 now? Is the version on the WAS 5.0 disk the same, or backwards compatible with it, and if so what is the disk labelled?

I'm trying to use WAS 4.0 with a Sun 1.4 JRE, and I get the IIOP problem - I can't use the standard IBM 1.3 JRE because I also need the Java Access Bridge to work fully with a windoze accessibility tool called Zoom Text that requires 1.4 to be present. AND IBM don't seem to ship a 1.4 JRE with the IIOP fix in it (for windoze) (unless you have a link to it?).

Thanks if anyone still checks this thread!

Adrian

<quote>Publish a procedure to run WAS 5.0 on other JDKs (for experimentation, early development, etc.) but not supported as a production configuration.</quote>

Please do so if possible. I would really like to be able to run WAS5 on a 1.4 JVM with support for hotswap, be it a Sun or IBM implementation. This would make me a lot more productive in a WSAD environment.

I used J2SE 1.4 with Eclipse 2.0 about 5 months ago (?) even in debug mode. You should be able to use it in WSAD since Eclipse is the basis for it.

Its only available for "enterprise level" subscription. Can somebody tell me if I can download WASD5.0 trial version?

Ok, how about here?

http://www-3.ibm.com/software/websphere/info/platformv5/wstrialv5.jsp

(I just love Google)

Hi Mark Nuttall,

This link allows only the download Appserver 5.0 not WASD5.0. For WASD5.0, it just provides the option of registering and then it says that whenever WASD5.0 is available, I will be informed. So we are back to where I started the thread of WASD5.0 not being available for trial download.

Vimal

Sorry. I saw that it had both. I already have WSAD 5.0 so I didn't pursue any further than the login. You can always spring for the Enterprise Toolbox Subscription. It is currently on special. I think it is cheaper than an MSDN subscription and you get a whole lot more.

Check out the ibm newsgroup. Maybe someone there knows.

Mark

Subscription is not an option for me without having tried the product and seeing how well it is integrated with WAS5.0. It appears IBM is still not ready with WASD5.0

11-Dec-02
Has anyone got WSAD 5 yet ? all I got was this email....

Dear Developer,

Thank you for your interest in WebSphere trial code. We plan to make the following trial code available in a few weeks:

IBM WebSphere Studio Site Developer for Linux, Version 5 trial
IBM WebSphere Studio Application Developer for Windows, Version 5 trial
IBM WebSphere Application Server - Express for Windows, Version 5 trial

You will receive an e-mail notification once the above trial code become available for download. Thanks again for your interests in WebSphere. To learn more about WebSphere, please visit us at http://www.ibm.com/websphere/.

Sincerely,
IBM WebSphere Marketing Team

WAS 5.0 is J2EE1.3 compliant and integrates some J2EE1.4 features (WebServices). It is not J2EE1.4 compliant!
WSAD is now available. I received the CD after some 15 calls to different IBM departments... persevere! and good luck!

What about xDoclet support? xDoclet support for WAS 4.0 was pratically non-existent, probably due to the complication of IBM's proprietary xmi files. Have they changed the mechanism to a more simple one (as in JBoss or WebLogic)?

If you want to download a trial version go here. If you just want to read some WAS5 documentation then go here.