I'm starting to do more work with RAD 6. As with any new release of an IDE, new features have been added and existing ones have been improved (and changed around), so I'm running into some surprises. As I learn how to do little tricks in RAD 6, I'll try to document them here.
RAD 6, officially Rational Application Developer for WebSphere Software, is the successor to WebSphere Studio Application Developer. RAD 6.0 is basically WSAD 6.0. Whereas WSAD 5 is for developing apps for WAS 5 (and WAS 4), RAD 6 is for developing apps for WAS 6 (and WAS 5, and I think WAS 4). Whereas WSAD 5 is built on Eclipse 2, RAD 6 is built on Eclipse 3.
If you don't already have it, you can download a trial copy of RAD 6 to try it out. DeveloperWorks also has a zone to learn more about RAD 6.
Bobby Woolf: WebSphere SOA and JEE in Practice
What's the difference between interoperability and integration?
I found this question in "Outstanding questions regarding BPEL and ESB" on the Richard Brown's Gendal World blog. Richard Brown is an ISSW coworker of mine in the UK and, from what I hear, quite smart. (Then again, he says he reads my blog. But maybe he's still smart anyway!) His blog is really good, BTW. Richard gets the question from James McGovern in a post with the same title, "Outstanding questions regarding BPEL and ESB."
So, what's the difference? Wikipedia says "Interoperability: the capability of different programs to exchange data via a common set of business procedures, and to read and write the same file formats and use the same protocols" and "Integration allows data from one device or software to be read or manipulated by another, resulting in ease of use." Yuck, those aren't much help.
To me, interoperability means that two (or more) systems work together unchanged even though they weren't necessarily designed to work together. Integration means that you've written some custom code to connect two (or more) systems together. So integrating two systems which are already interoperable is trivial; you just configure them to know about each other. Integrating non-interoperable systems takes more work.
The beauty of interoperability is that two systems developed completely independently can still work together. Magic? No, standards (or at least specifications, open or otherwise); see Open Standards in Everyday Life. Consider a Web services consumer that wants to invoke a particular WSDL, and a provider that implements the same WSDL; they'll work together, even if they were implemented independently. Why? Because they agree on the same WSDL (which may have come from a third party) and a protocol (such as SOAP over HTTP) discovered in the binding. How does the consumer discover the provider? Some registry, perhaps one that implements UDDI (which sucks, BTW). So SOAP, HTTP, WSDL, UDDI--all that good WS-I stuff--make Web services interoperable.
Another example I like is the "X/Open Distributed Transaction Processing (DTP) model" (aka the XA spec); see "Configuring and using XA distributed transactions in WebSphere Studio." With it, a transaction manager by one vendor can use resource managers by other vendors. Even though they weren't all written for each other, they still work together because they follow the same spec. They're interoperable.
Now consider two systems that weren't designed to be interoperable, or perhaps interoperable but with different specs. This requires integration. The integration code--could be Java, Message Broker, etc.; I co-authored a whole book on this--takes the interface one system expects and converts it to the one the other system provides. This is why WPS has stuff like Interface Maps and Business Object Maps.
So, you want interoperable systems; integrating them is simple. Otherwise, you have to integrate them yourself.
I'm documenting tricks in RAD 6 and WAS 6. Let me clarify the relationship between the two.
RAD is a development environment (an IDE) from Rational for developing J2EE applications. WAS, from WebSphere, is an implementation of the app server part of the J2EE specification, which you use to deploy and run J2EE applications. You don't need one product to use the other, but they work great together.
RAD includes a test server environment for deploying and testing your applications while you develop them (instead of waiting for your customers to do it!). This test server is a full-blown WAS server. It's not licensed for production use, but it works just like WAS because it is WAS. Whereas WAS is installed in the
This also answers Bill's question: If you have RAD installed is there any reason to also install WAS? (Bill knows the answer; he's just reminding me to give you the answer.) RAD contains a full WAS install for testing purposes, so about the only thing you really need a separate WAS install for is production. To perform load testing and failure scenarios, you really need a set of server computers and software (web and application servers, database servers, LDAP, firewalls, etc.) that mirror your production environment as closely as possible, so RAD (or any single WAS Base install) is definitely inadequate for that. But RAD is perfectly adequate for unit, function, and end-user testing.
The main place where RAD meets WAS is the Servers view in RAD that let's you start and stop servers, etc. Those servers, as long as they're of type "WebSphere v6.0 Server," are WAS 6 servers. The key connecting point is that you can add a RAD Enterprise Application project (an EAR file) to a test server. This way, when you change the code in the project, the new code is automatically deployed to the server (although you usually have to restart the project or the server for the changes to take effect).
Notice that in RAD 6, you can also create a WAS 5.0 or 5.1 test server. This lets you replace WSAD 5 with RAD 6 and start using the latest tooling even if your team is still deploying on an older version of WAS.
The test server in RAD is WAS Base. RAD also has some support for testing WAS ND (Network Deployment), the clustered configuration of WAS which is what most customers actually use.
So for the most part, when I (or anyone else) explain how to do something using a RAD test server, you can also do the same thing from the command line using a WAS install, and vise versa.
I'm documenting RAD 6 issues. There's a new version available, 184.108.40.206, and some interim fixes for it.
RAD has a feature called the Product Updater which finds and installs the latest patches. To run it, from the main menu, select Help > Software Updates > IBM Rational Product Updater. It runs in a separate window and JVM. The first tab, Installed Products, shows what you've got now. The second tab, Updates, shows what's available to install. For example, mine shows that 220.127.116.11 and Interim Fix 002 are available. If you select an update, the Detailed Information pane shows what's in the update.
IBM Rational Product Updater
You can also download and install patches manually, which is necessary if you're running RAD on a machine that doesn't have an Internet connection. Unfortunately, there doesn't seem to be a master "Recommended Updates" document for RAD like there is for WebSphere Application Server, so it's a little more of a challenge to keep up with the latest patches. Two good places to look are the RAD support page and the Rational Developer V6 products page on developerWorks.
Here are the latest patches (currently):
I'm documenting tricks in RAD 6. In Part 1, I explained how Activation Spec is replacing Listener Port for configuring MDBs, and gave some J2EE-spec-based guidance on which approach to use when. Here is some additional advice that is more specific to WAS 6.
In the WAS 6 docs, "Creating a new listener port" recommends that you should upgrade your EJB 2.0 MDBs that use Listener Ports to EJB 2.1 MDBs that use JCA adapters (and therefore Activation Specs). It strikes me that this advice is a little bit empty because your EJB 2.0 MDBs are using a JMS provider, so you can't update to Activation Specs until your messaging system vendor updates their JMS implementation to use JCA. Nevertheless, the advice still holds that if you can update your MDBs to 2.1 and Activation Specs, you should do so and quit configuring your WAS servers with Listener Ports.
Also in the WAS 6 docs, "Administering support for message-driven beans" explains what type of configuration to use with the supported JMS provider types:
It goes on to say that Activation Specs must be used with any MDBs that use JCA adapters. So, the JMS API implementation for (V6) Default messaging is apparently implemented using JCA and therefore requires Activation Specs. The JMS impls for the other providers apparently do not use JCA and therefore require Listener Ports. If and when those other providers are upgraded to JCA, then you'll be able to use Activation Specs.
Which brings to mind another question:
If a JMS provider is implemented using JCA, then you can configure the MDB connection as JCA using an Activation Spec, or as JMS using a Listener Port. Which should you use?
Just for fun, I implemented an EJB 2.1 MDB in RAD 6 to use (V6) Default messaging, but instead of using an Activation Spec, I configured its connection using a Listener Port (which specified a connection factory and destination that were configured in the default messaging provider). When I tried to run this configuration, the server started with no errors. But when I deployed the app and the server tried to start the EJB jar, I got this
WMSG0063E: Unable to start message-driven bean (MDB) MyExampleMDB against listener port MyExampleQueuePort. It is not valid to specify a default messaging Java Message Service (JMS) resource for a listener port; the MDB must be redeployed against a default messaging JMS activation specification.
So when configuring an MDB that listens for messages from the default messaging provider, there's nothing to stop you from using a Listener Port instead of an Activation Spec. But WAS will refuse to run the app. So I guess that's how you'll know when you need to convert your Listener Ports to Activation Specs.
This presents a bit of a dilemma, though. When you're developing an MDB, you're not supposed to know where the messages/events are really coming from. The configuration of the Activation Spec or Listener Port effectively hides this from you and makes it part of the deployment configuration. You just have to know that there'll be a resource in the deployment server with the expected resource name. But now you also have to know whether or not the source will be accessed through a JCA adapter, and therefore whether to configure it with a Listener Port or an Activation Spec. This makes your code, or at least its configuration, a bit less flexible.
For example, if you design your MDB to use WMQ, then you'll need to specify a Listener Port that the deployer will provide to map your MDB to its WMQ queue. But then if the deployer decides to use WAS 6's Default messaging instead, now he'll provide an Activation Spec to map your MDB to its queue. But your MDB isn't configured to use an Activation Spec, it's configured to use a Listener Port. The deployer will need to go modify the
I'm documenting tricks in RAD 6. Something that's changed since WSAD 5 is the concept of a test server and how to create one.
WSAD had the Server perspective. That has been simplified in RAD 6 to the Servers view. The single item in the list of servers is the default WAS 6 test server called "WebSphere Application Server v6.0." New > Server gives you a dialog that creates a new item in the server list. However: Whereas in WSAD this was a separate server that could be started and stopped independently of other servers, in RAD this new server is really just an alias to the server you already had (assuming both servers are for the same type (WAS 6) and profile (default)). Because the two "servers" in the list are aliases to the same server instance, they start together, share the same configuration, etc.
Here's how to create a new separate sever (not just an alias): First, you need to create a new profile. In a file browser (on Windows), find this file and run it:
Once you've created the profile, go back to RAD and open the New Server dialog again. Select the same server type (WAS 6) but specify your new profile (MyProfile) and its SOAP connector port (8881).
When you're done, you'll have a new server (not just an alias) that you can start and stop separately from the other servers, config independently, etc. Since each profile has different ports, you can even run two servers at the same time.
Thanks to Roland Barcia for his help in figuring out how to do this.
A reader recently asked: Which web sites (if any) do you frequent to keep up with Java goings-on?
Hmm, that's a good question. Here are a couple you might want to check out.
I do a lot of my learning by reading books, so one of my very first blog postings was What You Should Be Reading. This is a theme that has come up a number of times in my blog, so Google for that. Likewise, check out a frequent recommendation of mine, the ISSW Recommended Reading List, which is mostly articles and web sites, not books, so that they're freely and immediately accessible.
The reader proposed one possibility for a good web site to learn about Java: The Server Side. I tend to find The Server Side to be kind of a super market tabloid of a Java news site; more interested in shocking than educating. There, I've said it, let the hate mail begin. (sigh) When I peruse The Server Side, what I find is lots of announcements for new versions of frameworks I've never heard of, which doesn't make me feel more knowledgeable about how to use Java. To anyone who wants to defend The Server Side: What would be useful is for you to highlight sections of the web site for learning about Java, and thereby prove what a good educational site it is; I'd like to know.
There are other Java web sites which tend to be educational and helpful. My collegue Kyle Brown publishes and comments occasionally on JavaRanch, which seems to actually have informative articles. Along the same lines, jGuru seems good. A performance-specific site is Java Performance Tuning; a similar site is Precise Java. (Also in the Google list of Java performance sites is one called Nawa Shibari, but judging from the root page, I'd say it seems to be something very different! Is this where Java performance enthusiasts go when they're not tuning Java?!)
OnJava is O'Reilly's take on things. Javalobby is kind of the closest thing Java has to a political action committee. And finally, at the risk of simply endorsing my own employer, there are lots of good articles in the developerWorks' zones on Java, WebSphere, WebSphere Application Server, IBM WebSphere Developer Technical Journal, Rational Application Developer (and the older WebSphere Studio zone), and so on.
That should give you some stuff to browse for a while. Hope you find it helpful.
Aug 23 Update:
Another helpful site is java.net, run by Sun as a newsie addition to the main Java Technology site.
A reader asked: Is IBM going to release Rational Application Developer 6.1? Is RAD 6.1 available now?
The question appears as a comment on WebSphere Application Server V6.1 Announced. IBM_RAD_Customer asks:
I can't use RAD 6.0 to build applications for Websphere Application Server 6.1
Yes, RAD 6.0 does not know how to develop code for the new features in WAS 6.1, such as the new Java language features in J2SE 5.0. To develop code for those features, you'll need to use the Application Server Toolkit (InfoCenter), which is included with the WAS 6.1 install.
The latest version of RAD is
My personal opinion (because I use our products too): I wish we (IBM) would have a corresponding WSAD/RAD release for each new WAS release. We had that for 5.0, 5.1, and 6.0, which really helped development teams upgrade their environments and hit the ground running with the latest releases. But there is apparently no RAD 6.1 to go with WAS 6.1. If you wish we had RAD 6.1 so you could buy it, that's a missed sales opportunity for us, one that you might want to communicate to your IBM WebSphere/Rational salesperson, whom I'm sure will be glad to communicate this back to Rational's marketing along with actual customer names and estimates of missed sales.[Read More]
Why are declared interfaces important?
Declared interfaces, like clean air and clean underwear, are easy to take for granted until you don't have them. I used to do my OO programming in Smalltalk, which is a great language; but one deficiency I always felt (and this is heresy for a Smalltalker to say, but I'm saying it anyway) is the runtime binding--what I came to think of as extremely weak typing. Smalltalk variables had no declared type/class, so practically any code with correct syntax would compile. It wasn't until runtime, when a client invoked a message on an object, that the environment determined the variable's object's class and looked at the class to see if it implemented a method with that signature. So you didn't really know if your code worked until you ran it, and you got lots of runtime errors that finally uncovered your simple programming mistakes.
I always thought there had to be a better way, and I discovered one in Java: interfaces. An interface is a contract between an object and a client using the object. The object promises to implement methods with these signatures, and the client promises to only invoke messages with these signatures; the object's class can implement those methods any way it wants to, and the client can depend on the signatures not changing even if/when the implementation does. New classes that didn't exist when the client was written can nevertheless work properly for the existing client simply by implementing the agreed-upon interface. Different implementations (classes) are interchangeable not because they coincidentally happen to implement some common set of signatures, but because they declare that they implement the same interface. (This interface vs. implementation thing also makes the distinction between abstract and concrete classes much more meaningful.)
Data can also suffer from weak typing. For the generator and consumer of some data to exchange it successfully, they have to agree on the format. When they don't agree, either the consumer derails with parsing errors, or worse yet proceeds (seemingly successfully) with incorrect data. When data exchange problems are detected, the developers fall into a blame game: "Your generator code is producing incorrectly formatted data." "No, your parser code can't parse the correctly formatted data." Resolving this dispute can be difficult.
XML does for data what Java interfaces do for code: It strongly types the data by declaring its schema (much like the DDL for a relational database schema). XML data has to be well formed to be parsed. It can also be valid, meaning that it fits the agreed-upon data structure. That structure is declared in an XML schema which the XML data is validated against. So when the consumer of some XML data can't consume it successfully, the development teams have a much more objective and less political means to determine where the problem is: a validating parser. Either the XML data validates against the schema--in which case the consumer has a bug--or it doesn't--in which case the generator has a bug (or the data validates yet the consumer finds flaws in it, in which case the schema needs to be improved). The schema is definitive (at least to the limits of a schema's ability to capture a program's intent), and is declarative so that it can be used by a variety of parser implementations. I like this idea so much that I tend to believe that almost all XML data should be validated before or as part of being consumed, or better yet, before even being sent (no use taking up bandwidth transmitting invalid data). (For example, see Validating XML in WAS and The Message Validator Pattern.)
I see SOAP and WSDL as making Web services strongly typed. A SOAP message is an envelope whose payload is an XML document, and that document should have a schema it can be/is validated against. WSDL declares an interface the way a Java interface does, and (usually) declares the incoming parameters and outgoing return types as XML documents with schemas the messages can be/are validated against. This helps ensure that a consumer and provider implemented independently still work together. And when there's a problem, it helps narrow down where the problem is: either the consumer invoking the service isn't conforming to the WSDL properly, or the provider implementing the service isn't. That doesn't fix the problem, but it tells you who needs to fix it.
So declared interfaces are a good thing, both for code and data. Can we agree on that?[Read More]
The latest version of WebSphere Application Server, v6.1, is now available.
Check out the press release from the announcement back in April, "IBM WebSphere Application Server V6.1 delivers flexible, secure infrastructure to provide a reliable foundation for your Service Oriented Architecture." For details of the announcement, see WebSphere Application Server V6.1 Announced. One of the main differences is that WAS v6.1 runs in Java SE 5 (see IBM Java Developer Kits: Java 5 SE) whereas WAS v6.0 runs on J2SE 1.4; both WAS v6.0 and v6.1 implement J2EE 1.4.
There are the usual Base, ND, and z/OS editions. (How many J2EE app servers run on mainframes?!) There's now v6.1 documentation, including the v6.1 InfoCenter.
If you're a Passport Advantage member and licensed for the latest releases, you should be able to download WAS 6.1 now. (If you're a WAS customer/client, can you confirm that WAS 6.1 is now available for download? Please add a comment.)[Read More]