It's a new quarter and time for a new round of marketing announcements from IBM.
While some products (or at least versions) are new, the announcements reiterate some already announced and available products. This latest news focuses more on how the products go together, how it all fits into SOA
, and on how IBM clients
are achieving success with IBM products and SOA.
WebSphere Application Server V6.1 has been announced, which I'll cover in my next posting.
The next version of WebSphere Portal
, version 6.0, has been announced:
WebSphere Business Modeler V6.0 announcement: Version 6.0 of the IBM WebSphere Business Modeler family of products provides unrivaled business modeling, simulation, and collaboration capabilities to revolutionize business flexibility
. Actually, that's from September 2005, but it was discussed a lot again this month.
WebSphere Business Monitor 6.0 announcement: IBM WebSphere Business Monitor V6.0 delivers real-time business monitoring with metrics, visual displays, and alerts
(from September 2005).
WebSphere Commerce V6 announcement: Preview — IBM WebSphere Commerce V6
. Again, originally announced in January.
New versions of WebSphere Enterprise Service Bus, WebSphere Process Server and WebSphere Information Server -- 6.0.1, not exactly news for my readers; see WebSphere Business Process Management
Lots of articles have been published about all this. See:
SOA breaks a monolithic application into a collection of parts, a composite application.Loosely Coupled
gives a quick definition
composite application -- An application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems).
Applications are traditionally monolithic. Two applications may share the same reusable framework or component
, but they each contain their own copy of the code and run it separately in their own process. Even an application with an n-tier architecture
is a monolithic architecture distributed amongst multiple processes.
What makes SOA different is that applications share running parts--called services or service providers--not just at development time but at runtime as well. If a shared part goes down, the outage affects multiple applications. So an application is made of multiple parts, some of which are shared with other applications. Is such a shared service part of app A or app B? It's part of both. So the "composite application" term not only describes that the application is in multiple parts, but that the parts are shared between applications.
I've talked about The Two Parts of an SOA Application
, service coordinators and service providers. The providers are the shared parts. The coordinators tend not to be shared, although they can be composite services
that are reusable service providers as well. I expand on these ideas, and how to make use of them, in Streamline SOA development using service mocks
.Personal finance application and services
What is a composite service?
There doesn't seem to be a whole lot of agreement (yet) in the industry, or perhaps even within IBM, on what this term means. But here's my take, at least.
In the tradition of the composite pattern
, a composite service
is a service whose implementation calls other services. This is as opposed to an atomic service
, whose implementation is self-contained and does not invoke any other services.
A composite service acts as both a service provider of the (composite) service and as a service consumer of its child services. The composite can be considered to be aggregating together the child services into a bigger service. A composite service is one kind of what I call a service coordinator
, a coordinator that also itself is a service.
In "Service-oriented modeling and architecture
," IBM's Ali Arsanjani
shows composite and atomic services in the Services layer of an SOA:
The layers of a SOA
You cannot tell from a service's API whether it's composite. In fact, two providers may implement the same service, one in a composite fashion and the other in an atomic fashion. A provider implemented one way might be reimplemented the other way; this change makes no difference to the consumers because the interface is still the same.Service component architecture
(SCA) supports composite service components. Recall that an SCA has a service interface and service references. Those references give the implementation the ability to call the other services referenced. They also serve as a declaration that this component needs these services, much like a Java class importing other Java classes. An SCA with no references is atomic; one with references is composite.
Service Component Architecture overview
A business process is a kind of composite service. A business process can be invoked as a service, a request to perform its functionality. The process contains a sequence of activities implemented as services, so therefore is a service that calls other services. That's a composite service.
In my mind, a business process is a special case of composite service. Usually, a service executes what might be described as synchronously. (The execution can be invoked synchronously or asynchronously.) A service has a return value (or exception); it is returned at the end of execution. The consumer usually waits (but not necessarily with a blocking thread) while the service executes, and does not continue until the service completes and returns its result.
What makes business process a special case is that a caller usually doesn't wait while the process executes. A caller invoking a business process (synchronously or asynchronously) usually waits only while the process starts, to confirm that it starts successfully. But once the process starts, it runs on separate thread(s) "in the background" while the caller proceeds with other work.
Because of this difference, it seems to me, although a business process is just another service and another way to implement a service, a caller usually knows whether or not the service it's invoking is a business process. If it's not, the caller cannot tell whether the service is composite or atomic, but if it waits for a return value, then the service is most likely not a business process.
David Chappell has touts the significance of SCA
: Why Service Component Architecture Is Big News
David Chappell is the author of several books on Microsoft technology
, lots of articles
, and general all around knowledgeable guy. In his posting, he's not endorsing SCA as good or bad, but acknowledging its industry momentum and telling developers to pay attention to this trend.
Thanks to Richard Brown for pointing this out
You can now try out the next version of DB2.
I've talked about DB2 Viper
, the next release of DB2, which will handle both relational and XML data. IBM now has a DB2 Viper Early Community
page, which lets you download a beta and try it out. There's also a new article, "What's new in DB2 Viper
: As Andy Piper notes
, C. M. Saracco has two articles on DB2 Viper:
At a recent presentation, a colleague asked me, "Can a composite service be implemented in an ESB?"
As I've previously discussed, a composite service
is one whose implementation calls other services. It acts as both a provider of the (composite) service and a consumer of child services.
As a consumer of services, a composite service can certainly live outside of an ESB and use the ESB to invoke its child services. As discussed in ESB and Workflow
, if a composite service is a business process, it must live outside of the ESB since an ESB is generally not thought of as including a process engine.
So what if a composite service is not a business process? Can it be implemented in an ESB? The question is: If a composite service were implemented in an ESB, how would it be implemented?
An ESB can contain integration logic implemented as mediations, mediation flows built from mediation primitives. Mediation flows usually (always?) run in a single transaction and are stateless. Thus it would be difficult to implement a mediation primitive for invoking a service, especially a general-purpose primitive that could be configured for any service.
Thus in general, I think you're better off implementing composite services external to an ESB. A composite service is a consumer of services available via the ESB.
I talked about the relationship between ESB and Workflow
in general. How is this difference reflected in IBM's products?
I explained that one school of thought, which I share, is that workflow doesn't run in an ESB, but it should implement its activities as service consumers and use an ESB to invoke the providers. This has been my view for several years now, since before we started to refer to all of this messaging connectivity as ESBs.
This explanation is consistent with the feature set in IBM's SOA and ESB products: WebSphere Process Server, WebSphere Enterprise Service Bus, and WebSphere Message Broker (aka the Advanced ESB). Remember that WPS is built on top of WESB. Here's a diagram of the component model in WPS/WESB:
WebSphere integration product family
All of this is in WPS. As I explained in Better WBPM Pictures
, what this diagram doesn't show very well is how much of this is in WESB. WESB contains the SOA Core components and the Mediation Flows component, but none of the other Supporting Services or Service Components.
So WESB contains Mediation Flows, but only WPS contains Business Processes. That's the major difference between the products: WESB does mediation flows, but not business processes. Business process is outside of the ESB. Similarly, Message Broker does message flows but not workflow.
So the IBM ESB products are consistent with my previous explanation. They do mediation flows but not workflow. Workflow is generally considered to be functionality outside of ESBs.
There's a pretty interesting new television show on HBO
, "Assume the Position With Mr. Wuhl
|This show is a cross between entertainment and documentary. It's staged at a class of college students at New York University, where history buff Robert Wuhl teaches the way history really was.|
He calls (American) history "the stories that made up America and the stories that America made up," that history is popular culture, the entertainment of its day. He quotes Tolstoy, "History would be wonderful thing - if it were only true," and Napoleon, "History is a myth that men agree to believe." To explain why history is as much fiction as fact, he quotes a line from The Man Who Shot Liberty Valance, "When the legend becomes fact, print the legend." In other words, once everyone believes the story, it doesn't really matter whether it's true, it gets printed anyway. If it's not what happened, well, it's what people want to believe happened.
So, I don't know how accurate his retelling of past events really is. But it's interesting and funny, and it makes you think. How much of what we've all been taught really happened, well, really happened? It's interesting to see his take on things.
For another bit of current entertainment that will make you think, see V for Vendetta is Fantastic
Speaking of David Chappell
, he has another very interesting blog posting, Making Loose Coupling Real: The Need for Interoperable Queued Messaging
He points out that SOA tends to assume services are invoked as Web services, but current WS-* specs don't support what he nicely summarizes as interoperable queued messaging. (QM is what you get with JMS providers like WebSphere MQ and the Service Integration Bus, as well as non-JMS messaging systems like MSMQ.) He points out that you need QM for loose coupling; and you need I for, well, interoperability, the holy-grail of Web services (otherwise, why put up with HTTP?). He argues that WS-ReliableMessaging doesn't really get the job done (not that it's exactly universal these days anyway--are you using it? Who is?).
I'm a JMS/messaging kind of guy; I have a book on messaging patterns
. To me, the way applications should talk to each other is via asynchronous messaging. This is how a service coordinator
) should invoke a service provider, using Request-Reply messaging
. As for invoking services using SOAP-over-HTTP protocol
, I'm fine with SOAP (or at least that's another conversation), but HTTP is just too darn fragile. Like David points out, you need queued messaging.
As I described in Reliable Web Services
, I see WS-ReliableMessaging (or perhaps WS-Reliability) as a way to make messaging systems interoperable (see More on Interoperability vs. Integration
). So rather than replacing messaging systems like WMQ, WS-Relia<something> can augment existing messaging products to make them work together, and do so over the Web/HTTP/IP/whatever.
Like David and others are pointing out, this is something we need for all this SOA stuff to really work, not just within enterprises but between them as well.[Read More
This week's BusinessWeek
magazine has an article on JBoss
' Marc Fleury
, "An Open-Source Lightning Rod
," and an interview online, "The Bad Boy of Open Source
|Some notable quotes:|
- "Meanwhile, some open-source companies are put off by what they say is Fleury's money-grubbing, controlling style."
- "Some investors have even refused to invest in JBoss because of Fleury's style."
I find it interesting when mainstream media starts talking about technical issues. These articles aren't about the technical merits of JBoss, J2EE, or open source, but of how Marc's personnality fits within the industry. It also discusses how Oracle offered $500 million for JBoss, but Marc seems to have skuttled the deal.
I've talked about some good BusinessWeek
articles before: "Beyond Blue" cover article in BusinessWeek
, HP has a New CEO: Mark Hurd from NCR
, Perficient Featured in Business Week
, and Social Network Analysis
. Also, a not so good article: Is Java So Nineties?
Also, I've talked about Marc a couple of times: Marc Fleury in Business Week
and JBoss Partners with Microsoft
The March 2006 issue of the IBM WebSphere Developer Technical Journal
is now available.
Actually, it's been available for several weeks now; I forgot to point it out. The March issue is now listed in the archives
ISSW's Bill Hines has a very interesting Comment Lines column, "The (XML) threat is out there...
" It explains the need for an XML Firewall, one of the simplest but important capabilities of the DataPower
Lots of good stuff, go check it out.[Read More
Bill has a really interesting posting that I'd like to point out.
In earned value and executable code
, he describes a policy to measure progress on a project in terms of the percentage of requirements met through executable code. Coding effort (more code, refactored code, whatever) is only progress as more requirements are fulfilled.
This has some very interesting consequences. Writing documentation, modeling UML, etc. doesn't count as progress because no more requirements can be executed successfully. This gets you focused on one of the main tenants of the Manifesto for Agile Software Development
(also see "The Agile Manifesto
" in Dr. Dobbs
): "Working software [is more valuable than] comprehensive documentation." It also means that if you spend the first six months of a year-long project documenting and analyzing, you're not half way done, you're 0% done since you have no working code yet. Yikes!
I like this perspective a lot; it may not be that original, but it's good. However, as the Freakonomics
guys would ask, "What are the incentives?" An obvious incentive is to start writing working code. But is that a good idea from day one? Even XP
has a week of planning at the beginning of an iteration. A week into an iteration, is your progress really zero? If you take some time to write some tests, do they contribute zero? Does refactoring your code contribute zero?
I've heard Kent say that ideally you could write good software without any tests, since ultimately tests are overhead and don't provide user functionality. Perhaps the same can be said of refactoring, that ideally code is fine the way you instinctively write it the first time. Nevertheless, these efforts do seem necessary in practice. I'm wondering how you justify these efforts when they count as zero progress.
BTW, people and process
discusses another good point, that people are more important than process. This has also been captured in the Agile Manifesto: "Individuals and interactions [are more important than] processes and tools."
Anyway, good stuff, go check it out. But consider the consequences as well.[Read More
We've updated the WAS recommended reading list and created a new one for WBPM.
The updated one is the J2EE and WebSphere Application Server Recommended Reading List
. Like the title says, it focuses on articles and other stuff for learning about J2EE and IBM's J2EE products like WAS and RAD. I've talked about it in the past in ISSW Recommended Reading List Updated
We now also have a completely new list, the Service-Oriented Architecture and WebSphere Process Server Recommended Reading List
. Like the original, this one focuses on technology and products. The technology is SOA and ESB; the products are the WebSphere Business Process Management
products, especially WPS and WID.
These lists are produced by my department, IBM Software Services for WebSphere
. In fact, I had a hand in producing both lists. We hope you find them helpful.[Read More
The Associated Press
has compiled a list
of cities with the highest percentage of educated workers. Raleigh, North Carolina
ranked third with approximately half the adults having bachelor's degrees
The top five cities are Seattle, Washington; San Francisco, California; Raleigh; Washington, D.C.; and Austin, Texas.
For more details:
Also see: Raleigh, NC: #7 Richest City, #13 Most Literate City
Well, looks like Marc Fleury and JBoss
have found a suiter.