Catálogo de publicaciones - libros

The BizTalk Server 2006 product is a group of application services that facilitate the rapid creation of integration solutions. BizTalk Server is designed specifically to integrate disparate systems in a loosely coupled way. BizTalk Server is a toolkit, and within this toolkit you will find tools to help you build your application. The trick, like the wise Scottish man said, is “using the right tool for the right job.”

Every BizTalk development team, regardless of the size, will encounter the same types of problems. The two most difficult issues that new BizTalk architects face in organizing the development team are how to structure the project in terms of the development/build/test/ deploy process and how to appropriately structure the project source tree so that it is optimal for each developer given the task he is working on.

The BizTalk Messagebox is the core of the messaging subsystem. It has the responsibility of storing all message items within the product. The Message Bus subsystem queries the Messagebox and looks for messages that match a subscription. The BizTalk Message Bus is a publisher/subscriber model, or pub/sub. Simply stated, every message going into the Messagebox is “published” so that endpoints with matching message subscriptions can receive the message and send it to the appropriate orchestration or send port and finally to the corresponding adapter. Each BizTalk process that runs on a machine has something called the Message Agent, which is responsible for searching for messages that match subscriptions and routing them to the End Point Manager (EPM), which actually handles the message and sends it where it needs to go. The EPM is the broker between the Messagebox and the pipeline/ port/adapter combination or orchestration that has a subscription for the message. Both the EPM and Message Agent are executed within the BTSNTSvc.exe process that runs on the host. Figure 3-1 shows the Message Bus architecture.

Pipelines are probably the least properly utilized tools in the BizTalk toolbox. Pipelines are designed to do one thing well:

The most important words in the preceding statement are “Examine” and “Modify.” As stated previously, messages in BizTalk are immutable once they have entered the Messagebox. The only proper way to affect a message is to change it in a pipeline either on the send side or the receive side. Before starting a new custom pipeline, it is important to understand that a pipeline by itself does nothing. The real work is accomplished by the pipeline components that are attached to the pipeline. If you are building custom pipelines, 99% of your time will be spent in coding the custom pipeline components, not in building the actual pipeline.

Chapter 4 outlined the “advanced basics” of creating custom pipelines and pipeline components. You should now have the tools that you will need to create well-structured and professional-looking pipeline components. Now that you have learned the internals of how pipelines and pipeline components work, you’ll put your new knowledge into practice. This chapter will explore some of the nuances of pipeline component development as well as give you some best practices for creating and implementing them. We will show you some examples of common problems that pipeline components can solve, along with some advanced implementations of cryptography, compression, and decoding.

The chapters to date have dealt with advanced concepts with regard to pipelines and messaging. Most of the concepts in the previous chapters have involved examining the intricacies of a particular tool within the BizTalk toolkit. Here we’ll show you how you can use some of the more advanced concepts within BizTalk to solve some higher-level scenario-based problems.

Orchestrations are series of ordered operations or transactions that implement a business process. To interact with entities outside the boundaries of this business process, orchestrations can use send or receive ports. You can performtransactions in parallel, execute business rules from within orchestrations, call complex logic in managed .NET assemblies, or call and start other orchestrations. They are by far the most powerful tool in a BizTalk architect’s tool belt. To perform complex routing in BizTalk or do any process automation work, you need to use orchestrations.

The Business Rule Engine (BRE) enables you to encapsulate the creation and management of complex rules to be used from within your applications. These rules can be modified and updated in real time without having to update any assemblies in the solution, thereby providing a great deal of flexibility.

In this chapter, we cover BizTalk Server 2006 operations, which include configuration, management, scalability, high availability, backup, restore, and disaster recovery. A welldesigned and developed BizTalk system can only realize its full potential when married with a well-architected and managed BizTalk operations environment. BizTalk Server 2006 provides a number of new features and tools to improve the operations experience for IT staff. This chapter covers the critical management tasks necessary to ensure a BizTalk system is operating at a high level of performance and availability. In this chapter, you will find discussions of the following topics:

There may be additional areas that require documentation in a specific application’s disaster recovery plan not listed here that must be addressed on an application-byapplication basis.

In the previous chapters, you have seen how to create schemas to define the different messages that your BizTalk applications send and receive, how to create orchestrations for the implementation of business workflows, how to create custom pipelines to customize the different stages of message processing, and finally how to create and maintain ports to receive and send messages. In a nutshell, you have seen how to develop each of the major artifacts present in a BizTalk solution.