Roll Out Strategy in BizTalk Migration
Rollout in an EAI migration project is always tricky – the goal should always be to cause as little disruption and downtime as is necessary. In order to achieve this goal of minimal disruption, an incremental phase approach is recommended.
To further illustrate our phased deployment approach, consider the following scenario which is typical in most EAI implementations in large enterprises - The existing SeeBeyond implementation has a history of having been built incrementally; new programs or upgrades were placed in service individually. Now compound that complexity with migrating the actual EAI logic to a new tool (BizTalk). Deploying such a migrated solution which includes a large number of sub-systems in service all at the same time, even if they are well tested, is an incredibly risky step for any business. Do not be deceived if each subsystem individually has a low bug rate – a single problem can manifest itself in ways across other systems that may not have been tested or accounted for. What typically occurs is that the number of such problems quickly overwhelms and cross-pollutes other systems, crippling the ability of the organization to deal with them. In other words - High Conversion Risk.
Incremental migration strategies entail the decomposition of multi-system implementations in phases which can be independently and selectively addressed and replaced. This reduces the costs and risks of a migration program. The original SeeBeyond sub-systems are retained and used until the BizTalk functions achieve an acceptable level of reliability, then they are replaced. In the beginning the smaller interfaces are piloted as the learning curve is steeper and the number of unknowns greater, so we do not want to overload with a complex sub-system. As we gain greater expertise and vital insights, we attempt to bite of larger pieces and tackle them until we meet with complete success.
In an incremental rewrite methodology, the SeeBeyond system continues to run as the new system is built, tested, and deployed. You will want to try to build the new system in a way that seamlessly integrates with the old system. The side-by-side environment maintains redundancy as functionality moves from the old to the new system.
Posted in: C# and .NET| Tags: Microsoft WCF B2B BizTalk BizTalk Server EAI flagship integration solutions Migrating Windows Communication FrameworkMicrosoft Operations Manager (MOM) 2005 Overview
This section will provide a brief architectural overview of Microsoft Operations Manager (MOM), and explain the basic setup of a MOM system. At a very high level, MOM is Microsoft’s offer that allows operations staff to monitor and manage the IT infrastructure of a company. MOM also offers a rich reporting offering that uses SQL Server Reporting Services to support long-term health tracking and performance monitoring.
MOM Components
Like many of the more advanced products in the Windows Server System, MOM requires SQL Server as the data store for both its configuration data and the actual data that MOM collects from the systems that it monitors. For smaller organisations , deployment onto an MSDE database is supported, but given the volume of data that continuous monitoring of systems will generate, the storage capacity of MSDE will be quickly exceeded in most deployment scenarios.
There are three basic entities in a MOM management system -
- The MOM Management Server, which is responsible for coordinating the overall management of a particular set of IT assets.
- MOM Management Packs, which define how management and monitoring will occur.
- Managed computers, which can be either managed via the installation of a MOM agent (which is the default and recommended configuration) or through an agent-less configuration which uses standard technologies like Windows Management Instrumentation (WMI) for monitoring.
The MOM Management Server is administered through a Microsoft Management Console (MMC) snap-in, and once a MOM Management Server has been configured, management and monitoring is accomplished through the MOM Operator Console, as shown in Figure 1. The Operator Console is a managed application (again proving that Microsoft’s own internal adoption of .NET technologies is continuing to increase) that provides an Outlook-style interface for managing the day-to-day operations of an IT department.
MOM also ships with a web version of the Operator Console called the Web Console, which allows remote monitoring of a MOM Server-managed environment. Of interest to developers is the fact that the Web Console is written entirely using the publicly-released MOM SDK, highlighting the deep degree on integration that MOM makes available.
Management Packs
Management Packs are the glue that binds the whole MOM monitoring experience together. The basic atom of a Management Pack is a rule, which may be an Event Rule, a Performance Rule or an Alert Rule. A rule acts on a piece of data from a provider, which may be a Windows Event Log, the Windows System Monitor (PerfMon) or a custom log file. A rule applies criteria against this data that a provider makes available, and if this criteria is met, a response can be trigger. A response may be an email, pager notification or execution of a piece of managed code. Finally, knowledge can be applied to a rule, so that operations staff responding to an alert trigger by a rule being fired have ready access to documentation that they can use to diagnose and rectify the problem. Figure 2 shows a MOM rule and supporting entities.
Posted in: Software Programming C# and .NET| Tags: Microsoft .NET technologies Management Packs Microsoft Operations Manager MOM MOM Components MOM Management Server MOM Operator Console MOM SDK PerfMon Windows Management Instrumentation WMIArchitecture of an Application Block in Enterprise Library
The client code calls into the ProviderBase Factory class with the Create ProviderBase method. The ProviderBase Factory then calls the ProviderBase InstanceFactory class. This class calls the Enterprise Library core, which examines the I ProviderBase interface for the attribute that tells it what sort of custom factory to use. It creates an instance of that class and uses it to discover the appropriate configuration object. In this case, the correct object is the Provider Data class. The core then examines the Provider Data class for the Assembler attribute that tells it which assembler to build. It builds the assembler and passes it the Provider Data class. The assembler constructs an instance of the Provider class.
Application Block Software Factory Generated Files
Application Block Software Factory produces application blocks that have a run-time component and a design-time component. The run-time component implements the application block’s functionality. The application block also provides the configuration schema, which defines the application block’s behavior. The design-time component makes it possible to display this information in the configuration tools. Either of these tools allows you to read an application block’s current configuration, to change it and to store it. Most of an application block’s functionality and configuration information is contained in classes that implement the providers.
The Run-Time Component
Table 1 lists the most relevant run-time classes created by the Application Block Software Factory that implement a provider’s functionality.
Table 1: Run-time component classes for functionality
Class name
Description
Provider
This class is an implementation of the provider base class. The Create New Provider (Typed) or Create New Provider (Untyped) recipe creates this file.
ProviderBase Factory
This is a static class that has a Create Provider method. This method allows users to create instances of the provider. The New Provider Factory and Base recipe creates this file.
ProviderBase CustomFactory
This class finds the correct configuration information for the provider that is being instantiated and returns it to the Enterprise Library core. The New Provider Factory and Base recipe creates this file.
ProviderBase InstanceFactory
This is the entry point into the Enterprise Library core. The New Provider Factory and Base recipe creates this file.
ProviderBase
The provider base class that implements the I ProviderBase interface. Provider implementations derive from this class
I ProviderBase
The interface that the provider base class implements. The New Provider Factory and Base recipe creates this file.
Table 2 lists the run-time classes that contain an application block or a provider’s configuration information.
Table 2: Run-time component classes for configuration information
Class name
Description
ApplicationBlock Settings
This class defines the application block’s configuration information. The design-time counterpart of this file is ApplicationBlock SettingsNode class. The Create Application Block recipe creates this file.
ProviderBase DataRetriever
This is a helper class that is responsible for retrieving the default instance name from the configuration.
ProviderBase Data
This class defines the base provider class’s configuration information. The design-time counterpart is the ProviderBase Node class. The New Provider Factory and Base recipe creates this file.
Provider Data
This class defines the provider’s configuration information. The design-time counterpart is the Provider Node class. The Create New Provider (Typed) or the Create New Provider (Untyped) recipe creates this file.
The Design-Time Component
The design-time component translates between the run-time configuration classes and the Configuration Console’s UI display. Table 3 lists the most relevant design-time files created by the Application Block Software Factory.
Table 3: Design-time component classes
Class name
Description
AddApplicationBlockSettingsNodeCommand
This class represents the menu command from the application that is used to add the configuration for the block (that is, “New, Data Access Application Block”)
ApplicationBlock SettingsNode
This class mirrors the properties in the ApplicationBlock SettingsNode. It represents the block’s top-level node in the configuration tool.
ApplicationBlock SettingsBuilder
This class translates the information in the UI configuration hierarchy nodes into run-time configuration classes. This is necessary in order to save the configuration information. The Create New Application Block recipe creates this file.
ApplicationBlock SettingsNodeBuilder
This class reads the configuration information by translating run-time configuration information into UI configuration hierarchy nodes. The Create New Application Block recipe creates this file.
CommandRegistrar
This class contains commands that place the nodes at the correct places in the configuration hierarchy. For example, the CreateSingleUICommand command ensures that a node only appears once. This class also associates the nodes with the correct UI commands such as Rename and Replace. The Create New Application Block recipe creates this file.
ConfigurationDesignManager
This class defines the UI commands, such as New, and the node maps for the configuration hierarchy. A node map defines the correspondence between the run-time configuration information and a UI node. It also contains the OpenCore method that reads the configuration information. The Create New Application Block recipe creates this file.
NodeMapRegistrar
This is a helper class that creates a mapping between nodes and configuration information. The Create New Application Block recipe creates this file.
ProviderBase Node
This class mirrors the properties in the ProviderBase Data class. It also defines characteristics such as the Configuration Console category for the property and whether or not the property is required. The New Provider Factory and Base recipe creates this file.
Provider Node
This class mirrors the properties in the Provider Data class. It also defines characteristics such as the Configuration Console category for the property and whether or not the property is required. The Create Design-Time Provider Node recipe creates this file.
Posted in: Software Programming C# and .NET| Tags: NET Enterprise Library Microsoft Enterprise Library application block provider ProviderBaseFactory CreateProviderBase IProviderBaseGlossary of Terms in Microsoft Enterprise Library
application block. A reusable software component that is designed to help developers with common enterprise development challenges. For example, the Enterprise Library includes a Data Access Application Block that developers can use to incorporate standard database functionality into their applications.
base node. The design-time counterpart of the run-time provider base class. Generally, the base node is defined in the BaseClassName Data class. The design-time project includes this class.
design - time project. The design-time project contains the files that make the application block and its providers visible and configurable in the Configuration Console and Visual Studio Configuration Editor.
default instance. The provider instance that the application block creates if the Create method has no type parameter. You define the default instance in the Create New Provider Factory and Base Wizard.
provider node. The design-time counterpart of the run-time provider implementation. The Application Block Software Factory creates a node when you complete the Create a Design-Time Provider Node wizard. Generally, the node is defined in the ProviderName Data class. The design-time project includes this class.
parent UI node. The node that contains the current node in the configuration hierarchy.
provider. A .NET object that supplies some functionality. The Enterprise Library includes many providers. For example, there is a provider that allows you to connect to a SQL database, execute commands, and retrieve results. The Application Block Software Factory creates a provider implementation when you complete the Create New Provider wizard. Generally, the ProviderName class defines the provider implementation. The run-time project includes this class. You can create either typed providers or untyped providers. Typed providers have strongly-typed their own strongly-typed configuration classes. Untyped providers use a generic name/value collection.
provider base class. The class from which provider implementations derive. The Application Block Software Factory creates a provider base class when you complete the Create New Provider Factory and Base wizard. Generally, the ProviderBaseClassName class defines the base class. The he run-time project includes this class.
provider library. A .NET Framework assembly with a corresponding Visual Studio project that contains a number of providers. These providers extend the functionality of an application block. This application block is included in a different assembly.
reference node. A node that the current node needs to correctly function. When you use the Application Block Software Factory to build a design-time project, you enter the value of a property’s reference node when you use the Create a Design-Time Provider Node wizard. Reference nodes appear as types in the dropdown list in the Configuration Console’s property pane. For example, in the Logging Application Block, if you have a trace listener that logs to a database, the reference node is the connection string for the database. If you are using a SQL database, you use the dropdown list to select System.Data.SqlClient as the type. You define a reference node when you define a provider’s properties in the Create New Provider wizard.
run-time configuration type. The class that contains the configuration information that the design time uses for the configuration tools.
typed provider. A provider that includes a ProviderName Data class. This class contains the run-time configuration information. This configuration information can be used in the design-time project so that the provider’s properties and values will appear in the configuration tools.
untyped provider. A provider that has a generic provider data class. This class uses a name/value collection that can apply to different types of providers.
Posted in: Software Programming C# and .NET| Tags: NET Enterprise Library Microsoft Enterprise Library application block base node default instance provider node provider reference node provider libraryAutomated Testing with Unit Tests
Being able to automate the testing process of your projects is an important feature of a CI-environment. Having source code that works as tests for your application logic will help you when you’re later going back to modify, extend and fix existing code. With good tests you can ensure that your code changes won’t break the whole application. There are different frameworks available for unit testing, the most widely used with .NET is NUnit (http://www.nunit.org). To learn more about test-driven development, visit Wikipedia: http://en.wikipedia.org/wiki/
Test-driven_development.
When the installation of NUnit is complete, you can explore the included samples to learn more about writing unit tests. You can use the NUnit GUI to run your unit tests outside of the CI-environment.
To start writing unit tests, you need to add a reference to the following assembly in your Integration.Test project: “C:\Program Files (x86)\NUnit 2.4.8\bin\nunit. framework.dll”. Additionally you should create a reference between the Test and the Common project, so we can access our business domain model in the tests project.
When you’re done adding the reference, let’s create a class named PersonTest.cs which will contain all the unit tests for our specific domain object.
Tests are done through assertions. There are many types of assert methods included in the NUnit framework and you should use them to validate your business logic. Writing good unit tests is hard and it’s a practice in which you will continually improve as you get more experienced with it.
You can now begin to run and validate the unit tests on your local machine, open the NUnit GUI application and open the Integration.Test.dll file.
As you can see in my screenshot, both of the tests for the Person object validates.
When we later go back to change the business logic, we can use the unit tests as a means to validate that our changes doesn’t break anything.
Finding Answers to Specific Problems – search engine
I have heard colleagues muse about the changing role of “software developer,” postulating that development has become a job mostly concerned with research and discovery. While that is no doubt an overstatement, the ability to find information quickly is an important skill. The place many of us turn to first is our search engine of choice whether it’s Bing (replaces Live Search), Google, or a meta search site like Dogpile.
The appeal of most search engines is the beautiful simplicity of a single search box, but the needs of a developer are not simple when you factor in multiple versions of frameworks, programming languages with similar constructs, and behavior differences between competing products (I’m looking at you, Structured Query Language and Cascading Style Sheets). With just a short time investment, you can learn some advanced search operators and tricks to help narrow search results to exactly the information you need. For example, search for “live advanced search keywords” or “google advanced operators” and you’ll find a bunch of operators to help you become a search ninja.
In addition to your search engine of choice, Wikipedia can be an invaluable problem solving tool. I have found Wikipedia to be especially useful when searching for general topics such as common computer science algorithms and concepts. Although I often end up at Wikipedia through search engine results,
Wikipedia has its own search box right on the home page (http://wikipedia.org/).
Of course not all problems will have solutions waiting to be discovered via a search engine. Some problems have already been solved in another part of your organization and you simply have no idea about the pre-existing solution. There are many tools designed to help companies deal with code asset management and search behind the firewall. One interesting product is Krugle, a specialty search engine built for indexing and searching code.
Efficiency Upgrade for developers
Developers solve problems. Good developers solve problems efficiently. The reward for that efficiency is [insert your preferred reward here]. Let’s assume you’re simply motivated by the satisfaction of a job well done (or maybe a promotion, a raise, longer lunch breaks, or just some extra time with your family). Whatever the motivation, the secret to solving problems efficiently is not inventing everything from scratch. Certainly the secret is not spinning your mental wheels hoping for inspiration. And most definitely the secret is not using
Intellisense to arbitrarily try classes, methods, and properties until something works.
The secret to solving development problems efficiently is having the right information and the means to find the information you don’t have.
If you have been developing software for more than a week, you know that a working knowledge of language syntax and program construction
(that is, “programming”) is only a small part of the necessary skill set for solving problems with software. As a developer, you need to understand the technologies, processes, and methods available to you. You also need to have a set of reliable resources you can turn to when you encounter problems.
Below you will find some resource recommendations to help you find the information you need to help solve development problems more efficiently so you can get on with living the rest of your life.
Security Application Block Dependencies of Enterprise Library
- Core library functionality. The Enterprise Library Core provides services, such as instrumentation and configuration, and is a shared dependency of all Enterprise Library application blocks. The core library functionality is contained in the assembly Microsoft.Practices.EnterpriseLibrary.Common.dll.
- The ObjectBuilder subsystem. The ObjectBuilder subsystem performs all of the repetitive and necessary tasks for creating and disposing of object instances, while still providing a high level of flexibility. Enterprise Library uses the ObjectBuilder subsystem for tasks such as injecting configuration into block classes and connecting instrumentation classes to application blocks. The ObjectBuilder subsystem is contained in the assembly Microsoft.Practices.ObjectBuilder.dll.Depending on the specific functionality you require from the Security Application Block, you may also require the following application block contained in the Enterprise Library:
- The Caching Application Block. The Security Application Block uses the Caching Application Block to cache security information and then retrieve it when required. You can replace the Caching Application Block with your own caching provider. Depending on how you configure the Caching Application Block, you may also require the Data Access Application Block. For more information, see the Caching Application Block documentation.
Security Application Block Documentation
Together with the introduction, the documentation contains the following topics:- Design of the Security Application Block. This topic explains the decisions that went into designing the application block and the rationale behind those decisions.
- Developing Applications with the Security Application Block. This topic explains how to download and install the application block so you can use it in your applications. It also is divided into several subsections. The first subsection, Entering Configuration Information, demonstrates how to configure the application block to perform common tasks. The next subsection, Key Scenarios, demonstrates how to use the application block to perform the most typical security operations.
- Extending and Modifying the Security Application Block. This topic explains how to extend the application block by creating your own providers and how to modify the source code.
- Deployment and Operations. This topic explains how to deploy and update the application block's assemblies and also contains information about configuration.
- QuickStarts. This topic explains how to install and configure the QuickStart applications and contains a series of walkthroughs that demonstrate how to incorporate common security operations into an application.