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.