A colleague recently asked me where to find out about IBM's take on what an ESB
is. I figured, why not make a blog entry out of it? So here it is.
First, so far at least, there is no single definition
IBM always uses (nor one the industry agrees on). Here's the definition from our executive's guide
An ESB enables software applications running on different platforms, written in different programming languages and using different programming models to communicate with each other, without requiring expensive, time-consuming reengineering.
Second, IBM's general company line is this: ESB is not a product, it's a pattern.
(By my standards, a very broad pattern; an architecture++ level pattern that spans multiple applications across an enterprise and even between enterprises.) It's more about the goals achieved and the way multiple products work together than any one product. You don't just "install an ESB," take satisfaction, and walk away. It's something you design custom for your enterprise and then implement using the products that provide the features you need. (See flexible infrastructure for end-to-end integration
for a list of ESB capabilities and our products that provide them. Keep in mind that you don't need all of the products, just the ones for the capabilities you want your ESB to have.) Having said that, I remember a day when an app server wasn't thought of as a single product anyone agreed on. So I can imagine the day where an ESB might be a single product, or a single core product with several optional add-ons; but the industry isn't there yet.
Third, IBM thinks that ESBs have many different capabilities
. I've seen the list expressed different ways, as you'll see in my references. Without getting into enumerating all of those here, let me summarize by saying that we believe many competing (e.g. non-IBM) products that call themselves ESBs do not have the range of capabilities that IBM's products do. Some competitors' views of what an ESB is are more limited than IBM's, a reflection of their products' more limited capabilities. (Hey, I'm not trying to flame anyone, I'm just espousing IBM's basic position here. You be the judge.)
Forth, we think an ESB is a key part of making an SOA work
in production (see Services Oriented Architecture and Web services
): an ESB enables the SOA providers to make their services available and the SOA consumers to invoke those services. SOA is one of our key approaches to helping you develop what we call an On Demand Business
So, where can you find out more info?
Remember Roach Motels
? "Roaches check in, but they don't check out." The more I read about how open source licenses
work (even those approved by the Open Source Initiative
(OSI)), the more I think they're like a Roach Motel for code. The licenses are supposed to encourage sharing, and they do up to a point, but they also trap the code within the license.
What made me think of this again was reading Will Sun's 1600 patents suck the life out of Linux?
, which Bob Sutor referred to
. (To be clear, what I'm talking about here is the licensing being applied to the source code, not the patents being made available publicly
so that the source code does not violate those patents.)
But like a lot of other shared, open source code, [code, for example, built from CDDL-licensed code] has a firewall around it. CDDL or unlicensed code that's ready to take on the CDDL license can get it in, but nothing gets out. In other words, it's not universal sharing.
I think the whole idea of these licenses is "hey, if you use my open source code to develop your code, then you have to give me license to use it to." Fair enough.
But this "I'll control who I share with, but you must share any derivative work with me" approach has some ugly consequences, namely code which cannot be combined because of incompatible licenses:
What this means is that if code from the CDDL-licensed OpenSolaris were intermingled with code from the GPL-licensed Linux, then the resulting derivative work would technically be required to inherit the licenses from both, which is impossible because certain provisions in each license cancel out the other. (In other words, they're totally incompatible with each other.)
So I suppose that if you developed a piece of code totally independently of any open source code, you could then donate it to multiple projects with incompatible licenses. (Although, why should you donate it to any project? Maybe you should create yet another new license?) But the whole idea of making code available is for reuse and modification, and if your code reuses code under one license, you're probably required to inherit a license (to be sure, consult a lawyer) and so now your code can't be used with any other license that is incompatible with this one. And if your code reuses code from two difference projects with incompatible licenses, you're in violation of both.
Seems to me: If we really want open source projects to improve the software industry at large, and not just serve as the basis of commercial products, we need for licenses to be compatible so that a derivative work doesn't have to choose one side or another, but can choose to comfortably live with all sides.
(And of course, as always, my standard disclaimer
Alright, this is totally frivolous
, but what the heck, it's Saturday. I've just found a web site
with my favorite Simpsons
I want to share something with you: The three little sentences that will get you through life.
- Number 1: Cover for me.
- Number 2: Oh, good idea, Boss!
- Number 3: It was like that when I got here.
After 16 seasons
, as the writers of South Park
and their character Professor Chaos
) (not this one
) discovered, whatever you might do, the Simpsons have already done it
And it turns out that there's lots of these web sites:
Also, check out Bart
's chalkboard punishments:
There's also Bart's prank calls
I've been teaching a tutorial lately, "Architecting and Developing J2EE Applications Using Patterns" (WebSphere Technical Exchange
, IBM WebSphere 2004
). Of all the different practices I suggest, the one which seems to stir the most controversy is to implement Business Object
objects as entity beans
, preferably CMPs with CMRs
(see my Persisting Domain Objects
blog entry). Hey, CMPs are good, they've improved a lot since EJB 1.0, and since you've bought WAS and WSAD/RAD already, you might as well take advantage of them.
Well, now there's a new column in the IBM WebSphere Developer Technical Journal
saying much the same thing, The EJB Advocate
. It's written by Geoff Hambrick
(how to pronounce "Geoff"
), an IBM Distinguished Engineer
and member of my IBM Software Services for WebSphere
department. From the description of his column:
Since the Enterprise JavaBean (EJB) 2.0 specification came out, I have not hesitated to recommend that developers use all the forms of EJBs... The trouble is that two years later, many Java developers have not evolved their thinking along with the specification...
My point exactly. EJBs, when used properly, are good. Do you want to know more?
Read Geoff's column
One of the coolest new features in J2SE 5.0
(formerly known as Java 1.5
) (what's new
) is generics
) (aka JSR 14
). The killer app
for generics is the problem of making sure that a Collection
and having to downcast each element as its accessed from a collection.
There is a new article in the Java technology zone
about generics, Java theory and practice: Generics gotchas
, that teaches you how to use generics. There is also a tutorial, Introduction to generic types in JDK 5.0
Generics are not yet part of J2EE
, but will be part of J2EE 5.0 (aka JSR 244
) (Java 5 hype from Sun
The Design Patterns Toolkit
(DPTK) on IBM's alphaWorks
is an Eclipse plugin
) for generating Java source code (or any other type of text file) from XML templates. The idea is that experienced developers create templates for standard code structures that inexperienced developers then use to generate those code structures for the specific needs of their custom applications. The toolkit includes features for creating templates from a set of sample code, using it as an example to create boilerplate code.
For more info:
Two weeks ago, IBM made 500 patents available
for open source projects, in an effort to create a patent commons
. Today, Sun has announced that they are making 1,600 patents available for open source, calling it the "largest single release of patent innovations into the open source community by any organization to date
." This is part of Sun's effort to open source Solaris
, an effort to compete with Linux
. The patents will be available through their Common Development and Distribution License
Looks like Sun wants to compete with IBM for who will be the largest contribuitor to the patent commons. Wonder who else will join?
A few of the articles on these topics:
January 26, 2005
Bob Sutor compares IBM's patent pledge with Sun's patent pledge in Regarding Sun and and their "opening up" of 1600 patents: please do it for all OSI licenses
January 29, 2005
Also see Bob Sutor's blog ZDNet on patent pledges
Back on the happiness thread
: I haven't seen this book yet, but it sounds interesting. One Small Step Can Change Your Life
by Robert Maurer
takes the Japanese practice of kaizen
and applies it to improvement not of industrial processes, but of one's self. Kaizen is continuous improvement
one small step at a time. It was pioneered by an American, W. Edwards Deming
(his 14 points
), who helped the Japanese automobile industry rise to prominence and compete effectively with Detroit in the 1970's and 1980's. Maurer applies this to personal improvement, making small improvements that add up to big ones. (See 50 ways to fix your life
and How to reach the summit of life success
.) A similar book is Small Change: It's the Little Things in Life That Make a Big Difference!
. Sound interesting.
, the JDO
2.0 effort, just voted not
to approve the latest draft of the spec. The Public Review Ballot
shows that 10 of the 16 committee members voted against approving the draft. One was IBM, which commented:
The public review draft has done little to address the concerns we originally expressed in the JSR Approval ballot regarding the overlaps between JDO's proposed new capabilities and other similar Java technologies.
The concern is this JSR's relationship with JSR 220
, the EJB
3.0 effort (see EJB 3.0 - Early Draft Review
). For some discussion, see JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle
. Also see Unnamed Persistence Specification (UPS)
for a more general discussion about how JDO and EJB CMPs are (maybe?) coming together.
There's a new article on developerWorks that you may find interesting, "The role of JNDI in J2EE
." It explains what JNDI
is all about, a topic I also touch in my "Eliminate caching in service locator implementations in J2EE 1.3
" article and in an upcoming one on implementing J2SE clients for WebSphere MQ
JNDI helps decouple application code from the resources it requires (other code components, database connections, global variables, etc.). This is also tackled by the so-called "Inversion of Control
" approach and frameworks. Martin Fowler gives IoC the much more descriptive name "Dependency Injection
" and compares it with JNDI and the Service Locator
pattern in "Inversion of Control Containers and the Dependency Injection pattern
One of the authors of the new dW article is Kirk Pepperdine
). Kirk and I used to work together at GemStone Systems
, whose J2EE
application server product was super-cool because it also had a built-in object-oriented database
. The database is now available as the GemStone Facets
product, which can be added to any application server and used as a JDO
For some thoughts I've had about the J2EE-alternative frameworks and persisting Java objects, see Persisting Domain Objects
and Unnamed Persistence Specification (UPS)
The cover story
of this week's Time magazine
(dated January 17, 2004) is "The New Science of Happiness
," a topic I talked about
a few weeks ago. (Is Time
reading my blog? Eh, probably not!)
One thing it talks about is that the field of psychology has historically been focused on helping emotionally ailing people become neutral, but now is also focusing on helping neutral people become more fulfilled. Part of this is measuring happiness, not an easy thing to do scientifically. One measurement approach is the Satisfaction with Life Scale
. As for defining when someone is happy, Dr. Daniel Kahneman
distinguishes between the experiencing self
, whose happiness is based on what's happening right now, and the remembering self
, whose happiness is based on an experience's high and low points and ending. Kahneman thinks the experiencing part is most important (what you're doing influences how you feel), whereas Dr. Martin Seligman
focuses on the remembering part (how you feel is based not on what happened and how you felt, but on what you remember happening and remember feeling). Some guidance for how to become happier comes from "Eight Steps Toward a More Satisfying Life" by Dr. Sonja Lyubomirsky
. She suggests that you have to commit yourself to being happy, much like the Intention practice from the book in my previous post.
It's an interesting collection of articles, so check it out.
An emerging trend in J2EE
is a new feature called Service Data Objects. SDO is not part of J2EE yet, but is already in the latest versions of IBM's WebSphere Application Server (WAS 6
) and BEA's WebLogic. Those companies are leading JSR 235: Service Data Objects
to add SDO to J2EE.
SDOs are basically the Data Transfer Object
pattern on steroids. SDOs accomplish three main goals:
- encapsulation -- Like DTOs, SDOs group data into a package that can easily be serialized and transferred between tiers/processes.
- mediation -- SDOs provide a uniform data access API, regardless of how the data is actually stored or has to be accessed. Thus regardless of how you're getting your data--JDBC, entity beans, JDO, JAX-B, etc.--a client just treats it as SDO data. The magic is a mediator layer that adapts each different kind of data source to the SDO API.
- caching -- SDOs support disconnected operation--so your app can keep working even while the database is unavailable, using the data it has already loaded. This also enables keeping track of changes so that they can easily be committed, replyed, rolledback, logged, etc. This enables an SDO to implement optimistic locking so that the GUI doesn't have to.
Starting with WAS 5.1 and WebSphere Studio 5.1.2, the JSF
(see Developing JSF Applications using WebSphere Studio V5.1.1
) tooling uses SDO (formerly known as WebSphere Data Objects
(WDOs)) so that a JSF GUI has a simple API for accessing whatever data it needs.
SDO is part of a set of J2EE extension specifications IBM and BEA have been working on jointly called CommonJ
. CommonJ consists of these parts:
- Service Data Objects -- Uniform data access
- WorkManager and Timers -- Better timers than EJB 2.1 (see EJB 2.1: The Timer Service)
- Enterprise Metadata Discovery -- Makes JCA adapters describable and discoverable
All of this is working toward making J2EE better support SOA
applications and what is starting to be called a "service oriented programming model" (SOPM) (see Why all the interest in SOA now? Part 2
), where an application's functionality is wrapped and exposed as services, and a user application isn't so much a set of functionality but a coordinator for invoking the services that provide that functionality. (Some or all of the services the user application uses may be provided in-process, but they don't have to be, and the app's architecture enables it to fairly easily switch from in-process services to remote ones as needed.)
Here are some more links on all this stuff:
I've added a new link to my blog's list of web sites: WebSphere Recommended Reading List
. It's compiled by the department I work for, IBM Software Services for WebSphere
(ISSW). We help customers be successful with WebSphere
products, and we're frequestly asked (which we appreciate), "Where can I learn more about WebSphere (products, programming, production, etc.)?" This list is our collective answer.
The current version is from February 2004, but it's getting ready to be updated (I've seen the draft). In any event, much of what in the new list is already on this list, because most good information is still good a year later. I'll keep an eye out for the update and let you know here when it's available.
So, if you'd like to learn more and what to know what resources are available, check out this list.
Also take a look at: