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."
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.
Bobby Woolf: WebSphere SOA and JEE in Practice
There's a pretty interesting new television show on HBO, "Assume the Position With Mr. Wuhl."
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.[Read More]
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.
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.
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.
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.
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."
Update: As Andy Piper notes, C. M. Saracco has two articles on DB2 Viper:Read More]
Well, looks like Marc Fleury and JBoss have found a suiter.
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[Read More]
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.[Read More]
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:
IBM has announced the next version of WebSphere Application Server, version 6.1.
The announcement ("IBM United States Software Announcement 206-076" dated April 11, 2006) is "IBM WebSphere Application Server V6.1 delivers flexible, secure infrastructure to provide a reliable foundation for your Service Oriented Architecture" (). There's also a WAS z/OS V6.1 announcement. The planned availability dates are:
WAS 6.1 implements J2EE 1.4 and J2SE 5.0; compared to V6.0, this is the same J2EE version but the latest J2SE version. Various new features of WAS 6.1 are listed in the Description. The WAS 6.1 hardware and software requirements are posted.
Product positioning describes the members of the WAS 6.1 product family. Statement of direction describes some other products we plan to release in the coming year:
The Application Server Toolkit (see WAS 6: Application Server Toolkit and Rational Software Development Platform) has been enhanced to provide "basic support for the creation of new applications targeting" WAS 6.1, including tooling for developing Web apps, portlets, Web services, and EJBs. Thus the ASTK can now do much of what RAD 6.0 does, and is updated for WAS 6.1.
There's also a WAS CE V1.0.1 announcement. (See WebSphere Application Server Community Edition (WAS CE).)
For more info:
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 (more) 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]
There will be a webcast on April 19, 2006, "Raise the Bar on Quality in All Your Business Applications."
Not that you could tell from the title, but it's on WebSphere Extended Deployment. The speakers are Jamie Thomas and Billy Newport.
For a preview, check out this podcast: Making SOA real with WebSphere, Episode 1: Improving resource utilization.
Update: Also, Billy has some recent, relevant posts on his blog: