Stephen Cohen's thoughts on Enterprise Architecture

Building enterprise worthy parts from Microsoft pieces

I spent the last week working on a proof of concept for a very large customer.  They wanted to build a service oriented software infrastructure to be used across many well known, and all possible future, applications.  The principle goal is to provide safety and security in a structured and predictable way.  The top requirements are;

   * Component lifecycle management such as fail and recover as well as dependency start and stop

   * Logging to system logs, files, and databases

   * Event triggered notification to dependant processes as well as system operators

   * Real, near real and latent publication of data to interested subscribers

   * Synchronous and asynchronous messaging support

   * Role based security with auditing and data filtering

These are all very appropriate pieces of software plumbing to be built and shared in an enterprise environment.  Certainly no small task, but absolutely worthy of the effort.  So worthy in fact that Microsoft has already done this for them and you too.  No additional charges, you own it, in many cases you are already running it.

   * Component lifecycle management is provided by registering your components with COM+ Component Services.  Since the early days of the Microsoft Transaction Service (MTS) Microsoft has included a hosting environment which provided object activation, fail and restart, and pooling.  If you are running Windows XP, XP Pro or Windows 2003 you have COM+ 1.5, go to administrative tools and start the Component Services snap-in and check it out.  If you are using the .Net framework you have managed code access to the COM+ services under the clever name Enterprise Services.

   * Logging has been addressed by the Logging Block Design developed by Microsofts’ Patterns and Practices group.  It implements the Enterprise Instrumentation Framework and the Exception Management Application Block to provide a robust extensible logging infrastructure. The document and the binaries are free to download.

      * Publish and subscribe doesn’t have a really clearly story in the Microsoft universe.  Not because it isn’t well support… on the contrary, there are three competing ways to available.  In at the Heavy weight class we have BizTalk 2002 with the publish-subscribe toolkit. Biz Talks graphical tools and substantial management GUIs are built on top of COM+, completely abstracting the publish and subscribe metaphor with BizTalk objects.  In the middle weight category is SQL Server , which since verison 7, has been using both publisher and subscriber as part of its replication scheme.  Placing the database engine squarely in the middle of the fray, SQL ensures persistent storage maintains appropriate, consistent, and timely synchronization.  Finally, in the feather weight division we have COM+ Loosely Coupled Events (LCE).  Trim and fast, LCE is a programmatically accessible means of processing publish and subscription requirements.

   * Notification also has a few contenders to be considered.  SQL Notification Services uses T-SQL, XML, and the .Net framework to create notification applications quickly.  In many environments the prerequisite SQL licenses and development skills already exist making this an attractive approach.  Not to be ignored, Exchange brings us Exchange Instant Messaging (IM).  IM has the advantage of proving a “sticky” client which can queue a message if the user isn’t watching the screen at the time the notification is sent.

   * Asynchronous Messaging is readily available via BizTalk, the System.Runtime.Remoting.Messaging libraries of the .Net framework using any combination of Queued Components, AsyncCallbacks, and remoting as necessary for your needs.  The good folk of Microsoft’s patterns and practices have been so kind as to provide some very well written guidance specifically on Implementing Asynchronous Interoperability (or how to live in a world where Microsoft is just one of many vendors).

  * Security has become so vast that the Microsoft Software Developers Network (MSDN) online has promoted Security to a level 1 category in its outline.  The Windows environment has a long history of tracking identity, operating context, and role membership.  With the addition of Active Directory to the mix I am very comfortable saying all the parts are there to do security well.  

Every enterprise has to work through the buy versus build discussions.  There are certainly times when truly custom solutions are the most appropriate approach.  However consider the risk you are adding to an already risky effort.  It is unlikely the code created by your developers will receive the testing, feedback, and improvement that a commercial product has after being “in the wild” for a year or more.  

Published Saturday, February 28, 2004 4:13 PM by Stcohen
Filed under:

Comments

 

stcohen said:

Good catch. I tend to write these as a sort of stream of thought and really should proof read them more. I meant to convey that the publish/subscribe metaphor has been around since SQL 7.

I edited the post to say "... SQL Server , which since version 7, has been using both publisher and subscriber ..."

thanks again.
February 28, 2004 4:45 PM
 

SBC said:

The UIP App block is another one to consider for UI requirements.
February 28, 2004 7:22 PM
 

Stephen Cohen said:

Agreed !!

There are a growing number of blocks out there... many I didn't talk about. I'll try to dig into these soon.

Have you worked with the UIP block? How did that go?
February 28, 2004 8:17 PM
 

Udi Dahan - The Software Simplist said:

Assembling "building blocks" into something that works isn't trivial.

A house for instance, is nothing but some lumber, bricks, and other raw materials processed by some tools - hammers, saws, etc.
But the assembly is what matters.

I agree that MS has some good blocks out there. However, the assembly of these blocks into reliable, secure, scalable systems remains an unsolved problem.

When dealing with a number of applications that will need to use the same infrastructure, I think it wise to create an infrastructure that encapsulates all the underlying blocks into a single API. In this way, it is possible to allow the application developers to focus on their business of delivering value, without getting bogged down in the complexity of "plumbing".

It is also important to be able to upgrade the infrastructure without impacting all the applications that sit on it. This is one of the more tricky lifecycle issues that often get left out of the requirements.

All in all, this has absolutely nothing to do with SOA =) but rather is "just" enterprise development. SOA brings additional benefits to the table - of which several appear in my blog.
February 29, 2004 5:18 AM
 

SBC said:

Udi - I think Ron Jacobs' ShadowFax venture is bringing some structure (similar to App Blocks) to SOAs.
February 29, 2004 5:45 AM
 

Udi Dahan - The Software Simplist said:

I know, I'm thigh-high in ShadowFax.
February 29, 2004 7:32 AM
 

Stephen Cohen said:

It is true that it is far from simple to achieve " ... reliable, secure, scalable systems ..." with Microsoft parts. If nothing else it keeps consultants like myself in the game "-) In the next few days I will be blogging on the various parts in greater detail and how I am weaving them together, effectively creating an API for the customers organization to use.

While this isn't a complete SOA, the end result is intended to be message based communication across multiple protocols into "black-box" services. In this case the services are intended for consumption by applications which will in turn provide services to exposing the business.
February 29, 2004 11:33 AM
 

Stephen Cohen s thoughts on Enterprise Architecture Building | Green Tea Fat Burner said:

June 9, 2009 3:26 PM
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker