Bobby Woolf: WebSphere SOA and JEE in Practice
From archive: August 2008 X
What are the main principles a software architect should know?
Some colleagues of mine are compiling a list, "97 Things Every Software Architect Should Know" which will eventually be a book. So far they've got 49 axioms such as Don't put your resume ahead of the requirements, One line of working code is worth 500 of specification, and Architectural Tradeoffs. Check it out.
The customer reviews on Amazon give Enterprise Integration Patterns five stars.
Enterprise Integration Patterns is a book I co-authored; check out the reviews for yourself. For a couple of years now, the total has been stuck at 4.0-4.5 stars because of helpful reviews like "A Tactical Book" (which says: it's all about using messaging systems) and "Good for concepts but lacks practical usage" (which says: After reading this book I know concepts but still have to buy real Biztalk book.). I'm also amused by "interesting patterns with a little bit of hype", which warns, "One word of warning, it's a "Martin Fowler Signature Series Book", which means it's more interested in being on the bleeding edge as opposed to being thorough." As Martin once commented to me: I feel sorry for anyone who considers this stuff bleeding edge.
Anyway, those reviews aside, there are now enough 5-star reviews to make the overall average round-up to 5.0. Not bad for a book that was published almost five years ago, an eternity for a computer book.
For some good developerWorks articles on this topic, see:
IBM is scheduled to run a series of jams on service management.
I've already talked about the IBM Service Management World Tour. We now also have a product page for IBM Service Management Software and Services.
And we will also have the IBM Service Management Jams:
[A] new series of live webcasts customized for IBM Service Management practitioners, Business Partners and the business community. With these weekly webcasts, we’ll provide the very latest in thought leadership, solution deep dives and real-world experiences aimed at those managing IT, service delivery and operational infrastructures of all kinds – across every major industry. These live web events are free to everyone.
The first one will be August 19 at 12 p.m. EDT. You need to register to attend.
How do you do information as a service using WebSphere products?
I've talked about information as a service, how it makes database access into SOA services. Now ISSW's Andre Tost has a new article, "Leveraging Information as a Service in your WebSphere-based SOA solution," which explains how to use IaaS as an enabler for business process modeling (BPM).
This article is in the July issue of the IBM WebSphere Developer Technical Journal, always a good source of WebSphere best practices. Check it out.
So what's this cloud computing thing all about? Sounds like SOA and ESBs to me.
David Chappell, frequent industry commentator and author of books like Understanding .NET (not to be confused with David Chappell, Sonic MQ and Oracle guy and author of Enterprise Service Bus, nor with Dave Chappelle, the guy with the self-titled TV show), has a new and rather interesting paper, "A Short Introduction to Cloud Platforms." There's a discussion of it, David Chappell: Introduction To Cloud Computing, on InfoQ.
I personally get cloud computing confused with grid computing. According to Wikipedia (chronicler of wikiality), grid computing (part of the onetime future of computing) is a cluster of resources that act together like one big resource, such that you don't care where in the grid your functionality gets performed. This sounds like, for example, a J2EE application deployed to a WAS ND cluster; the user doesn't know nor care which cluster member is performing his work. Cloud computing, says Wikipedia, occurs on the Internet (or some other type of network, I suppose) such that you don't even know where it's occurring. When you perform a search using Google, Amazon, Travelocity, etc., where is your search executing? Silicon Valley, New York City, or Bangalore--it doesn't matter. In fact, users in NYC are probably hitting different servers than those in Bangalore; those servers are running in a cloud. The data centers in Silicon Valley, New York City, and Bangalore should each be running a grid.
"What cloud computing really means" (InfoWorld) (part of Inside the emerging world of cloud computing) doesn't really answer its own question. Instead, it covers all the bases, saying cloud computing can mean: Software as a service (SaaS), utility computing, Web services in the cloud, platform as a service, managed service providers (MSPs), service commerce platforms, and Internet integration. Gee, clear as mud. (At least they didn't say it's Web 2.0 (which I say is MVC for the Web).)
Likewise, "Guide To Cloud Computing" (Information Week) doesn't really say what it is. But Amazon, Google, Salesforce, etc. are all doing it. An example that a lot of journalists are talking about is Amazon Web Services (AWS), which essentially lets you outsource computing jobs to them. Need some data crunched? Give it to Amazon and they'll get it done. Of course, there's a lot of constraints in how you package up your functionality to be performed, you need to have a lot of flexibility on when it gets done exactly, and you may need to worry about the security (esp. privacy) of your data.
Of course, I should also mention that IBM does cloud computing as well. See:
The Africa press release even has an IBM definition of cloud computing:
Cloud computing enables the delivery of personal and business services from remote, centralized servers (the "cloud") that share computing resources and bandwidth -- to any device, anywhere.
Back to David's paper. He divides an application platform into three parts (see Fig. 2): Foundation, such as the operating system, and I'd include middleware like a J2EE application server; Infrastructure Services, other capabilities and middleware that the app uses for persistence, security, messaging, etc.; and Application Services, which perform business functionality and ideally are wrapped up as SOA business services. The upshot (see Fig. 3) is that cloud computing makes infrastructure and application services available outside the enterprise, in the cloud. Cloud computing also enables the app itself to run in the cloud, so you just deploy your app to the cloud and access it from anywhere (again, like a world-wide WAS ND cluster).
To me, this approach isn't that astonishing; I guess someone just had to give it a name. I (and many others, I think) look at SOA as being an app that works as (what I call) a service coordinator consuming services, namely service providers. The key is that the providers for any given service may be inside the enterprise (what David calls on-premises) or may be outside the enterprise (what David calls the cloud). In fact, a single service may have both internal and external providers, and it seems to me that the cloud should include both, so that the app consuming the service doesn't need to know whether the provider is inside or outside the enterprise (or both). I think an important part of solving this problem, making services available to consumers without having to know where the providers are, is the enterprise service bus. This is one of the main points of my articles "Why do developers need an Enterprise Service Bus?" and "Simplify integration architectures with an Enterprise Service Bus" (the latter with James Snell).
So cloud computing is functionality being performed wherever is convenient, where the client application doesn't know nor care where the functionality actually lives. A great approach to make this happen, and to prepare for more of it in the future than may be practical for you today, is to use SOA and ESBs.
Data access in an application is getting a lot more interesting.
In the good old days, you implemented an application, and it accessed its data from a database. At a really high-level, the architecture was simply two layers: The application and the database it used.
Typical application database stack
A more advanced variation was to have multiple applications sharing a single database (the Shared Database pattern).
In this architecture, the application knows what database stores its data, the schema the data is stored in, and is responsible for transforming the data into the format it needs. This creates a lot of work for the application and makes it very dependent on the details of the database. Worse, several applications using the same data may be repeating the same effort, not only writing duplicate code to access the data but also performing the same transformations redundantly.
In modern enterprises, this application-on-a-database approach is becoming increasingly quaint. If every application first has to write a lot of code just to access its data, then applications are much more difficult to write and get working correctly. What is needed is a separation of concerns, where:
In our really high-level architecture, this separation of concerns creates a third layer between the application and the database, a layer we tend to call information.
The information layer doesn't persist the data, the database still does that. The information layer rationalizes whatever is in the database, producing normalized, cleaned-up, customized data for the application.
The information layer encapsulates this data rationalization behavior so that it can be developed and maintained separately from the application. It also makes this rationalization behavior reusable by multiple applications. If your app needs certain data gathered and normalized a certain way, and another application already has that, then your app can reuse that. And if another app has already accessed this data, the data may be cached in the format your app needs so that it can just use it.
Furthermore, no complex enterprise stores its data in just a single database. An enterprise's data is spread across multiple databases, legacy systems, business partners, old archived data, unstructured data (such as much of the Internet), and so on. What may seem like one Customer record may actually come from multiple data sources. Often the same data is stored in multiple places; sometimes the redundant data conflicts with itself. Often data which an application needs to go together as a single record is stored in many different formats, none of which may be the format the application needs.
What this leads to is a three-layer architecture for the enterprise, the same application-information-database layers as before but now for a whole enterprise and not just a single application. The enterprise layers are:
With this layer of integrated information, the question changes from how will your application access its data to how will your application use the information layer to access the information it needs and how will the information layer access the data. Data access in an application is getting a lot more interesting.
08/29/2008 update: Here's an article that discusses this idea in a lot of detail as a pattern: "Inside the Preferred Data Source Pattern."
I'll be speaking at the OOPSLA 2008 conference.
If you need even more reasons to attend, here are some other conference highlights that look promising:
So, lots to do. Please come join in.
WebSphere has turned 10 years old.
WebSphere Application Server was first released ten years ago. The anniversary was actually a couple of months ago; here's an article on this milestone: "IBM WebSphere at 10" (eWeek).