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]
Bobby Woolf: WebSphere SOA and JEE in Practice
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 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 appliences.
Lots of good stuff, go check it out.[Read More]
There's a new Insight and outlook column in the developerWorks Architecture Zone: "What is IT governance, and why should you care?"
My answer is, "In a world without governance..."
I'll let you check out the article to find out what service governance is. The points I'd like to drive home are:
For previous columns, see What's the best software to implement as a service?
Have fun.[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:
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]
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:
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:
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]
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]
Well, looks like Marc Fleury and JBoss have found a suiter.
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]
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.
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.