ATTENTION: This blog has moved to a new location. Please update your bookmarks, browsing habits, and aggregators.

	Thursday, April 17, 2003

Microsoft's Not All Bad This post (and this weblog) has a new home. As a strong Java advocate, I take a few (deserved) pot shots at Microsoft's forays into enterprise software when the opportunity presents itself, but I have to say that when it comes to "office" suites and rich user applications, no one does it better.  I've been using the Office 2003 beta for a while, and it is very, very nice.  (I wouldn't be the first to compliment InfoPath or OneNote - which can only be truly appreciated on a TabletPC - but the improvements in Outlook are the most important feature to me, personally, so far.) To a point, with reasonable XML support and accessibility through web services added to the product, it doesn't bother me (much) to have Microsoft own the desktop applications because it is now possible to build solid integration with the Office products from a generic environment.  (In fact, we've got a neat demo using web services support to plug Excel-based financial models into processes implemented in our Java-based BPI platform.)  The former state-of-the art for integration with Office was either at the file-format level (e.g., through POI) or through a Java/COM bridge (e.g., for free through something like JACOB or for pay through something like J-Integra (the JCA support is a nice touch)). That isn't to say that I wouldn't jump at the chance to have similar high-functionality applications on a Linux platform (although Cygwin fully satisfies my occasional craving for sed, awk, find, and their ilk).  Even though IBM's going to make a run, it appears that OpenOffice and Corel are the only options for SMB and SOHO users, and that means that Microsoft will still get my money. 10:40:40 PM

BPEL4WS 1.1 - Forward Progress This post (and this weblog) has a new home. Version 1.1 of the BPEL4WS specification is out and has quite a few positive changes (even some that I was hoping to see, if I may say so). Some out-takes from the changes section follow. Separation of Process and Protocol In the 1.1 version of the specification we clearly separate the core concepts from the extensions required specifically for the two usage patterns [of business protocols and of business processes]. My hope is that the separation of protocol and process moves discussion toward a consideration of the kinds of protocols that are appropriate for different types of interactions, e.g., those bound by a two-phase commit protocol. (See Transaction Internet Protocol (IETF RFC 2371) for the sort of thing that I'm thinking about.) It's time for mainstream web services to move beyond just HTTP and JMS. Scoped Correlation Variables and correlation sets that are associated with scopes rather than with the process as a whole. This is a base requirement, as correlation ids may not be known until a scope's execution has begun or until an initial invocation has returned. Event Handlers This next one is something that I've called the arrival problem in our internal requirements discussions for our bpi product and amounts to a kind of pre-correlation of messages with proceses or scopes: Event handlers which permit a process or scope to be prepared to receive external events and requests concurrently with the main activity of the process or scope.  This is especially helpful for events and requests that cannot be "scheduled" relative to the main activity, but may occur at unpredictable times. In practice, the events may even occur prior to the initiation of the process or scope in the first place! There are many, many use cases for this across vertical industries, including healthcare (e.g., automated discharge summary documents in an inpatient hospital setting, laboratory results prior to a surgical procedure, or insurance eligibility verification prior to a billing event) and supply chain (distributed order management, advance ship notices, shipment locator messages). 4:01:34 AM