WebSphere Enterprise Service Bus v6.0.1 is now available.WebSphere Enterprise Service Bus
(WESB) is a new product that implements (IBM's take on) the ESB pattern
. There's a general marketing overview
(PDF) and a set of PDF documentation
. The InfoCenter docs are a part of the WebSphere Business Process Management InfoCenter
, which includes docs for WebSphere Process Server (WPS) and WebSphere Integration Developer (WID) as well.
The WESB release coincides with new v6.0.1 releases of WPS and WID. The v6.0 versions of those products were released
back in September 2005. The v6.0 numbering can be a bit misleading; rather than these being the sixth major release of these products, this is actually the first (essentially v1.0). The version 6 numbering coincides with the numbering of the current versions of WebSphere Application Server
and Rational Application Developer
. v6.0.0 is the first release of WPS and WID; v6.0.1 is the first release of WESB.
Raleigh, North Carolina has made Forbes' list of the richest cities in America at #7. It's also the #13 most literate city.Raleigh
is the biggest city in North Carolina's Research Triangle
that includes the Research Triangle Park
. IBM, including the Software Group
that helps produce WebSphere and Rational products, has a large presence
and long history
in the Triangle.
The Forbes article is "Richest Cities In The U.S.
" Raleigh is #7 in terms of income. Another publisher has picked up the story and shows a helpful summary table
. Raleigh's median income is $47,878, and its median home price is the lowest in the list at $185,200. Other cities in the list are San Jose and San Francisco and Seattle, Washington and Virginia Beach, Anchorage and Honolulu.
In a seperate but perhaps related story, Central Connecticut State University has published a list, "America's Most Literate Cities
." The study ranks cities by indicators of literacy: "newspaper circulation, number of bookstores, library resources, periodical publishing resources, and educational attainment" as well as Internet use. Raleigh ranked at number 13
. The study, and Seattle's #1 ranking, is discussed in "Seattle reaches literacy peak
What are the set of products that go together to create WebSphere Integration Developer and how do they fit together?
I've already talked about The WebSphere Process Server Stack
. Now let's consider WebSphere Integration Developer
, part of the WebSphere Business Process Management
suite and the main IDE
for WebSphere Process Server
and WebSphere Enterprise Service Bus
. Where does WID fit in with the other IDEs?
Like last time, I have a crude diagram I drew myself that shows the parts.
The WebSphere/Rational IDE v6.0 Stack
OK, very impressive; what's that mean? The stack works like this:
Notice that WID is not built on top of RAD; they're seperate and designed for two different types of developers. RAD is for application developers whereas WID is for integration developers, the people who design how apps will fit together and talk to each other. IBM expects these to be different people with different skill sets and thus needing different tooling. For developers with both application and integration skill sets that wish to do both, you can buy both RAD (or RSA) and WID and install them in the same Eclipse install so that you'll have one large IDE with both sets of tooling.
WID is the IDE for developing "applications" (really SCA modules
) deployed into WPS and WESB.
What's wrong with requirements? Why are use cases better?
Yesterday I talked about how use cases aren't just for user interactions anymore
. I see them as being useful for documenting how services work
, and even how your business works
. Seems to me that anytime one thing uses another thing, you can describe the interaction with use cases.
So whatever happened to good old requirements? I don't know, but I never liked them, I don't use them, and I'm glad. I remember requirements like (if I'd been working on e-commerce
apps 10 years ago) "must be able to add a product to the shopping cart" and "must be able to check out." These things would go on for pages, usually you'd end up finding two requirements twenty pages apart which directly contradicted each other, and you'd end up needing requirements lawyers to interpret the darn things. The worse part was that when the users and developers agreed to a final set of requirements, neither side really knew what they were agreeing to and probably had very different ideas in mind.
|Use cases are much more, well, useful. They describe different ways the users will use the app (or consumers will use the service, or customers will use the business, etc.). Customers and developers can actually understand what's being described and actually have the same idea in mind how the app will work (at least until you start mocking up the GUIs). This is because you're describing not what the app will do, but how users will use the app. It puts the focus back on the user and what the app will do for them.|
All is not perfect, though. Use cases often become too dang complicated too quickly. When your template has ten or twenty sections, that's too hard. The use case is supposed to be about what works right, yet too many get too lost describing preconditions, post conditions, error paths, dependencies, inheritance, and a whole lot of other stuff that confuses more than clarifies.
Perhaps the worst thing to ever happen to use cases is use case diagrams, the things that show which stick figure actors interface with which use case ovals. People will spend forever trying to get these things right. Do they really help you understand the app any better? I've repeatedly worked with developers new to use cases that keep asking me, "Is this right?" It's supposed to be intuitive; you shouldn't have to worry about right, you should worry about useful. Is it describing how users will use the app? Then it's right enough. If not, then all the templates and diagrams in the world aren't going to help you.
Special mention goes to XP user stories
. Stories get use cases back to their basics: Tell me what it'll be like using some part of the application to perform some typical task. No template, no prereqs, no error paths ... just a simple description of how things work. If the description happens to mention what's already in place, what could go wrong, etc., fine, but that should be a natural part of the explanation, not a necessity forced by the template.
So forget requirements, use use cases. And if your use cases are getting too complicated, use XP stories. It's all about communicating and agreeing upon what you want the application to do.
IBM has announced their conferences for this year.
You can see the list of most (not all) of them at IBM Conferences & events
Here are the ones of most interest to this blog:
Enterprise Integration Patterns
is #2 on a Top 10 list of enterprise books.eWeek Magazine
has a series of articles called "Pings and Packets." It seems to be kind of a blogish recap of recent news tidbits. In any event, it has started to include a list called "Amazon.com's Top 10 Enterprise Books." There are lists for December
, and October
Looking at the list, it seems to include any computer books with "enterprise" in the title. So an architect study guide and an EJB book make the list, but Core J2EE Patterns
does not. In any event, Patterns of Enterprise Application Architecture
is #1 on the list and EIP is #2. Pretty cool.
Rational IDEs are built on a foundation called the Rational Software Development Platform.
In The WebSphere/Rational IDE Stack
, I talked about how WID and RAD are both built on top of the ASTK, which is built on top of Eclipse 3.0. That's correct, but there's more to the story.
As Bill points out in his comment
, the ASTK and so on are actually built on top of what we call the IBM Eclipse SDK (IES). You can see a good picture of it in the IBM Redbook Patterns: Implementing Self-Service in an SOA environment
on page 76: "Figure 5-4 Rational Software Development Platform products."
IBM Eclipse SDK is really an internal name. Publically, we usually refer to it as the "Rational Software Development Platform." Problem is, the IBM Rational Software Development Platform
) is also the term we tend to use for the family of Rational IDE products
. So, when we use the term, are we referring to the common code base these products are built on, or the collection of products that are all built on this code base?
In any event, if I were to redraw my WebSphere/Rational IDE stack and wanted to be more complete, like Bill describes, I would show a IBM Eclipse SDK layer between Eclipse and the ASTK. This represents the stuff we add to Eclipse. Some of the parts of the IBM Eclipse SDK are optional Eclipse packages. One example is the Eclipse Modeling Framework
(EMF), which I kind of assumed was part of the Eclipse 3.0 base but which is actually an extra optional module. The EMF itself contains other parts, one of which is the Service Data Object
(SDO) framework, which is gaining acceptance
So, nothing's ever simple to explain, is it? I hope this helps.
One way to look at WebSphere Process Server is as a Russian doll architecture.
A Russian doll
(or Matryoshka doll
) is a doll which opens to contain another doll and so on. In this way, one big doll actually contains many progressively smaller ones.
I've already talked about The WebSphere Process Server Stack
, how WPS is built on top of WESB which is built on top of WAS. To be even more specific, they're built on top of WAS ND, which in turn is built on top of WAS Base.
Another way to look at this is as what we call the "Russian doll" architecture, shown here (again, my picture, not Marketing's):
The WebSphere Process Server v6.0.1 Contains Relationship
This is really just a different way of drawing the stack from before:
The WebSphere Process Server v6.0.1 Stack
What the Russian doll perspective emphasizes is that WPS has WESB built in, which it turn has WAS built in. WAS isn't just a predecessor that evolved into WESB and WPS; WAS is actually contained in them. They're running on WAS, so to speak.
This is significant for IBM because it means that we're not reinventing software servers from the ground up; we're building WPS on the proven WAS foundation. What's significant for you as a WebSphere customer is that all of your skills in administering WAS and deploying applications to it are still relevant and useful for WPS and WESB. Many WebSphere customers have invested significantly in building well designed WAS server farms; rather than needing to replace these, they can use these and build onto these to add WPS and WESB servers as well.
So WPS and WESB provide lots of new functionality, but they build on what you already know (and hopefully love) about WAS.
What is WebSphere Business Process Management?
WebSphere Business Process Management (WBPM) and WebSphere Process Integration (WPI) are two terms IBM uses for its new suite of SOA
integration servers and development IDEs. These products are:
For some of the main documentation, see the IBM WebSphere Business Process Management information center
. I've talked about these products in WebSphere Enterprise Service Bus
, WPS and WID Now Available
, and New WebSphere Integration Products
There are also some related products that aren't officially part of the WBPM suite. Rather, they're considered part of the WebSphere Business Integration suite. These products are:
For some of the main documentation on these products and others, see the IBM WebSphere Business Integration information center
There's even a hardware component to all this, the DataPower
integration appliance. DataPower is what's commonly called an application-oriented networking device, which I've talked about in IBM Acquires DataPower, AON Vendor
and Application-Oriented Networking (AON): The Future of SOA?
The January 2006 issue of IBM WebSphere Developer Technical Journal
is now available.
This month's issue has:
Lots of good stuff, so start reading up.
There's a new Insight and outlook
column in the developerWorks Architecture Zone
: "How do I translate business needs into IT requirements?
|The question this month is:|
How do I translate the business needs of my organization to IT requirements so that they can be addressed within my system architecture?
My answer is: One word: use cases (OK, two words).
I'm on a bit of a use cases kick these days. Everything starts to look like an opportunity for use cases. In this case (ugh!), my take is: Why just use use cases to model how your software app ought to work? Why not also use them to model how your whole business works (or at least ought to)? Use cases for your whole business may be excessive, so concentrate on some part of your business you want to automate and model as an SOA. The business use cases model the way the users of this part of your business (customers, employees, etc.) use the business.
This is the second article in the Insight and outlook
series. The first one is "Why and when should you choose SOA?
Like this blog
? Please nominate it--as well as your other favorite developerWorks blogs
--for the 2006 Bloggies
: The Sixth Annual Weblog Awards. Thanks.[Read More
What are the set of products that go together to create WebSphere Process Server and how do they fit together?WebSphere Process Server
, the flagship product in the WebSphere Business Process Management
suite, is built on top of WebSphere Application Server v6.0
Here's a picture to show the relationship. I drew it myself, so it's really bare bones because I don't draw well, and so that no one will mistake it for an official item from WebSphere marketing.
The WebSphere Process Server v6.0 Stack
Now the latest version of WPS, v6.0.1, is built on top of WebSphere Enterprise Service Bus
v6.0.1, which is built on top of WAS v6.0. So it looks like this:
The WebSphere Process Server v6.0.1 Stack
Thus you can deploy J2EE/WAS apps to WPS or WESB just as if you're deploying them to WAS because, in fact, you really are. For that matter, you can deploy WESB apps to WPS. The products are built on top of each other, so the more basic products are really inside the more sophisticated ones.