TechEd 2009 - Day 2

On Day 2 I spent some more time looking into BizTalk 2009 and System Center(SCOM).

The ESB Guidance 2.0 presentation from Brian Loesgen provided some excellent insight into the latest version of the ESB Guidance 2.0 CTP. I am going highlight some of the interesting bits of info that I picked up. For more details regarding ESB Guidance check out the codeplex site. You may not want to bookmark that site because it won't be living there very long. You will have to read the rest of the blog to get the punchline.

What is ESB Guidance 2.0?
It is an initiative of the Microsoft Patterns and Practices team that provides architectural guidance, patterns and practices. The building blocks that are in the package are reusable blocks of code that compliment BizTalk Server. They do not replace BizTalk servers but they allow you to use BizTalk in a "BUS" mode instead of the more traditional Hub and Spoke Model.

Why 2.0?
There was a previous version called 1.0 that left some people wanting more. The initial stab of the kit was known for a tedious installation, pushed some of the itinerary decisions onto the client and lacked some of the tooling that developers were asking for. I am happy to say that these issues have been resolved. Brian indicated that his install only took around 15 minutes instead of hours or even days with the old version. They have done a great job on this version.

Features
The itinerary designer was pretty slick. When you install ESB Guidance, an additional toolbox will be included in Visual Studio which allows you to drag these ESB related shapes onto your orchestration designer. You then are able to configure these shapes within Visual studio. I tend to look at this as if you are configuring a workflow for a message. You have a particular series of events and you want to configure it to encounter. The sum of all of these events are essentially your itinerary. So for example you may receive a message and as part of this message's interaction, you need it to be transformed to a new message format, have it passed to an orchestration for additional processing only to be transformed to an additional format on its way out the door. Instead of tightly coupling this solution within a series of maps and orchestration(s) you essentially are configuring the itinerary which will instruct BizTalk what to do with the file. BizTalk will use .Net components, that are included in the Guidance kit, to perform all of the map and orchestration resolutions at run time.


Additional info:

• Only available for BizTalk Server 2009
• Provides extensibility points so you can customize to meet your needs
• More prescriptive guidance is available in this version
• Samples of popular scenarios in SDK
• Itineraries can now be published to an XML file or SQL Server repository. This worked very well. From within Visual Studio you can push the itinerary to SQL Server with a click of a mouse. You can use deploy multiple versions of the itinerary to the repository and by default the newest version will get executed.
  

Big News
It was announced at TechEd 2009 that the ESB Guidance will be making its way into the product offering. Starting in June, it will be known as the BizTalk Server ESB Toolkit. It will be signed code from Microsoft and available via MSDN Download centre. Private fixes will be available via MS Connect site and support will be available via Microsoft Premiere Services. There will be no additional charges for the toolkit when you have a BizTalk license.

SCOM (System Center Operations Manager)
I decided to attend a session that was a little outside my comfort zone. I have had exposure to both MOM (Microsoft Operations Manager) and its successor SCOM through my involvement with BizTalk. We have used both of these technologies to inform our team of any issues that are occurring on the BizTalk Servers. I can't imagine running BizTalk without them.

The session itself was dedicated to Cross Platform Management packs. More specifically, using SCOM to monitor your Unix/Linux operating systems and the applications that run on these platforms.

I was impressed with the experience inside of SCOM. The experience of managing and monitoring these platforms is the same as it is for Windows platform. Under the hood SCOM is issuing commands through SSH that is able to retrieve information from the platform or is able to execute a command on those systems.

In the Windows world an agent is pushed to the server that SCOM is going to be monitoring. The process is very similar for Unix/Linux however the terminology is a little different. In Unix the equivalent of a Windows service is a daemon. So you will find that daemon bits are deployed to these servers much like windows.

Out of the box you will find that SCOM has the addressed the core set of functionality that you would expect. This includes:

• File Systems (both physical and logical)
• Memory usage
• Processor Usage
• Network interfaces
• Daemon availability

I wasn't able to catch the entire list of supported flavours of Unix/Linux so the following list is not comprehensive:

• IBM AIX 5.3, 6.1
• HP - 11.2, 11.3
• Red Hat ?,?
• Solaris 8, 9, 10
• SUSE

If you need more visibility than this you can look to some 3rd party packages like Novell's SUSE Linux management pack. For more application specific management packs that run on Unix/Linux you can look to Bridgeways' Management Pack. With the Bridgeways' management pack you can find support for:

• Apache Web Servers
• PostGres Database
• Oracle Database
• DB2 Database
• MySQL
• Apache Application Server
• JBOSS Application Server
• WebSphere Application Server
• Oracle Application Server
• BlackBerry Enterprise Server
• VM Ware ESX
• and more

It was an interesting session. What I found was that Microsoft is very serious in this area. Customers have demanded a composite monitoring solution that allows them to watch their entire enterprise, not just their Windows Servers. Microsoft has stepped up by providing the functionality themselves or by leveraging a 3rd party management pack. Microsoft has also stepped up their game in the support area. They have increased their support capabilities so that when you do have an issue with their Unix/Linux management packs that they will have someone that can speak intelligently about the issue from a Unix/Linux perspective.

Expect SCOM 2007 R2 and these third party management packs to ship June 2009.