I hope this posting doesn't come off sounding too much like I'm doing IBM's sales and marketing for them, but if you're sensitive to that sort of thing when you're expecting technical information, be warned that this posting is about IBM's business, not its technology. The reason I'm posting is that as I learn more about how IBM is put together, I find that I better understand what its various products are and how they fit together. So I'll try to pass on some of this knowledge to you.
I work in the IBM Software Group
. As much as I'd like to think that software is the entire company, it's only one group in IBM, but perhaps the part that you're most familiar with--the part of IBM that makes and sells software products. This is in contrast to other parts of IBM, like Global Services
that'll do IT
for you, IBM Hardware like servers
, and IBM Research
that does our basic science. IBM Software doesn't do end-user applications, but rather provides the foundations that applications can be built on.
IBM Software consists of five brands:
|Information management: software for storing application data|
These are the database products like DB2, IMS, Informix, and Cloudscape. And here's an interesting product: IBM Electronic Media Management System (EMMS).
|Collaboration tools: software that'll make you work with your colleagues|
These products include the groundbreaking Lotus Notes, which uses the Lotus Domino server, Lotus Sametime, and IBM Workplace.
|Software development tools: software for building applications|
Rational has tools for architects and developers, tools for SCM, testing tools, and so on. They even still support Ada. (Is Ada still used? Guess so.)
|Management software: software for monitoring applications|
Tivoli has products for security like Tivoli Access Manager, storage management like IBM Tivoli Storage Manager for Application Servers, and systems management like IBM Tivoli OMEGAMON XE for WebSphere Application Server.
|Middleware for application infrastructure and integration: software for running applications|
This includes servers like WebSphere Application Server and WebSphere Portal, application integration like WebSphere MQ and WBI Message Broker, and business integration like WBI Server Foundation and WebSphere InterChange Server.
So the idea is:
|Build||You develop your applications using Rational products.|
|Deploy||Your applications run in/on/using WebSphere products.|
|Manage||Your applications store and manage their data using DB2 products.|
|Monitor||You monitor your applications while they're running using Tivoli products.|
|Collaborate||You collaborate with your co-workers using Lotus products.|
So hopefully this provides a little clearer description of how the software brands relate.
HP has named its new CEO, Mark Hurd
, formerly CEO of NCR
Hurd replaces Carly Fiorina, who left HP six weeks ago: Carly Fiorina steps down as chairman, CEO of Hewlett-Packard
In related news, it looks like Hurd won't break up the company: Analysts: Hurd likely to keep HP whole
(ZDNet). Hurd generally seems to be regarded as a good choice: HP's Hurd mentality
(CNN); NCR's stock dropped
(Reuters) when they announced his resignation.
We have a new developerWorks blogger, Ali Arsanjani, with his Best Practices in Service-oriented Architecture
blog. Ali is IBM Global Service's chief architect for SOA and the author of an article I recently talked about, How to identify, specify, and realize services for your SOA
. So, if you'd like to learn more about SOA, check it out.
An ongoing question is, "Where can I learn more about WebSphere products?" One place is the WebSphere Redbooks Domain
WebSphere Redbooks Domain helps you find the Redbooks that pertain to WebSphere products
. IBM Redbooks
is another effort by IBM, like developerWorks
, to get expertise out of employees' heads and into customers' hands (so to speak). Redbooks are books written by IBM employees and partners on new technologies and products to help customers get started faster and achieve greater success. IBM distributes them for free as HTML pages and PDF files; you can also order them as books or CD-ROMS.
You can also search the site for books on a particular topic, such as books on WebSphere Application Server V6
. To find out about new WebSphere Redbooks as they become available, subscribe to this WebSphere Redbooks RSS feed
A couple of good Redbooks on WAS 6 and RAD 6:
For more thoughts on where to go for info:
IBM likes to say that an Enterprise Service Bus (ESB) is a pattern
, not a product. I've come up with an annology that I think is much more useful.
When we say that ESB is a pattern ("IBM Info on ESBs
"), not a product, what we mean is that you can't just buy an ESB v1.0 product, install it, and boom--you've got yourself an ESB. Having said that, you can do this with an app server (we prefer that you buy WAS 6
), and building enterprise apps is a heck of a lot easier if you have a J2EE
app server to deploy them into. Likewise, I expect the industry will eventually have some ESB standard (like J2EE) where you'll buy something like WebSphere ESB v1.0 and what you'll get is a glorified messaging system
(based on WebSphere MQ, WBI-Message Broker, and/or the WAS 6 Service Integration Bus) that makes it a heck of a lot easier and standard to integrate the parts of a service-oriented architecture (SOA) than those products do today. (See ESB vs. Message Bus
and Service Integration Bus
.) But you still have to develop an integration solution that is custom to your enterprise, like a J2EE application; any out-of-the-box ESB product is like a J2EE app server, an environment for running your solution. (You'll probably also want some ESB building tools, the equivalent of RAD
So do you understand that's what we mean when we say that ESB is a pattern, not a product? I wonder.
I think a good anology is that an ESB is like a network of roadways connecting a group of cities.
(The whole "information superhighway
" anology/hype all over again? I hope not; bear with me.)What makes roadways like an ESB?
- Custom -- Roadways must be custom designed and built; they don't just roll off an assembly line. They have to follow the contours of the land and handle obstacles with specialized structures like bridges and tunnels. The shortest route would be a straight line, but highways tend to wonder from city to city to connect as many as possible. Heck, the on- and off-ramps to an Interstate/freeway are rather similar to the adapters we use to connect non-messaging applications to messaging systems. The cloverleaves that form at an intersection of Interstates are not unlike message routers. This all has to be custom designed; every solution is different.
- Evolving -- As long as a roadway is in use, it's never done. Besides repairing potholes, the requirements keep changing. Roads must be made wider to handle more traffic. New on- and off-ramps are added. Obstacles are removed so that connections can be made. As long as it's useful, you just keep trying to make it more useful.
Linn Cove Viaduct on the Blue Ridge Parkway
So it goes with ESBs. Your enterprise's ESB is going to be different from the other enterprise's ESB. And you're always changing your ESB around to make it better: adding new services, adding new service providers to increase throughput, adding notifications for new kinds of events, getting rid of ones that no one uses any more, etc.ESBs are custom and evolving. That's why they're a pattern, not a product.
(But I still think there are (see ESB*?
again) and will be products that serve as the foundation for building and running ESBs. If these are not ESB products, what are they?)
The developerWorks team is running a survey to learn what our readers (and you are one, right?) think about our blogs. We hope to use this info to help make the blogs better and easier for you to use, to find out what features and functions you would like to see on our site. The survey should take less than ten minutes to complete. So if you're interested, please go to developerWorks Survey
. Thanks for your help.
I'm documenting tricks in RAD 6
. Something that's changed since WSAD 5 is how you configure a test server.
In WSAD, in the Server perspective, you could select a server and open its server configuration editor
. This editor has pages for setting up the server's classpaths, data sources, JMS provider, etc.
RAD no longer has a separate server configuration editor. Rather, to configure a RAD 6 test server, you use the same administration console
you use to admin a WAS deployment server. A RAD test server is a full WAS server, so administration works the same. This way, you don't have two models for how to admin a server, one for test servers and another for production; you use the same admin console for both.
So to admin a RAD test server: In the Servers view, select the server and start it. Once it's started, pop up the context (e.g. right mouse button) menu and select "Run administrative console." RAD opens a Web browser view containing the admin console. (Or in your own Web browser, go to http://localhost:9060/ibm/console
. See Starting and stopping the administrative console
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:
- Default messaging (V6) -- Activation Spec
- WebSphere MQ -- Listener Port
- Generic -- Listener Port
- V5 default messaging -- Listener Port
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.
WMSG0019E: Unable to start MDB Listener MyExampleMDB, JMSDestination jms/ MyExampleQueue : com.ibm.ejs.jms.listener.MDBInvalidConfigException: Cannot deploy an MDB against a listener port specifying a default messaging JMS resource
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
file that specifies what Listener Port or Activation Spec an MDB uses (see the MDB section of "Application bindings
"). At least the deployer only needs to change a deployment descriptor and not change (and recompile) code. But to avoid needing to make this change, you'll need to decide what messaging system your MDB will use before you set its binding at development time.
I'm documenting tricks in RAD 6
. Something that's changed since WSAD 5 is how a message-driven bean
(MDB) is mapped to its destination/endpoint.
This is an issue with both RAD 6 and WAS 6, having to do with an improvement to MDBs in EJB 2.1/J2EE 1.4, which WAS 6 implements. The improvement enables MDBs to accept events from any resource with a JCA 1.5 adapter, not just JMS. For a good discussion of this new feature in EJB 2.1, see "EJB 2.1 The Enhanced Message-Driven Bean
The EJB 2.0 spec is purposefully vague on how an MDB maps to the source of its events; it's up to each vendor. WAS 5 invented the Listener Port
, which specifies a JMS connection factory and destination. That's enough info for a pool of MDB instances to be able to connect to the messaging system and listen to the designated destination. EJB 2.1 is no more specific, although it now specifies the additional requirement of an MDB working with a JCA adapter. How the MDB maps to the adapter is still unspecified; JCA uses an Activation Spec
, although that's an interface, so it's still up to the adaptor vendor to implement it.
When doing development with RAD 6 (or any other IDE for WAS 6), this leads to some questions:
- Should I use a Listener Port or an Activation Spec?
- Should I convert my existing Listener Ports to Activation Specs?
- If I keep using Listener Ports, will they eventually not be supported anymore?
The answers are not as simple as yes or no, but here are some guidelines to help you decide:
- J2EE 1.2/EJB 1.1 (WAS 4) -- Not applicable. There are no MDBs, so don't worry about it. (WAS 4 has message beans, but they're not EJBs.)
- J2EE 1.3/EJB 2.0 (WAS 5) -- Listener Port. All MDBs are JMS MDBs, so they all implement MessageListener and there is no JCA support. WAS 5 uses Listener Ports to associate an MDB class with its JMS destination; see "How MDB listeners work with a listener port in WebSphere Application Server."
- J2EE 1.4/EJB 2.1 (WAS 6), Connector MDB -- Activation Spec. A connector MDB uses JCA to access its resource, and thus the connector must be configured with an Activation Spec. This is new bean development, though, so it doesn't affect converting EJB 2.0 MDBs to EJB 2.1 MDBs.
- J2EE 1.4/EJB 2.1 (WAS 6), JMS MDB -- Depends. In J2EE 1.4, the JMS 1.1 API can now be implemented with the JCA 1.5 API (although this doesn't seem to be a requirement); see "Change to JMS Sessions in J2EE 1.4." So the question is whether or not your JMS provider's API is implemented with JCA. If so, your MDB will be a JMS MDB that is actually implemented as a connector MDB, and so is configured with an Activation Spec. If not, then this is the same JMS case as in J2EE 1.3 and you configure this EJB 2.1 MDB the same way you would an EJB 2.0 MDB, which in WAS is to use a Listener Port.
So, in WAS 6, whether you use a Listener Port or an Activation Spec depends on whether you upgrade your EJB 2.0 MDBs to EJB 2.1, whether you want your EJB 2.1 MDB to use a JCA adapter, and whether you access your JMS provider via a JCA adapter. As long as there are JMS API impls that don't use JCA, WAS will need Listener Ports; once all JMS API imples use JCA, Listener Ports won't be needed anymore.
I'm documenting tricks in RAD 6
. Something that's changed since WSAD 5 is that test servers are now shared by workspaces.
Thanks to Wayner for reminding me of this
In WSAD 5, each new workspace had its own servers. So if you wanted to have two servers with very different configurations, one way to accomplish this was to setup each server in a different workspace.
In RAD 6, the workspaces share the servers. So even if you start a new workspace, you still have the same servers. Combined with the fact that New > Server really just creates an alias to the same server (if it has the same profile), this makes it really difficult to create another server: New > Server doesn't work, a new workspace doesn't work, etc. For how to create a new server that's actually independent and separate from the ones you already have, see How to Create a Server
So just keep in mind that workspaces share servers. When you change the configuration of a server in one workspace, or delete a server, or create a new one (a truely independent one or an alias), you're doing so in all other workspaces as well.
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:
. This starts an InstallShield wizard that is the the Profile creation wizard
. Enter a profile name such as "MyProfile", add it to the profiles directory, use your node and host, and let it increment the ports so that they won't conflict with your other profiles. Make a note of the SOAP Connector port (such as 8881); you'll need it later.
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.
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
is a site run by Bill Hahn, an IBM employee that works in our Sales & Distribution organization
. WebSphere Central contains links to lots of useful presentations, tutorials, and downloads that you can use for learning more about IBM products. For example, he links to a handbook he wrote that shows how to use the JSF tools in WSAD v5.1.1
, and links to a list he's compiled of presentations and demos for various WebSphere and Rational v5 and v6 products
. He updates the site from time-to-time with new materials, so keep an eye on it.
In WebSphere Extended Deployment (XD)
, one issue I didn't address is:
Why is it called WebSphere XD? Why not WAS
I even said, "[WebSphere XD] is a J2EE app server unlike any other on the market..." Well, it's not exactly a J2EE app server.
WebSphere XD is not so much an application server as it is an environment for running application servers. It doesn't run the applications, it runs and manages the application servers that run the applications. So far, the app server it manages is one or more WAS ND
(Network Deployment) server clusters. You can think of this as XD being built on top of ND, but really XD manages ND, and therefore whatever's running inside of ND.
What makes this distinction important is that it means that WebSphere XD should eventually be able to support other J2EE-based WebSphere products
like WebSphere Portal Server
, WebSphere Business Integration Server Foundation
, WebSphere Commerce Server
--anything built on top of WAS ND.
WebSphere XD isn't just a new product in the WebSphere product line, it's one that over time will probably impact much of the rest of the product line, much like WebSphere Application Server itself.
IBM has a new product, WebSphere Extended Deployment
), that I've been meaning to talk about for a while now. It's a J2EE app server unlike any other on the market, and I think it really raises the bar on what we'll come to expect from an app server.
WebSphere XD is designed for a site that wants to be able to run multiple applications in a cluster of application servers and ensure that some of those applications run really well, even in high-load situations--even if that means making the other applications run not as well because of insufficient overall capacity. It helps take the guesswork out of deciding how much hardware will be needed to meet demand and adjusting the allocation of applications to meet peak demand; XD makes sure that whatever hardware you have is used optimally according to the criteria you configure.
WebSphere XD takes a lot of developments in autonomic computing
and grid computing
and applies them to WAS. (See The Future of Computing: Pervasive, Autonomic, and Grid
.) Like these emerging technologies, XD is a rather complex product that does a lot of different things and could take forever to discuss thoroughly. Since I don't have that long, here's an overview of five of the main capabilities that XD gives you:
- Dynamic Operations -- You define the response time goals that an application must meet. If an app is not meeting these goals, XD will start more copies of the app in underutilized servers and spread the client load, improving the performance clients receive.
- Prioritization -- You weight applications to indicate their importance. When an important application isn't meeting its response time goals, XD takes resources from less important applications and uses them to make the more important applications run better.
- WebSphere Partitioning Facility (WPF) -- A database can be partitioned to spread the load of different kinds of database users onto different servers. With XD WPF, you partition an application so that those different database users get sent to different app servers. XD runs each app partition only once, so that it's the only user of the data partition and can safely cache data from the database.
- Health Monitoring -- You define the normal operating range of an app server. XD detects if an app server falls outside that range, and if so, takes corrective action such as safely shutting down and restarting the server and its apps.
- Visualization -- Enables an administrator to see peformance statistics for all of the app servers in a cluster and drill down into details on an individual server. Enables you to spot servers that aren't running properly before they start causing problems.
Here's how the products in the WAS family compare:
- WebSphere Application Server (WAS Base) -- An implementation of the J2EE specification that provides a single application server (a.k.a. single J2EE container), running in a single JVM, for deploying and running one or more J2EE applications.
- WebSphere Application Server Network Deployment (WAS ND) -- Runs J2EE applications in a cluster of application servers (where each one is essentially a WAS Base server). WAS ND provides workload management (WLM) for load-balancing of client requests across the app servers in the cluster, and high availability is achieved through failover of client sessions between app servers in a cluster. Each app server is essentially identical, capable of running any of the cluster's applications; therefore a client request can potentially be fulfilled by any of the app servers.
- WebSphere Extended Deployment (WebSphere XD) -- Enables each application server in the cluster to be managed uniquely, so resources can be used where they're needed most. Declarative and programmatic policies configure how to optimize the resources and what tradeoffs to make. An application can run in a single app server and still have high availability--the entire application and all of its client sessions will failover to a new app server. Since different app servers run different applications, XD routes client requests more specifically.
The initial version of WebSphere XD is 5.1, which is built on WAS ND 5.1. Although WAS 6 is now available, WebSphere XD V6 is not yet available.
Here are some resources where you can learn more:
Starting next month, Kyle Brown
and I will have a series of articles exploring WebSphere XD in detail.