Thursday, February 03, 2005 - Posts

Paper on Enterprise Continuous Integration

Today I've been discussing with a co-worker our build process - from private to integration builds - that we currently use at customer site and how it relates to the upcoming Visual Studio 2005 and MS Build. And tonight I came across this post of Mads Haugbø Nissen mentioning an article of Mike Roberts on Enterprise Continuous Integration using Binary Dependencies.

Continuous Integration (CI) is a well-established practice which allows us as developers to experience fewer development conflicts and achieve rapid feedback on progress. CI by itself though becomes hard to scale as projects get large or have independent deliverables. Enterprise Continuous Integration (ECI) is an extension to CI that helps us regain the benefits of CI when working with separately developed, yet interdependent modules. We show how to develop an ECI process based upon binary dependencies, giving examples using existing .NET tools.

The full paper is available for download. A must-read if you're into ECI!

with 4 Comments

Demo of SOA application

The Channel 9-team uploaded a "Demo of SOA application" created by Brian Groth and Mark Berman.

Here is a very rough idea of what Brian and Mark have:

  1. We have the following legacy “backend” systems: (they were written for use by a single user, but we now have them working for multiple users):
    1. RPG application on an AS/400. I think it interacts with a DB2 database on the same box, but would need to verify that.
    2. WebSphere (J2EE using DB2) on UNIX (an RS/6000 box I think).
    3. CICS application on an IBM Mainframe (MP/3000 running OS/390).
  2. These are all “front-ended” by ASP.NET Web Services, which can pop events (when errors occur) to the event log, which are then monitored by our MOM server. We also use a playback feature to monitor what’s behind the web services so we know if these legacy systems go down, even when nobody is using them.
  3. There is also a SQL Server used to keep track of the status of orders in the AS/400. This is because we also have a Pocket PC application that interacts with a web service to change the status of the order (New Order, Allocated, Picked, Shipped). 
  4. We use an InfoPath form to kick off a purchase order, which starts everything into motion.
  5. We also record the order in SAP after everything is done.
  6. We also (soon) use Speech Server to call someone with the status of the order.
  7. Various BizTalk 2004 orchestrations control the logic of routing the order through the different systems.
with 0 Comments