Provide Feedback on this Broadcast

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Erik Leaseburg: Welcome, everyone, to this session today on Microsoft® BizTalk® Server 2004.

I want to give you a technical overview of the product. I'm assuming that you may have been playing with the beta version of the product. That is a public release, and I'll be giving you a link to that later. However, if you have not been working with the product in the past, or with the current beta version that's out on the Web site, I'll still be giving you an overview from the ground up, so that you'll be able to understand the various features of this new version of BizTalk Server, from a technical point of view. And then, of course, you'll have time for Q&A at the end to ask your questions, if there's something that I didn't make clear.

If we go here to slide number 2, the agenda, you'll notice that there are a couple of things that I want to cover here, and it's a pretty aggressive agenda, so I'll probably move fairly quickly. And you'll be able to go back and view the recording later, of course, to catch anything you miss. But there is a lot to the product, so I want to make sure that I try and cover as much as possible during our time here.

I want to talk about the remaining enterprise integration challenges that still face a lot of companies today, and then talk about the various features of BizTalk Server 2004 that help address those challenges in many ways, with this new release of the product.

We'll talk about the architecture, the message flow, and the adapters that are available for the product to be integrated with other systems. We'll talk about this really exciting interface to Visual Studio® .NET that's now part of the product, and the developers will really enjoy this. We'll show you more about orchestration and how it's integrated into Visual Studio as well. And how you can also now integrate Web services very easily into BizTalk Server projects, through the Visual Studio standard interface mechanism.

We'll go on to talk about how you deploy and configure BizTalk now. With this new version it's been made a lot easier. We'll talk about the Rule Composer, which is a new add-on for the product that is a very powerful rules engine. Also, there's a new feature, Enterprise Single Sign-On. And there's business activity services and monitoring.

On to the next slide (slide 3): wrapping up our agenda, we'll talk about Human Workflow Services, yet another great new feature of the product for doing human workflow integration. We have trading partner management for hooking up to many different trading partners, if you're dealing with a large number of customers in your base. We'll talk about some of the great improvements in the health and activity tracking, and the debugging features of the product. And finally we'll wrap up the BizTalk piece with some server administration, scale out, and performance examples and numbers. And we'll show how to migrate existing BizTalk 2002 solutions to the 2004 solution.

Then we'll just cover some final points around Microsoft Office System 2003 integration, with the launch of that product just yesterday. There are some really interesting scenarios around integrating with Office Visio® and InfoPath™, as well as Word, Excel, and many of the other features, now that XML is at the core of the Office System products as well. And finally, we'll give you some great resources for you to go out and learn some more on your own.

On the next slide (slide 4), here I talk about the challenges that many companies are still facing, even though they've spent significant time and effort on trying to aggregate data into large systems, say an enterprise resource planning (ERP) system, like SAP, J.D. Edwards, PeopleSoft, Oracle, Baan, or many of the other great ERP systems out there. A lot of that data still seems to be locked up in these large systems, but in many cases we find, through some research from Gartner, that a lot of data is still being kept right on the user's machines, in file folders, in spreadsheets. Eight percent of the data still resides in enterprises on the desktop. And so there is a challenge with getting to this data that's on the desktop and sharing that with others. That's one challenge around enterprise integration.

Also, some companies out there, Global 2000 companies that have been implementing systems like SAP, are finding that not everyone, obviously, is getting into that large ERP system and using that data to help them ease their day-to-day business challenges. Typically there is only one user for every five non-SAP users, in a Global 2000 company, who is using that system and using all of that great data that's there. There are still many others in the company who could use that data and who would probably find some value in it, if they had a simpler interface to that information that made sense to them.

System-driven integration, however, is only half of the battle; being able to get two back-end systems to talk to one another is a great accomplishment. Yet, you still, in the end, have to have those end-user information workers, those users at their computers, at their desktops, be able to get to this information in an easy and understandable way. And so trying to connect those end users to their data in these back-end systems is the other half, the missing piece of the puzzle, and BizTalk 2004 is helping to ease that integration challenge.

On the next slide (slide 5) we'll talk about the three main silos of users, or three types of individuals who need to be able to manipulate information within the company. You have your information worker, who is the end user, possibly taking orders or making decisions about marketing, or other types of business decisions. They need to be able to look at the information in these various systems in a way that they understand, and they may possibly come up with new business processes, if they're a business analyst and they need to come up with a new way of getting their products to market faster.

They might be doing business process design. Perhaps they are someone who wants to change the rules in which the business operates. Perhaps because of changes in the market, they may decide to change the discounts provided for different products, and they want to be able to go in and quickly change that information in the system and then allow that to propagate through to the various front ends that their customers may see, through printing catalogs or even through outlining systems. They need those rules that they change to take effect wherever they need to make a change.

They need to be able to access the real-time information about the patterns of usage by consumers of their products, or the services that they provide through an online site, through a catalog, or through other mechanisms. They need to be able to see that data quickly and easily, to know that when they make these changes in the business process or in the business rules, that those changes are having the effect that they expect; it's sort of a feedback loop that's necessary.

IT professionals then are also involved in the overall process of integrating systems and providing that data to the end users, because they're there making sure that the systems are in place and up and running. And if there are any issues, they can quickly resolve those. So they need tools that allow them to quickly deploy new versions or new solutions, to manage those solutions, and to make sure that if a solution has an issue, that they're able to monitor and find and resolve those issues quickly, through easy-to-understand error reporting.

And last, but not least, our focus on the developers is still true at Microsoft. We want to make sure that a developer can quickly get in through a single integrated development environment (IDE), that they can quickly build an integrated solution from scratch, or that they can collaborate with others in their workgroup to build an end solution.

The technology infrastructure then that's required to allow for all of these individuals to work together is a set of tools that BizTalk provides.

So if we move on to the next slide (slide 6), let's start talking about how BizTalk helps to alleviate some of these issues and helps all of these different types of people within an enterprise to work together. With BizTalk, we've taken some of the great features and the many lessons learned through a number of customer installations of the product today, and we've just taken that to a whole new level, with a whole new generation of BizTalk server technologies and capabilities in this product. You can almost think of BizTalk Server 2004 as sort of a generational jump of the product from its previous BizTalk 2000 and 2002 designs. We really looked at the product from the ground up, and we added a whole lot of additional features and capabilities to make it an even greater solution for our customers.

We've built in a number of advantages to the product that you'll find as you open the solution and open the system for the first time. We've really focused on integrating businesses more seamlessly. E-business is a major area of investment for Microsoft now. We have a whole e-business group that's working on solutions to help companies integrate their businesses electronically, and BizTalk Server is just one of the products from that group. So we're really putting a lot of time and money into helping customers ease their integration challenges and their e-business challenges.

The Enterprise Application and Integration (EAI) capabilities of the product are still there. EAI is a space that BizTalk Server 2000 and 2002 played well in, and BizTalk 2004 continues to make EAI a focal point. But also, BizTalk Server 2004 is a great B2B, business to business, and a B2C, business to consumer, platform as well. And we work on the solutions with BizTalk being sort of a process-centric computing machine, or a process that allows for multiple systems to interact and communicate with one another easily and effectively.

It's also a very scalable and a very reliable system for publishing and subscribing to messages. The engine itself has been re-architected to conform to a more publish/subscribe type of architecture. This allows you to interact with the system through publishing messages to the system and also subscribing to various types of messages in the system. And processing those depending on the type of message, the actual properties of the message, the contents of the message, and subscribe to the kinds of messages you want.

The rules engine that's been added to the product with 2004 is highly performant, and we'll have some numbers a little later to describe that. The Enterprise Single Sign-On capability that's been added to the product allows for developers to focus less on maintaining this reliable data, this sensitive data in custom formats that they have to come up with themselves, and that may not be as secure as they would like, because of the time frame they have to develop some of these solutions. The Enterprise Single Sign-On solution allows you to actually store this sensitive information in a secure architecture that we'll define in a little bit.

And finally, the BizTalk Server 2004 product is the first product that's going to be coming in a wave of products that you can expect over the coming year. So BizTalk Server 2004 is laying the groundwork or the framework for a number of other integration products that have already been on the market in other versions, but that will now be integrated into the overall "Jupiter" framework, we call it. It's sort of a code word we've used here at Microsoft for the line of products that will allow for companies to integrate their information, with their front-end users being able to see the information, being able to place the orders, being able to interact with a company through a B2C model, as well as businesses being able to interact with other business trading partners.

New content and new capabilities will be published in a versioned and controlled way. And finally, legacy systems or host systems will be able to be easily integrated into the systems or these EAI solutions. So you'll see, after BizTalk Server launches, other launches, such as the Commerce Server product in its next release, the Content Management Server product, and the Host Integration Server product. They will all be integrated with one another in a much tighter and more seamless way.

Moving on to the next slide (slide 7), I want to give you sort of an overall framework or architecture to get a feel for how the various pieces of BizTalk Server 2004 fit together. At the core of this architecture is the message box or the store for these messages that are flowing through this publish/subscribe model or system. These messages are documents that are possibly being passed between two systems, as far as a BackOffice® solution, or they might be a consumer message that's being passed to BizTalk to then be routed to back-end systems or to other partners. Or it might even be two businesses communicating with one another. This message box is at the heart of the system. It's a SQL-based message box, SQL Server™, and this message box, a database within SQL Server, is storing these messages and serving as a repository in a storage area for all messages, for reliability and availability purposes.

Outside the message box is the capability to correlate various messages flowing through the system with the appropriate processes they are tied to. That way, as different messages come in that relate to previous processes that have begun, but have not completed, those messages can be properly routed to the appropriate process. Content-based routing then is also critical, so that you can look at the message itself, see the contents of a given document, possibly a purchase order, pull apart the various parts of that purchase order, and then send those individual pieces of the purchase order off to the various partners to fulfill that order.

Outside of the correlation and content-based routing, we then have activation and instance management, which allows you to have your various processes activated at the appropriate times. As necessary, those processes can even be what we call dehydrated, or basically serialized into memory or into disk, and then later returned via the dehydration process, which will then return the running process back to its active state to continue processing. And this is especially important when you have long-running business processes that may take several hours, minutes, days, or weeks. There may even be seven-year to ten-year cycles for certain manufacturing scenarios, where there are long lead times required on certain types of orders; the aviation industry and others are sort of like this.

And so for those types of processes that may take years to execute, it's necessary to be able to quickly activate and run those processes when some type of action or message has been received, and subscribers to that message are able to then process the message. But then when you reach a hold state, where maybe it takes a couple of minutes or hours before the next action needs to take place, or you need to wait until a future action where a response is returned back to your system, that information can be dehydrated to disk, so that that process can be freed up and those threads can perform other actions and activities on the system.

Outside of this core processing engine, where the message box is at the core, you have orchestration, which is available in BizTalk 2004. BizTalk 2004 allows for the orchestration that the 2000 and 2002 BizTalk users were made aware of, where you used the Visio design tool to define a new business process and turn that into actual running code fairly quickly, by integrating the business process with back-end systems through COM interfaces or Microsoft message queue interfaces. The orchestration capabilities are still there in the product with 2004, and you'll see how they've been made even more powerful and easier to use. Of course, it's also possible to integrate your own applications or other applications, whether they're Microsoft, COM, DCOM, or .NET-based, or other types of applications that might not be .NET based, say J2EE types of applications, which can also be integrated in with the system.

Down below the message box then we have the information about how the adapters and the pipelines are used to get information into and out of the message box. How do you actually get these messages into the system, then make some decisions about the messages flowing into the system and then send those back out? Well, that's been through, first, the adapters, which is a transport layer that allows you to take in information in many different transport formats, and then send that information back out. Some of the transports supported are HTTP or SOAP for Web services. You can also pick up messages from a file folder or send to a file folder, whether that's local or on a file share.

BizTalk Message Queuing is also supported. This is a little different than Microsoft Message Queuing, and I'll make that distinction a little bit later as well, to give you some more details about that. Also, we have the ability to read information from a SQL Server database and send information to a SQL Server database or table, to insert, update, or delete rows. The FTP adapter allows you to actually send information off to a remote FTP server or pick up from a remote site. Also, there are adapters for SAP and MQSeries that we will be providing, which will allow you to more easily integrate directly with an SAP or MQSeries system without having to write as much custom code. And finally, there are your own custom adapters. If you have your own custom back-end systems, your own custom transports that you need to support, you can build adapters using a new powerful, common adapter framework, a BizTalk adapter framework, that's going to be common to all of the Jupiter products, including BizTalk Server.

The message pipeline then is the next layer, where after the message has been picked up from a file location, or maybe sent via HTTP to the server, it's then processed through a number of steps to turn that message into a resultant XML format. Perhaps the message was sent as a flat file, maybe comma-delimited or some other binary custom format, and it has to be transformed, as well as interrogated to make sure the message has not been tampered with or changed in any way, and to understand who it's from. So, the pipeline is sort of a process where the information is sent through a set of steps that you can define, and you can have one to many steps that take place, or possibly no steps, simply sending the message straight through if there is no processing required.

Some of these steps include decoding the message; decrypting the message if it's been encrypted in some format; possibly authenticating any signatures that have been attached to the message, to ensure it was from the intended user or the intended sender, so that the recipient understands and accepts that authentication protocol; parsing the message as necessary to pull out the necessary business information; extracting any special properties or metadata about that document or that message; and finally, any custom components that might be required.

The left and the right side of this slide describe to you some more steps that are required to allow you to integrate the system with a number of other systems in the environment. Some of these things include the administration capabilities, deployment, process management, and trading partner management capabilities of the product. The administration is still available through a Microsoft Management Console, or MMC snap-in type of capability, but there are also some additional administration features that are available in the product. Deployment we'll find is made a lot easier through the fact that all of your project information is compiled into a single .dll. Although if you do have multiple .dll files, you can deploy those using various mechanisms that we'll talk about in a little bit. Process management and trading partner management: we'll get into all of those details in the next few slides.

On the right side, we have some new capabilities around business intelligence, allowing you to extract information about what's happening in the system and about messages flowing through the system, to be able to make intelligent business decisions. Reporting and monitoring, of course, are also there in the product.

On the next slide I want to talk about the BizTalk message flow. Here on slide number 8 I've given you a pictorial way of understanding how this information or these messages flow through the system and eventually are sent into their intended destination. Because BizTalk is typically just a router for the information from one system to another, although it also will track a number of details about that message as it's routed to its intended destination, which can be helpful for doing business intelligence gathering.

You may have, in this case on the top-left side of the slide, a number of documents coming into the system from various sources. You might have XML files, flat files, or binary files that are being received by the system through many different transport mechanisms. They might be HTTP requests being sent to a Web server, or they might be an FTP server that's having documents dropped to a certain file location, or it might be an SAP system that's sending information in. Whatever format the messages are in, they are received through what is called a receive location. And that receive location contains the receive adapter that I talked about earlier, those adapters that allow you to receive information from various sources, whether it's a Web service type of receive, a request that's being sent into the system, a file being dropped, or SAP or MQSeries type of message coming into the system. That adapter picks up that message and then passes it to the appropriate pipeline to decrypt the message, parse the message, and do the other various steps in the pipeline that you've defined. And you can define custom steps as well, possibly resolving the party as well, to understand where the message came from. And finally, the result of that pipeline message is an XML document.

Note that there is the capability to have more than one receive location, and those multiple receive locations might mean that you have different partners that wish to communicate the same type of information to you, but each partner uses a different mechanism to communicate with you. So the ability to group these different types of receive mechanisms or receive locations together under a common receive port is very powerful. So that you could have one partner that prefers to send you e-mail with their orders, whereas another partner prefers to send a direct HTTP request to a specific URL, and then you can process the message that way. You have that ability to pick up messages with different types, and then using appropriate mapping criteria, you can map the document to one common format, if all of the different vendors are sending you information that's roughly equivalent, but just in different formats.

That XML data is then finally stored in the message box database as a central repository for availability and scalability purposes. This message box database, as I mentioned earlier, is SQL Server hosted, and the intended destination is then based on the information configured in the receive location and the receive port. At this point, the message box has a number of subscribers that are watching for messages of different types, looking at the format or the schema of the message possibly, or individual fields in the message to determine whether or not that message was meant for them.

These various processes may include an orchestration, as I show here in the middle, and an orchestration is an actual business process defined graphically, and then continually implemented directly in .NET components, COM components, or other types of components. This orchestration process, if it sees a message meant for it in a message box, will pick that message up as XML. It will process it, make various decisions, possibly perform various actions, make WHILE loop type of iterative operations on the message, send the information off to other systems, possibly query systems to determine what to do with this message, and then pass that information back to the message box for final routing.

The message box, to send the message box off to its intended destination or multiple destinations, will use sort of the reverse of the receive location, called the send port. And the send port uses a send pipeline, which is sort of the reverse of a receive pipeline, that is meant to take the message from an XML format and serialize it to its intended format. It might, again, be XML or it might be a flat file or other custom binary format. It can also sign the message, encrypt the message, and do other common tasks or even custom tasks that you define.

A send adapter, just like a receive adapter, is then used to send the message off to a specific destination, using a specific protocol. Again, it could be dropping to a file folder, sending to an HTTP URL address, MQSeries, message drop location, or an SAP system. These send adapters can also be custom built by you, and sent your own custom systems as necessary.

It may be necessary for the system to send the same message to many different locations, possibly if you're in a scenario where you're a hub and someone is sending you a request for a quote on, perhaps, a desktop computer system. And your site's sole job is to take that message and send it off to all of the subscribers or all of the various vendors out there that are willing to post a quote. When those vendors want to get that information, they've already defined what types of systems they're willing to state quotes for and when and how to be contacted, whether they wish to receive that request for a quote via e-mail or via a URL address, or Web service call. And so the ability to group together the same message, but sent in many different ways, is handled by a Send Port Group. This is an optional capability, where if you need to be able to send to just a single system or a single user, you can just use the send port. But if you need to be able to send to multiple systems, you can use the Send Port Group. The Send Port Group also has the ability to route the message to various users based on filtering criteria, and it can also map the XML document in various ways, depending on how the various send systems require the document to be formatted.

If we go to the next slide, number 9, on the Universal Message Box, here I want to just hone in on some of the architecture features of this message box that I talked about earlier. The SQL Server–based message box is designed for a very scalable, very available type of solution, based on SQL Server 2000 Service Pack 3. It is, as I mentioned, a publish/subscribe architecture where messages are published to the message box by the receive adapters and the receive pipelines, the receive locations, as I mentioned on the previous slide. And then, as appropriate, subscribers to that message box may include orchestrations themselves or orchestration instances that are picking up messages that have been processed. Or they could just simply be a send port, which includes a send pipeline or a send adapter, where you simply want to take a document in and then route it off to its intended destination, and no orchestration is required.

The server itself, and the servers that are participating in watching the message box, are stateless by nature, so that it's possible to have many different servers in a farm configuration watching for messages being posted to the message box. Also, a number of servers can be posting messages to the message box, which allows for a nice scale out scenario, which we'll talk about in a little bit more in detail later. You'll also find with this message box that the latency in general is very low, and the volatility of the routing is quite high, as far as being able to take messages of many different types and many different formats, and quickly routing those as appropriate to their intended destination.

The message box, as a SQL-based storage mechanism, also allows for large message support. And this is an improvement over the BizTalk 2002 product, where Microsoft Message Queuing was required for a lot of the routing and document storage capabilities. And therefore, with the Microsoft message queue being at the heart of BizTalk 2002, there was an inherent 4-megabyte (MB) limit that was imposed on all messages flowing through the system. And you could work around that limit by breaking the message up into smaller chunks and passing that through, but that usually required some coding, and it was just some extra headache that developers had with the previous product. With BizTalk Server 2004 you'll find, with this message box being SQL Server hosted and with no reliance on Microsoft Message Queuing, that that 4-MB limit has gone away, and that the messages in general, if they're large in size, much larger than 4 MB, they'll still be handled quite efficiently by not only SQL Server, but also many of the components in the system. The adapters, pipelines, and orchestrations in general have all been designed to also be able to handle large messages, streaming those in a much more effective way.

The adapter architecture is also very flexible and pluggable, as we mention here, allowing you to plug in and add any of the adapters we provide very quickly and easily, purchase additional adapters from us, such as SAP or MQSeries, or be able to build your own adapters and plug those in quickly. You can even build adapters that you provide as a service or a product to other customers. They can then very quickly and easily plug those into their architecture with no coding.

Security and auditing has also been improved in Microsoft overall, especially with all of our products that are releasing. We are focused very much on the security, wanting to make sure that we reduce, as much as possible, the footprint of the application and the ability for hackers and those with that intent to be able to come in and do things to the system. So we've definitely focused on any of the system components where there are exposed interfaces, such as the HTTP service and those services that tend to get hit by hackers quite often. So we've made sure that we have isolated those components and have also tested and run those through a number of security reviews to make sure that they're very secure in the way that they've been built. We've made sure that they can also be isolated off into their own process and given very strict permissions, so that the permissions given to high-risk parts of the system don't necessarily have to be applied to all of the systems. So you can assign different levels of risk and different criteria or different capabilities to the various parts of the system at run time.

On our next slide (slide 10), as I mentioned, there's this pluggable adapter framework called the BizTalk Adapter Framework. It has been improved over the previous framework that was called the application integration component framework (AIC) components that you would write. It's a similar framework, but it has a lot more capability around being able to build adapters that are synchronous or asynchronous in nature, that are just one-way send or one-way receive adapters, or that might be a request/response type of send and receive adapters, or that receive a request and then send a response back type of receive adapters.

The adapter framework in general is going to be used going forward with the other products in the Jupiter vision, so it's a very robust framework. And we have a number of adapters that were already built today for BizTalk Server 2000 and 2002, which are being migrated to 2004. A number of our adapter partners are moving their adapters over to 2004. You can just see here an example of some of the different data adapters, for getting into various back-end data systems, that were available with BizTalk 2000 and 2002, and which are being migrated to 2004 by those adapter vendors. Also, there are many application-specific adapters for allowing the ERP systems, like SAP, that we're building an adapter for, as well as Baan, Oracle, J.D. Edwards, you name it. And then from a vertical point of view, some of the industry-specific solutions around HIPAA, RosettaNet, and other industry standards that were developed for the previous versions of BizTalk are in the process of being migrated and upgraded to the BizTalk 2004 adapter framework.

And finally, there are low-level infrastructure type adapters, or technology adapters we used to call them, for being able to send data in a very specific transport format or mechanism that might be specific to a certain system or host system. There are also adapter vendors out there that are working to move their adapters to the 2004 adapter framework standard.

The next slide (slide 11) talks about some of the really great features around the developer side of the house, and for the developers, this is what the next few slides are going to focus on. This one-developer experience is pretty critical, we feel, to being able to quickly design, develop, and deploy a solution as a developer. And so we really focused on Visual Studio .NET 2003 as the core for the developer experience. A developer will no longer have to go off to the Start menu to launch three or four or five different applications to be able to design an end-to-end EAI or B2B solution, but they will be able to do most of what they need to do right there in Visual Studio directly, as one environment.

If you were a BizTalk developer in the past, you'll find a lot of your friendly interfaces, such as the editor, mapper, and the Orchestration Designer, are now directly hosted in Visual Studio. And this will allow you to enhance and build on your existing Visual Studio knowledge, even if it was Visual Studio 6.0 or previous versions. With Visual Studio .NET, you also have the ability to harness the power of the .NET Framework in your code, because all of the various components and code snippets that you might write for the various tools in BizTalk use C# in the .NET Framework as a standard. But there's also the capability to write your own custom components that you integrate in your solution, and those can be written in any .NET-compliant language. It's also, of course, possible to continue to integrate in classic COM and DCOM types of components into your solution, because .NET does have the ability to interoperate with COM solutions.

Moving on to the next slide, 12, where we talk about the Orchestration Designer a little bit more. In the past the Orchestration Designer was a separate tool that you would launch, and it was actually Visio with some extra components added on to it, so it had very much a Visio feel. And our goal there with the previous versions of BizTalk, with the Visio interface, was to try and capture both the developer and the business analyst in a common tool and satisfy both of them. What we realized though is that for the developer, for them to be most productive, we need to make sure this tool was integrated directly with Visual Studio. And so there's no longer a requirement, actually, for Visio to be installed with this new version of the product. Although I'll talk a little later about how Visio is still going to be used by the business analyst to design a high-level business process.

Now, with Visual Studio .NET 2003 and BizTalk installed, you're able to go in and add new orchestration design items to your BizTalk project. The process of starting a new BizTalk project in Visual Studio is simply to open a new project, just like you would in any classic Visual Studio project. And when you open that new project, you'll be asked for what kind of project you want to create. And you'll see BizTalk projects as one of the choices, after you've installed the BizTalk developer pieces. Then in that developer project you'll see Create a New Blank BizTalk Project, and you can simply choose that to start from a blank BizTalk project. Or there are a couple of other choices that I'll talk about in a little bit, that are also available there.

After you have that blank BizTalk project, you can then simply add new items to the project, such as an orchestration design, such as the one you're seeing here on your screen, or you could add a schema to describe a specific business document that's going to be flowing through your system using the BizTalk Editor. That's simply by adding a new schema file. Or maybe a map to define how you would map messages from one type of document format to another, and that's simply by adding a BizTalk map. You also have the ability to add pipeline components that I talked about earlier, either send or receive pipeline components. And this capability to quickly add various pieces or various files to your overall BizTalk project is a lot more intuitive for the Visual Studio developer.

With Visual Studio, and Orchestration Designer combined, you have a lot of really interesting capabilities in the product. You have the capability to use nested processes, like you had in the prior version of BizTalk, where you can actually have processes nested within other processes, and the ability to actually compose a very high-level transaction diagram or business process, and then build detailed versions of that process out in sub-diagrams. As well as there are nesting processes directly in the single design interface, using a scope shape, we call it. And these are defined out there on the left side, in the toolbar. You can drag these various shapes directly onto the design surface, and then this is defining, basically, in a graphical way, your business process that's going to take place.

Long-running transactions are also supported by the Orchestration Designer, so that you can support these several hour, day, week, or month-long processes that might take several cycles to complete, have several transactions with various partners on the back end, as well as have your own internal systems to complete. Those long-running transactions are supported by the product, as well as short-lived, atomic type of transactions, which are still supported.

Correlation has been made a lot easier for developers who used to have to do a little bit of programming or who had to do some extra configuration of the Microsoft Message Queuing system to allow for the correlation of messages. This is simply the ability to, when you're completing a long-running process, be able to take that information and understand when a message returns later to that business process — that message was meant for this process and not another process. An example might be if you were going to the cleaners and you dropped off your laundry, you would give them your first and last name so that when you return you would again provide that same information, and they would make sure to give you your appropriate shirts and pants so that you didn't pick up someone else's laundry. The same is true for a business process that's taking many, many steps to finish doing its processing. It might need to send a message off to a partner and then wait for that message to come back several months, days, or hours later. And when that message does return, it uses some token or set of tokens as a key to then understand which process was processing the message beforehand, and then pick it up and continue.

You also have the ability in Orchestration Designer to directly map your messages right in the orchestration process, whereas before you had to map those separately in the messaging engine of BizTalk 2002. You can now map messages directly, using the transformation shape right within the Orchestration Designer, which is a nice capability.

Correlation is simplified through the use of correlation sets, where you define, as I mentioned, one to many keys for that message that define it as a unique message flowing through the system.

The Web service capability that's now native to the system is excellent. So you can actually add a Web reference if you need to call an external system. Or you can expose your whole orchestration process as a Web service to external systems that need to be able to call in and submit a document or a message to your business process for decision making, and then back-end system processing.

And then finally, a new standard has been defined and has even been upgraded to a new version, called the BPEL for Web Services Standard (BPEL4WS), which stands for Business Process Execution Language for Web Services. It was released last year in version 1.0, and then about five months ago in May it was released as a version 1.1 standard, to describe business processes and an overall execution framework and language for defining how a business process takes place. What are the actions and the steps that need to take place? What are the interactions that various partners or systems need to make with one another? This Business Process Execution Language is not just a Microsoft standard, but it is actually a collaborative effort between Microsoft, IBM, and BEA. And then with the 1.1 framework we also added expertise from SAP and Siebel, in the process of putting the standard together.

So, a number of players have worked to create this common BPEL standard that our Orchestration Designer can conform to. And it can either export BPEL-compliant documents or import specific sets of BPEL-compliant documents, or specific pieces of a BPEL-compliant document. It is a superset of BPEL, in that it won't support every single piece of the BPEL standard, but it will support most of the BPEL standard components, and it can also then allow for additional customization of that BPEL capability and that BPEL execution to custom formats that aren't BPEL compliant. Because BPEL was really designed for Web service interaction. If you need to interact with a classic COM component or a back-end host system, BizTalk 2004 allows you to do that even if BPEL may not be able to describe that specifically in its schema language.

On our next slide then, the ability to call the Web service or expose your orchestration as a Web service is made very easy through a couple of mechanisms in the product. You'll see here on this slide, number 13, that to simply call a Web service or an external Web service on the right side, you just have to add that to your Visual Studio project or your BizTalk project as you would in any project, via Add Web Reference. The Add Web Reference capability is a really great feature that Visual Studio .NET added in 2002. And now you can take advantage of that very quickly in Orchestration Designer. Simply by adding a Web reference to your BizTalk project, you are able to immediately add a reference to a WSDL file and a specific URL out there for a Web service. The various schemas for the documents and the messages you will be sending and receiving from that Web service are then brought into your BizTalk project as custom messages that you can then conform your message to, before sending it out. Or once receiving a response back from that Web service, you can then take that message and manipulate it or query it to define and pull information out that you need, as part of your overall running process.

The other capability then is to integrate many different Web services together and use the orchestration engine and the business logic in your orchestration as an overall Web service process to the outside world, or to an outside service. This simply involves using the BizTalk Web Services Publishing Wizard. And this Publishing Wizard is a step-by-step wizard that you'll just walk through and define which orchestration you wish to publish, and which port or which outbound and inbound mechanism you wish to support. And it will then build the appropriate ASP.NET Web service project for you, and publish that out there as a virtual directory in Internet Information Services (IIS), that you can then take advantage of.

The nice thing with this is you can go into that ASP.NET .asmx file or that Web service file and manipulate it and change it as necessary, if you want to add on additional capabilities, such as WS-Security or other types of Web service mechanisms, before calling in your orchestration. You can customize those and create Web service project.

On to the next slide (slide 14), I want to quickly review a concept of a new architecture framework that we're putting forward here at Microsoft as a standard way of thinking about how to architect systems in general. It's called the service-oriented architecture, because we feel that Web services, thinking of services in general, and tying the services together is core to what a lot of companies are doing when they're integrating systems or building new systems. They're typically building some custom code, but in many cases they also simply want to stitch together or integrate a number of existing systems that are already in place at the company, or between enterprises. And these various services are exposed in many different ways. They've been implemented on many different platforms, in many different languages. And we find that a lot of developers spend most of their time simply trying to stitch these services together and figure out how to come up with a couple of common transport mechanisms and a couple of common formats in which these services can share information. Because each system tends to be built with its own requirements, and therefore it doesn't often have common interfaces that all of the other systems can directly plug into.

So our hope is that over time Web services will become that glue or that common message and transport format that various systems will use to integrate with one another. And by using Web services as the interface mechanism, you'll be able to more quickly integrate new systems and build new processes using tools like BizTalk Server, as well as tools by other manufacturers, because Web Services and SOAP and WSDL, the Web Services Description Language, are all standards that have been implemented and sent to W3C for inclusion.

So the service-oriented architecture is one that we put forward as a way of allowing you to build systems that are Web service exposable, but that are also capable of making Web service calls as necessary, to get the information they need. And by doing this you'll have the ability to quickly get to the information you want.

So on the next slide (slide 15) I show an example of where you might already have an existing, very complex business process in place at your company. And this process may include calling multiple back-end systems, having various business layer or business logic capabilities, various data layer capabilities, and various back-end data systems that drive this process. But in the end that business process has some type of input and some type of output. By putting some type of a façade or service façade on this overall business process, that is Web service-based, it's very easy to plug this service process into other processes or process services that you define in the system. And you'll find that over time, as you implement more of your systems in this way, where you have basically a black box where the actual business logic takes place and you put a Web service interface on it, it's easier to plug these various services together into larger, more complex processes, or set the processes and even put a black box around that larger process. So it simply allows you to have some abstraction around a complex process, so that you can interface with it very easily using Web services.

On the next slide (slide 16) I talk about the development experience, specifically the Solution Explorer that a lot of you have already become familiar with in Visual Studio and Visual Studio .NET. The ability to take and add more than one project to an existing solution is very powerful, because you can have, in a classic Visual Studio scenario, possibly some C# assembly libraries that are accessed by a Visual Basic® .NET Windows® application. Well, the same is true with BizTalk Server projects. Now that they're .NET-compliant projects that run as Microsoft Intermediate Language (MSIL) code, these projects can actually reside within a solution that contains other .NET projects, such as a class library. Or, in this case, in this screen shot, we have a MyMathService Web service that's been added as part of the solution. And this Web service is actually consumed by the BizTalk Server project, and is called by the BizTalk Server project. And we can see that in fact there's a Web reference that we've added to the project. Then that Web reference specifically points to that math service, and specifically a class called Service1.

This is what makes BizTalk much more powerful than the previous versions of the product, as far as Web service integration, in that you can add a Web service very quickly, with no code, by simply adding a Web reference. Also, if that Web service is one that you yourself host and that you need to change, you can add that Web service as well, directly to your project. You can also add other .NET class libraries that might be used by BizTalk directly to your solution, in one common window.

After you have your BizTalk Server project created, it might contain some orchestration design such as the BizTalk Orchestration1.odx file that you can see here in the screen shot. It might have some schema files, like the InDoc.xsd and the OutDoc.xsd schema files. And the schema files are now .xsd based, or XML Schema Definition Language based, which is nice that we're using that new, common standard for schema definition. And possibly, some mapping is involved to map the inbound document to an outbound document format, using the InToOutMap.btm, a BizTalk map file.

All of those individual pieces that make up our BizTalk project are then within this single BizTalk Server Project1 solution. And inside the BizTalk Server project, you can define a number of properties simply by right-clicking a project and going into the Properties window. Your standard Visual Studio Properties window will come up for that project, and you can set things like the version of the project. And you can define a strong name for that assembly, so that it can be deployed to the Global Assembly Cache, which is a requirement for BizTalk 2004 projects. They do have to be strongly named for deployment to the Global Assembly Cache.

Also, source control is now a real great advantage, in that these BizTalk Server project files are all hosted under Visual Studio, so it's very easy to add that BizTalk Server project to Source Control using Visual Source Safe or possibly other source control programs that you may have in your environment.

You can, as I mentioned, add Web references, but you can also add references to classic .NET and COM+ components. Simply by adding a reference — instead of a Web reference, just right-click References and choose Add Reference — you're able to add a reference to any other .NET .dll on the system or any COM+ .dll that's on the system that you need to be able to interact with. Or it may be even a remote DCOM system, a .dll that you've registered locally. You can simply add those, just like you would add them to any .NET project. And then you're able to use those public methods within your BizTalk project.

After you've added all of the appropriate Visual Studio solutions, and even other BizTalk projects that you've compiled into .dll files, those projects can also be added as references to your BizTalk Server projects. And a case where this might be used is you've built one BizTalk project that contains just your schemas and your maps, and it's sort of a repository for all of the common business documents that you're going to manipulate in your system, and the common maps that are being used. Those don't change all that often, and they need to be versioned, so you keep those off in a separate .dll as a BizTalk Server project.

And then that .dll that represents all of your schemas and your maps can be added as a reference to your existing BizTalk Server project, where you then might implement a specific orchestration, business process, or do some other mapping or custom mapping, and you can simply add that as a reference. So this is definitely additional power to be able to add components of one BizTalk project to another project, or .NET project .dll files to your BizTalk project.

After you're done with all of that design work and development, you simply compile your BizTalk project like you would any other Visual Studio project: right-click and choose Compile. After you've built the project, you'll have a single .dll that results from that BizTalk Server project. And that's the main piece of the project. Instead of having a bunch of different files that have to be deployed, you simply have to deploy that one .dll. And to deploy that .dll to the server, you simply right-click the BizTalk project again and choose Deploy, and that will, as necessary, register the .dll in the GAC, the Global Assembly Cache, and also register it with the appropriate BizTalk Management Database, which is storing the information about that BizTalk project and all its configured components.

In the configuration management space, after you have deployed this project, you have the ability to configure some additional information about how it's going to receive documents, or how it's going to send documents, or the people it's going to talk to. Or you may want to stop or start processing. In the past you had to go off to a separate management interface to do that. We assumed that typically the IT department or the operations department was going to do more of the configuration management work. But obviously during testing, as a developer and even as a staging or a test person, you might want to be able to do some of this configuration management directly within Visual Studio. So a whole new BizTalk Explorer interface (slide 17) has been defined, and it's very similar to the Server Explorer interface that Visual Studio .NET added, which was a very handy way to quickly get to the most common resources that a Visual Studio developer gets to: SQL databases, the application event logs, and things like that.

Well, now you have this powerful BizTalk Explorer interface right there in Visual Studio that allows you to quickly connect to one of your BizTalk management databases that might just be the one on your local developer machine, and you can see all of those assemblies that you just deployed from the Solution Explorer window on the previous slide. After you've deployed those assemblies and registered those with the BizTalk management database, they'll show up here in BizTalk Explorer. The ones that you see here under Assemblies are things like the HelloWorld project that I deployed and some other common .dll projects, some Human Workflow Service projects that are deployed by default.

Those assemblies can be undeployed directly from this interface. You can just right-click and undeploy those assemblies. All of the orchestrations that those assemblies may contain are also exposed here, under Orchestrations. And so that HelloWorld project that we deployed also has a HelloWorld orchestration contained in it. So we're able to see, for that specific orchestration, what some of the roles are and any invoked orchestrations that are currently running.

Last, you have things like roles and parties that you can set up to define how you communicate with external systems and group together related types of customers or systems, in Roles and Parties. And finally, there's the Send Port groups that I talked about, with Send Ports earlier, where you're able to define a specific port, which is an end point where you're going to be sending information. It will be a URI for a specific file location, or an HTTP address or Web service SOAP address, or MQSeries message queue that you need to send to. And those send ports can be configured here so that you can change, possibly, the name of the URL if you're moving from test to stage, or stage to production. The ability to be able to change that port interface here in this interface, directly from Visual Studio, is very powerful.

And as you can see, in the Receive Ports you can configure how you receive information. And you can see here we have a ReceivePort1 that can have one or many receive locations; in this case I just have one receive location defined. But as I mentioned earlier, you could have two, three, or four locations defined.

The receive locations allow you to define a single receive port that then can take the information from those many receive locations and possibly provide some common mapping to that information, before taking that information and passing it on to BizTalk for further processing.

So in this interface, you can see that there's a lot of capability for the developer, directly from Visual Studio, that wasn't available before: the ability to configure these ports, to be able to start and stop the ports. The binding operations is where you define how these ports will be hooked into specific hosts or Windows NT® services running on that box, or multiple boxes. You can start and stop orchestrations. You can define roles and parties. All of the information that most developers need is contained right here for deployment and configuration.

So that's the Visual Studio environment, and all of the really great features for developers.

Now we're going to move onto the next slide and talk about some of the new components that have been added to the product that allow for a lot of additional capabilities and new scenarios in which BizTalk can be used. On slide 18, we have the Business Rule Composer. And here is where you define your business policy about things in your system that might change or that require a specific rule that might adjust with time or other criteria. In the past, when you developed orchestrations and other system components in BizTalk, you either had to put that information out in a separate engine or a separate environment that you would change, or you would hard code that into your orchestrations or into your messaging environment. And suppose that information had to change over time, like you had a rule around purchase order processing, where if a purchase order request was under $1,000, you would just let that purchase order request go through for processing. Whereas if it was over $1,000, there might need to be additional manager approvals given before that purchase order request would go through.

That $1,000 limit often was hard-coded directly into the orchestration or directly into messaging, or even into one of your own components. And so if you needed to change that amount to, say, $2,000, if the business policy changed, that often involved the developer going back, finding that constant or that coded value, changing it, recompiling the appropriate orchestration or the appropriate assembly, or COM component, or going into the appropriate system and changing that information and then re-deploying that. And it would take time for all of this to happen. So a business user who wanted to quickly change rules around purchase order request processing, or maybe discounts given on products, who wanted that to happen in a few seconds or a few minutes, versus a few days or weeks for a developer, would find that that was sort of a hindrance.

Well, with the business rules engine you have the ability, in this separate environment, where you have a management interface and also a back-end SQL database running it, to define rules (such as this $1,000 hard-coded limit). But those rules that you define are versioned. And you can have your BizTalk projects communicating with the rules engine through the rules shape. Orchestration Designer specifically provides a rules shape that will allow you to call rules and determine values and the results of those rules to continue processing.

Then if that value changes from $1,000 to $2,000, you simply have to come into this interface, change that value, and create a new version of the rule. So that the value of $2,000 is now applied to this new version of the rule. And all future running orchestrations and processes will pick up that new version. The nice thing here is if you have existing processes that are already executing, they'll continue executing using the existing rule, so that you don't have any strange change in behavior in the middle of a long-running process. Whereas new instances that run can start using the new instance of the rule or the new version of the rule.

This rules engine is a powerful component that's part of the BizTalk Server suite, but it's also an engine that's available for use by independent software vendors or customers who just want to use the rules engine. It's very powerful. It's very fast, and there are scenarios where you might even consider using it outside of BizTalk. And so it is possible, through the API that is published, to call into the rules engine directly, via COM or .NET, to be able to use the power of the rules engine in your own products and solutions. But the integration with BizTalk is also very seamless, if you want to use BizTalk along with the rules engine.

As you can see on the next slide (slide 19), here are some additional scenarios you might think about with the rules engine. As we've talked about already, your business process diagram that you might have in a BizTalk project is a great way to use the rules engine. But you may also have a message bus where you have to do intelligent routing of messages. Say, in this example, if the customer wants to buy cars, then you route to a car dealer. If the customer wants to buy books, you route them to a bookstore, if you're a very generic sort of portal service.

For human-based workflow, you may need to determine how you're going to route messages for humans to make decisions about what to do. Say, if a purchase amount is over $1,000, then a manager's approval might be required; versus less than $1,000, then do something else.

And then finally, there's the business activity in general, being able to look at the overall volumes of business and the kinds of information that you're tracking, such as the purchase volumes coming in for a given customer might be over 100, and in that case that customer deserves some kind of premier procurement process. And so you might do a different type of processing or some kind of expedited processing for that type of order. So you can have things like your OLAP cubes being sort of a query store that your rules engine can even go against to make its decisions. So the rules engine itself doesn't have to simply be an "IF A=5" type of rule, but it can also go off and query back-end systems — COM, .NET components, OLAP cubes, or SQL databases — to be able to calculate and compute this rule.

Then on to our next slide (slide 20). I want to talk about another great feature, and that is the Enterprise Single Sign-On capability of the product. And this is where we've seen a lot of developers who are integrating these back-end systems or having to communicate with partners. Often in that communication there is a requirement for storing ID and password information, or credentials, for a back-end system or a partner site that you need to communicate with. Typically that responsibility of how to securely store that log-in information was laid on the shoulders of the developer. And with the developer being required to create this infrastructure, they may or may not have had the time to write it securely or have had the knowledge of how to write a secure framework in a system for storing password and ID credentials.

So what we wanted to do with BizTalk Server 2004 is provide this Enterprise Single Sign-On solution that you can take advantage of, so that you don't have to worry about how to store this information. We store it securely, encrypted in a SQL data store, and use a service to access that information. This part of the system has especially gone through many, many security reviews within Microsoft to help make sure that it is a more secure solution. There are a number of stop gaps and a number of capabilities in the product to keep that information secure, so that only those people who meant to access this information and use those IDs and passwords are allowed to use it, such as your BizTalk system, and not other processes or other people.

The impact then, of course, is that you're going to be able to quickly integrate with existing systems and quickly store those credentials, and not have to worry so much about where to maintain them or how to keep those credentials in sync. With some of these back-end systems, it's not easy to synchronize those, especially passwords that change frequently on some systems but not so frequently on other systems. It's easy to go in and change those within this one location, versus having to go into a bunch of custom .ini files, registry areas, or COM components where developers may have chosen to store these secrets in various ways, which could take a lot more time and effort.

In the next slide, 21, I describe a Single Sign-On example, where you're going in as a user on a Web client. Perhaps your goal is to just get your 401(k) balance, which is stored in a mainframe, but you're on a Web browser. And so, perhaps part of your process for requesting your 401(k) balance involves, through IIS, making a request where, behind the scenes, that ASP or ASP.NET page might be going to BizTalk Server to carry out that request.

And BizTalk Server has an HTTP receive transport, so it supports taking in an HTTP message. And using the Single Sign-On service, it can request a ticket that's been issued. And that ticket can be used as the validity check for that specific user, within their domain and their user name, or if they've provided credentials for some other mechanism, to specifically tell this BizTalk Server that this is the person who is requesting this information. And then through the BizTalk Server message box, that message is passed on to the appropriate adapter to receive that information. In this case, because it's a mainframe, the use of the COM TI adapter may be part of the Host Integration Server or SNA Server capability to be able to get this information. You can make a COM TI-based call to an SNA or a mainframe server. And that call then requires some type of specific credential.

Now, the user who logged in doesn't know the ID and password to the mainframe. That's possibly some custom ID and password that everyone who needs that information would use. But that's obviously sensitive information. So that's stored in the SSO credential database. And the SSO service then can use the original ticket that was submitted, and can validate, "Hey, this individual is a valid user. They are allowed to get their 401(k) balance for their specific account, so I'm going to redeem the appropriate ticket for that mainframe that will allow for that user just to get the information for their 401(k) balance, and get that information efficiently out of the mainframe, passed back through the message box and then back to the user as an HTTP response." So that way they get their 401(k) balance securely without ever having to know how the system communicated with the back-end mainframe or what that ID and password was.

On to the next interesting feature in BizTalk Server, which is on the next slide (slide 22). The business users, who want to get to this information that BizTalk Server is maintaining, they want to be able to quickly see information in tools that they're very familiar with, things like Excel, Word, Office products in general, like Outlook®, or a Web site. They want to be able to quickly monitor the information that BizTalk Server is tracking. And because BizTalk Server can be at the core or the heart of a solution, where you're routing purchase orders or manufacturing inventory records or medical information, manufacturing information — any type of information where BizTalk Server is processing that message — is tracking those details in a document tracking and activity database. That database then becomes a powerful message store for being able to determine behaviors of your partners and your customers, and then making decisions based on that information. But those decisions are made by end-business users who typically aren't going to be familiar with using SQL Query Analyzer or some other deep developer tool to go in and find that information. They want to use straightforward interfaces, like Excel, Word, and their browser to be able to look at this information.

So you, as a developer, have the ability to quickly expose information in BizTalk Server and messages that have flowed through the system to those end users. They might be able to look up things like real-time information about data that's flowing through the system as they go into the system, things like how long is production taking right now, as far as producing some type of material or some type of product. Or look at all of the different types of data that have flown through the system, and look at maybe how much money was made last month, based on all of the messages for purchase orders made by your various partners. And this data is stored by BizTalk Servers simply by the fact that it's the message routing mechanism. And so it becomes a very powerful store to be able to answer these questions.

And as you can see here, here's an example of an Excel spreadsheet that can be driven by either data in a SQL, a left cube, or even in just a raw SQL database for real-time information, that that user can then pull various dimensions or various fields out and quickly determine maybe, for a given set of customers, what was the volume of orders each of those customers had, or other types of information like that. And they'll be able to slice and dice the data in a number of ways using very intuitive tools that they're already familiar with, from previous experience.

On the next slide then (slide 23), an example here is where your individual developer might go in initially and define the overall business activity that's going to be monitored. And your business analyst, of course, is involved in that process of defining how the business activity is going to work. And then the developer turns that into real business logic. But those business analysts also understand what kind of data is in this information. What's the field, the specific properties in this message or purchase order as it flows through the system? I want to make sure I possibly track the purchase order total, the customer that sent the purchase order, and things like that. I want to make sure that I call that information out. And the developer can then make sure that they quantify and define those specific properties as critical when they define the business process. That way when the information about that message to metadata is stored in document tracking, and in the message box it's very easy for the Business Activity services service running on the system to be able to pull that information and aggregate it, possibly, in an OLAP cube store, where you can then query that information through intuitive interfaces, like in Excel or a Web site, possibly a SharePoint-powered Web site, using the SharePoint™ services. And so the Business Activity services is our service for allowing you to quickly query this information. And Business Activity services can also be accessed as a Web service itself, so that you can provide that information very quickly and easily, and aggregate that into other systems.

On to the next slide (slide 24), business activity monitoring and the wizard itself. This allows you to define what some of those key views are, or those key data elements that I want to be able to display. And using this wizard you are able to then define those fields, and it allows for you to create this Excel view that you can then easily customize. And you can have an end user run this Excel sheet to pull up numbers any time they like, real-time numbers that they can then access to see how information is flowing through the system, and what the current totals are for the data that they care about. This integration with Office tools or with Windows, Internet Explorer, or a Web browser in general is very powerful. This allows for that information worker to get to the information they need quickly and easily, versus having to install any kind of custom interfaces to custom, back-end ERP systems.

On the next slide (slide 25) we talk about another great future, the Human Workflow Services piece of BizTalk Server 2004, yet another new feature in the BizTalk product that allows you to integrate humans into the overall business process. We understand in general that there are times where the business needs to make decisions not based just electronically on the information stored in the document or in back-end systems, but that a human being has to be involved in making certain decisions that are more complex in nature. So Human Workflow Services is provided as a framework around which you can implement a human workflow process. This is really is a framework at this point. This is the first release of the Human Workflow Services feature in the product. So you have the ability, through the API, to be able to compose or put together what are called tasks, actions, and processes into an overall human workflow process. And then you can activate or call into Human Workflow Services via Web services. And you can also design these through the Orchestration Designer, which is sort of the core of the overall process, and where the human being fits into the process.

On the next slide (slide 26) I show an example of some of these major pieces of the product, of the Human Workflow Services piece, where you have task, action, and activity model. You have individual tasks, which are communicating with an actor, an individual that's going to act on that task. These actions then are put together and are composable at run time. And the actions then conform to an overall activity model workflow service feature, and the overall composition of those actions. And there's an overall API for this human workflow services interface that you can use to build human workflow-based solutions.

On to our next slide (slide 27), I'll talk a little bit about integrating with a number of trading partners, especially if you have a large number of trading partners, if you're like Wal-Mart or Ford or a company that works with a lot of other partners electronically, and you need to be able to integrate quickly and easily with them. BizTalk has been designed to help this large-scale trading partner management be easier, through a concept of parties and party types. And you'll see a number of other features in the product that allow for quick integration. So if you were the hub or the main company, or a large company that wanted to talk to many of your trading partners, you would want to be able to quickly add those parties to your environment, and be able to change properties about those parties, possibly the Web sites, or the e-mail addresses or other information about those parties you communicate with.

So the capability here is to have thousands of trading partners that you can easily query, interact with, and manipulate in individual ways, or as a group or a whole. And this allows you to quickly configure interactions with new trading partners, so that you can quickly bring new trading partners online electronically and start communicating with them. But you also conform to the unique needs of each trading partner. So that if one partner can only accept e-mails, whereas another one can accept Web service calls, you're able to define the various data formats and the various protocols by which you communicate with these different parties.

The individual partners themselves then may want to integrate with you electronically as well. And so we also, of course, have BizTalk Server as a solution for them as well, so that you can have a partner who wants to work with you electronically also using BizTalk. And they can use the SEED tool (slide 28) (Super Efficient and Effective Deployment tool is what that stands for) to take information about how you communicate and how you interact with other partners. And they can also apply those same standards and schemas to their environments so that they can quickly set up an electronic agreement, an electronic interaction of data with you. And this uses things such as the Windows SharePoint services. Web services can be leveraged, as other servers can as well. And trading partners can simply receive a package from the hub partner and then convert that into an imported project that they then bring into their system to quickly configure communication.

Now switching gears, let's go on to the operations side for the operations and infrastructure folks, as well as for developers who have tried to debug this project in the past. You'll find that the Health and Activity Tracking Tool (slide 29) that is new with BizTalk Server 2004 is a whole new interface for allowing you to quickly view business processes that are either actively running or that have run in the past. You can see step-by-step, through a nice, graphical interface, how that process has been executing and how it completed, or how it might have failed. This is a definite improvement over the past, where it was more of a text interface and you had to just kind of look at the graphical design as a separate window and then correlate the two. You can now see, side-by-side, the individual steps in a business process, what the message is, and what the variables are and such, as that business process completes.

This allows you also to track messages, see where they ended up, and see how many processes are running and what those processes are doing. Also, for the developer who is trying to understand why a process might be failing, they have the ability to go back and look at processes that failed to see what happened. Or on their own machines, or even on a separate machine, they can attach in a way that they can debug an actual business process and set a break point in this Health and Activity Tracking Tool, allow the process to run to that break point, and then query information about what the message is, and what the variables look like. And then they can continue processing, resume the processing, and possibly put a break point in somewhere else. So this allows for a much more robust debugging and tracking experience than was previously provided. And the important thing to note here is this HAT tool is a separate tool that you launch from the Start menu. You cannot debug a BizTalk process or an orchestration process directly from Visual Studio. You do have to use the separate HAT tool to do that.

BizTalk Server Administration, on the next slide (slide 30), is, of course, a Microsoft Management Console snap-in that allows you, if you're in IT operations or you're even a developer on your own box, to see the individual processes, to see the individual message boxes on your system, and to configure those message boxes. If you're in a large-scale environment, a server farm environment that might have many different servers doing different processing, you have the ability to start and stop different servers and overall hosts that are hosting those processes.

In BizTalk Server 2004, there is the concept of a generically named host may be comprised of one to many servers that are actually doing processing. So each of these hosts may be made up of one to many servers allowing you to scale out processing of a given process across many servers very easily.

You can, of course, also scale the database out through multiple message boxes. You could have a single message box initially, until you reach the certain point where you realize that possibly scaling out, having multiple SQL Server database instances, each with their own message box that also can be supported by one to many message boxes. And this also allows you to define security boundaries around different host processes. So possibly the host process that's going to be receiving documents might run with different capabilities and different permissions than the host process that does the actual business processing, that's accessing your back-end data systems where sensitivity is pretty critical, as well as maybe even a different host process that sends those messages off to the intended destination sites, intended partners, or intended partners or back-end systems. Those can also be separate hosts. And each of these hosts then ends up being a separate NT service that runs on those various servers. A given server can have many NT services that represent different BizTalk processes or BizTalk hosts that are running, or you could just have everything hosted in the single BizTalk host, if you want to keep things simple during development.

On the next slide (slide 31) I show the scale out capability, where you can scale out to multiple servers. As I mentioned, a given BizTalk host can contain one to many BizTalk servers, and as long as BizTalk is installed on each of those systems, the server components, you're able to simply add additional servers to that host, and then those various hosts will start taking part in processing the messages simply by the fact that you have a message box as a common store. And the various hosts will pick messages out of the message back as they have processing time and capability. This allows for a very natural "scale-out" model for adding additional computers, as the load requires, or removing computers if the load drops off, if you have some type of seasonal load on your system.

Network load balancing, of course, can also be used for routing messages to these individual computers if they're going to be end-point IIS servers that are picking up HTTP requests and need to post those to a message box. You can network load balance those or use Windows Load Balancing Services across those servers, and then they can all post to the message box.

A scale out of the storage (slide 32), instead of processing, is that ability I mentioned earlier with message boxes, where you don't necessarily have to have one single message box, but you can have one to many message boxes. And those various host computers can then post to the appropriate message box that they're designed to work against. And the key here is just to define a single master message box, and then all of the other message boxes are sort of slave or secondary message boxes to the master.

On the next slide (slide 33), I'll talk a little bit about performance here. Obviously, performance depends on the capabilities of the server hardware, as well as the way that the software itself has been configured and implemented. If you have a very complex orchestration that accesses many back-end systems that may take various amounts of time to return data, you're going to see different amounts of speed in general. But what we find with BizTalk Server 2004 is that it significantly improves all of the performance over BizTalk Server 2000 and 2002. It truly is enterprise-class performance and gives you very fast and scalable orchestrations, which was somewhat of a concern in the past.

The orchestration process is now compiled as MSIL, Microsoft Intermediate Language code. It's run as managed code in the run-time environment. And so being JIT-compiled code, it actually runs very efficiently. Typically we're seeing, in our scenarios — although we can't guarantee it, because it depends on your scenario — at least 5× performance improvements over BizTalk 2002 orchestration, but even significantly more than that in many cases. So performance has definitely improved in orchestration. The 4-MB limitation on the message sizes in the past, which was imposed by Microsoft Message Queuing, that's not limited to basically what your SQL database can store, your message box database. That 4-MB limit has gone away, so large message processing is much improved. The message box in general is not replicating large messages like the old shared queue might have replicated, between itself and Microsoft Message Queuing. You now have all of the information stored as a large message in a single blob in the message box database. So you'll find that large message supporters is also much more efficient and faster.

The rules engine itself is also very performant. It uses the optimized algorithm for smaller rule sets and fact bases. And for larger rule sets or fact bases there's a Microsoft algorithm that it implements. But in general, just a rules engine by itself, throughput is around 75,000+ rules per second. For complex, line-of-business type policies, around 30,000+ rules per second. And the scalability in general, as far as how many rules and sets it can store: 50,000 rules or rule sets, 100,000 objects in working memory. So the engine itself was very scalable, so that if you want to use the rules engine, you're going to still get great performance in your solution. Or if you just want to use the rules engine standalone, it's going to be very performant as well.

On our next slide (slide 34), I wanted to go through sort of some main things about migrating BizTalk solutions, because a lot of you out there might be using BizTalk Server 2000 or 2002 today, and you're wondering how you can take advantage of some of these really cool futures in BizTalk 2004, and what's going to be required to move your solution to that version of BizTalk Server 2004. We do provide a BizTalk Migration Wizard. And it's simply a way of taking information, BizTalk messaging objects that have been configured in BizTalk Messaging Manager and BizTalk 2000 or 2002, and migrating those to 2004. Of course, in this case 2002 is the requirement, so it's important you start with BizTalk Server 2002 and migrate to 2004. So if you're already on BizTalk Server 2000, you would have to migrate your solution to 2002, and then from there migrate to 2004. Although there is very little difference between BizTalk Server 2000 and 2002. So that type of migration is pretty minimal, if any at all, other than installing the product and following the migration specifications in 2002.

The important thing to note here though is that it is non-destructive. It does not change your 2002 environment in any way. It simply reads the interchange, BTM, or BizTalk Messaging database, which is the default name for the messing management database in BizTalk 2000 or 2002. And that contains all of your messaging objects, like your channels, your ports, your doc definitions, your envelopes, your applications, and your trading partners or the organizations that you're communicating with.

So those can be migrated very easily, simply by opening a new Visual Studio .NET project, and as part of choosing the BizTalk project, one of the BizTalk projects you can pick from is a migration project. And when you pick that, it will then ask you to point to your existing 2002 database, and specifically the SQL Server name and the actual interchange BTM database, or the messaging database name, if it's not interchange BTM. You type that in, and it will ask you for specific information about the ports, like what port groups you want to migrate over, and it will then appropriately find all of the dependent channels, document definitions, envelopes, organizations, and applications, and migrate all of those over as appropriately formatted files.

So things that it will migrate are things like the maps. It will look at the maps and take those over. If there are any scripting components, like scripting functoids, those will not be migrated, because that might be VBScript or JScript®, and you'll have to manually migrate that VBScript or JScript yourself. It will be included in the scripting functoid that's provided in 2004, so you just have to go in and make that code .NET compliant. The nice thing there is that the functoids in 2004 can now also be hosted in classic COM components that you can call out to, or .NET components. So it's very easy to migrate those functoids. You can even use the new 2003 migration capability. If you wrote yours in VBScript, there's a little tool in Visual Studio 2003 that lets you take a chunk of VBScript code in VB 6.0 type format or VBScript format, paste that in, and then migrate that to a VB .NET format. And so you could take advantage of that for doing some of your migration.

The nice thing for your schemas is all of your XDR schemas that were in the required schema definition language, or XML schema definition language in 2002, are now converted to the new standard XML schema definition language. So all of your old XDR schemas will be migrated for you automatically. Send and receive pipelines will be brought in as necessary to handle any type of encoding or decoding, signing, or verifying of signatures, things like that, for your message. And then finally, any kinds of specific binding information, such as the file you're going to pick a document up from, or the HTTP address that you're going to send a document or a message to, will be stored off in an XML binding file. And so at deployment time you can simply go into that binding file and, if necessary, change the appropriate paths, if you're on a different server, to the appropriate file locations or URLs, or keep them the same if they don't change, and then run through the deployment wizard. That's one of the menu choices, to be able to bind and deploy your solution.

Some other points to note (slide 35), orchestrations that you might have built in BizTalk 2000 and 2002, there's work in progress on a Jumpstart Tool that is tentatively scheduled for post-RTM, but it will not be part of the migration wizard that you're using in the beta version today, or any pre-released versions, or even in the RTM version. It might be Web released. They're still tentatively working on that, but the thought is the orchestration capabilities in 2004 are significantly improved on in the new environment, and so with BizTalk 2004, really, the orchestration shapes will be migrated over, and how they're connected. But how you actually implement those shapes, you will have to re-implement yourself. So, in environments where you're doing a lot of messaging, the migration wizard is great. If you're in an environment where you're doing a lot of orchestration, the Jumpstart Tool might be an option to help get you going, but you'll still have to do the binding and implementing part yourself, even when the Jumpstart Tool comes along.

And for your application and integration components, for now there's the requirement to manually migrate those AICs to the new BizTalk framework through processors or custom encoding components. The product team is also working on shims that would allow you to integrate your classic AICs without having to make any code changes as necessary, using some of the standard interfaces that are provided by those, such as the IBTSAppIntegration interface or IPipelineComponent and IPipelineComponent/Admin interfaces. Those shims would allow you to use those AICs as send or receive adapters in the new BizTalk 2004 scenario. Also supported in those shims would be the IBTSCustomProcess and IInterchange interfaces.

Some shims though that won't be provided include the BTSConfig, because that's how you configure BizTalk. There's a whole new configuration API for the new version of BizTalk, so that's what you would write your code against. And IPipelineComponent for any custom encoding or IParser or ISerializer wouldn't be supported, because of the new ways you can parse and serialize using the pipeline components in the new version of the product.

There's a great white paper already available on our beta Web site (http://www.microsoft.com/downloads/details.aspx?familyid=229ad086-6bc6-49ba-ba06-d9ba08fa811e). It's one of the top 10 downloads from the BizTalk product page. And it's a really good resource for those of you who want to start taking the beta version of the product and migrating your BizTalk 2002 projects to see how those go.

I want to kind of finish up here on Visio and Office integration (slide 36). Visio has been pulled out of the product as a requirement to do BizTalk development, but there's still, obviously, the need for business analysts to be able to create a business process diagram, and then share that with a development team. And there is a need for that development team to import that diagram into their Visual Studio environment. We don't expect, obviously, for your typical business analyst to be Visual Studio savvy, or to want to install Visual Studio, but they will have Visio, probably. And so there will be the ability for the business analyst to construct a business process using a simple Visio template that they'll be able to download, then construct this business process, hand it over to the developer, and the developer can then import that and tie that, as appropriate, to the back-end systems, and add additional steps to the process as necessary. This would even be bi-directional, where they could then share that back with the business analysts over time, so the analysts can see what the new versions of the implemented processes look like. And they can work back and forth in a collaborative fashion.

On the next slide (slide 37) we talk about the Office/InfoPath integration, where you have the ability to integrate with this new tool in Office System 2003, called InfoPath. It's a new tool that's included along with Word, Excel, Outlook®, Access, and all of your other favorite Office tools. InfoPath is sort of a forms-based tool that allows you to quickly collect data from an end user and then route that as appropriate to back-end systems. Or simply collect that data and store it in an XML-based file that you can then process.

The nice thing about this InfoPath mechanism is that in many cases you're trying to figure out how to quickly get information that the user enters into the system. And instead of having that user just type it into an e-mail that you then have to parse, you can provide them a nice interface through InfoPath. And if they install Office System 2003, they'll get InfoPath as part of the solution. And with InfoPath they then can have a form-based mechanism to enter that data. This form can be directly derived by a developer from an XSD schema. So it's very quick and easy for the end developer to create one of these form documents. The form then is filled out by the end user as appropriate back-end systems are queried to receive the information that's needed for additional parts of the form. And then the final result of the document is passed on to a back-end system as a Web service call. So the power here is that InfoPath can make Web service calls for the end user. And by being able to make a Web service call, the InfoPath document can be passed on to BizTalk or to other back-end systems for additional processing.

So here's an example on the next slide, 38, where we might have an InfoPath document where a sales rep is going in, and they're getting some information via ADO from the company employee database, to get some daily minimum prices via a Web service. They then want to submit their sales calls and submit that report to BizTalk Server, where that BizTalk Server can then be used to do some of the automated processing, such as sending summary e-mails and possibly submitting an action to be taken by BizTalk, based on e-mails that are returned. And then as necessary, BizTalk can update a reports database and provide daily sales information to a database that the company uses. And as necessary, they can query the history for additional information about the historical data of that sale. So InfoPath is a nice kind of user interface. Obviously, a Web browser-type interface or other customer-specific interface could also be used, but InfoPath allows for a very nice lightweight interface that takes minimal development time to create.

So, to wrap up, I just want to summarize a few key points about the product and give you some additional resources (slide 39). What we've tried to do with BizTalk Server 2004, of course, is to allow you to get to the information you need and allow for systems to easily connect with one another. And we've designed various tools within the product to make life for the developer even easier, such as the Visual Studio .NET integration, which makes for, I think, a very powerful interface and a quick design environment for your developers; for IT professionals using Windows and SQL Server and having standard repeatable processes through some of the wizards and the administration interfaces we provide; and for information workers we're providing rich Office views of the information that they want to access, through things like Visio or InfoPath, or a Web interface or Excel or Word, for charting and viewing information. We're trying to take advantage of all of the standards in the product, all of the standards that are becoming more powerful and more common in the Web services world, such as the XSD schema being the standard now, versus the XDR schema. XML, of course, is at the core of every part of the system. And also, we champion the emerging standards around Web service interoperability and XML Web services in general by having those built into the product at the core.

And then finally, we even help foster whole new frontiers of business development through a partnership with the industry to develop this Business Process Execution Language for Web Services standard, or BPEL standard, that will allow for businesses to quickly publish their own business processes, or at least the public part of their business processes, so that it's quick and easy for other industry partners to begin to interact with them electronically through standard business protocols that they've defined in an electronic way.

Here are some additional resources (slide 40) you'll want to check out to learn more about the product. Our beta Web site is right up on http://www.microsoft.com/BizTalk/Beta/. And when you go there you'll be able to download the beta version of the product where you can install the product on anything from a Windows XP to Windows 2000 or Windows Server™ 2003 box. Various components are required. If you want to use Windows Server 2003, you'll be able to install all of the pieces of the product. If you install on Windows XP or Windows 2000, there will just be a couple of capabilities of the product specific to Windows SharePoint Services that won't work. But in general you get most of the capabilities, even on a Windows 2000 or Windows XP box.

In the documentation that comes installed, you have a lot of great information. The document files that come with BizTalk have always been great, and this beta version of the document is very good. It will have a lot of additions that the product team is making, but you'll find a lot of great information around to learn about the product through some tutorials, how to plan, deploy, migrate, operate, design, and program the product through the documentation that's provided.

The SDK samples are in pretty good shape. They're adding even more samples as we speak, but the beta build does have a lot of great SDK samples about building your own custom adapters, administering the box, either through the administration interfaces or through the API interfaces, working with the rules engine, Human Workflow Services examples, messaging examples, orchestration examples, how to build your own custom pipelines if you need to, and single sign-on examples.

The BizTalk tutorial, of course, has a good EAI integration example, as well as a B2B integration example that you can run through to learn the product. There's also a Flash demo up on that site that you can check out for more information, at a high-level, on what the product does. It's like a 12-minute demo that you can run through.

The BizTalk Community is a great site to learn more about others who are doing BizTalk work out there. The BizTalk Server 2002 newsgroup is available here, and there is a BizTalk Server 2004 newsgroup. If you go to that BizTalk beta site under Microsoft.com, you'll see information about how to get to the newsgroup as well. You can post questions or see what kinds of questions people are asking and comments people are making about the product.

There's also a BizTalk User Group, BizTalkUG.com. This is not associated with Microsoft, but it's a good site. It has some good information as well. And then some other interesting sites are the topxml.com/b2b site and the gotdotnet.com site has a specific team, a Windows server site that's also pretty interesting.

I just wanted to also mention a resource for those doing development today and in the future, the Microsoft Windows Server System Online books, here on this next slide, where you can see real-world customer deployments and see integration stories, and you can learn what they've done in their environments to be able to use BizTalk Server as well as other products, such as Content Management Server, SQL Server, and Exchange Server. And right now there are documents and real-world stories and implementation details that are specific to various scenarios out there today for BizTalk 2002. And over time, as BizTalk Server 2004 is used, they'll be adding new scenarios and new stories out there on that. But for now you can get some good information about BizTalk, the current version of BizTalk, and the other e-business products out there on that site.

So, with that, I'd like to thank you for joining me on this call, and I hope you learned a lot about BizTalk Server. And I'm now available to answer any questions.

Otto Cate: Excellent. Thank you very much for the presentation, Erik.

Before we jump into the Q&A, I'd like to share a couple of quick program notes with our listeners real quick.

If any of the details on the PowerPoint® slides were difficult to view on your browser today, or if you'd like to simply have a copy of the slides, they'll be available for download within 24 hours of this live session, along with the on-demand streaming media content.

So we're going to jump into the Q&A here. We have a limited amount of time here, probably about 10 or 15 minutes that we'll be able to keep the message queue open, so I'm going to try to move through these as quickly as we can.

The first question here is regarding the message flow, back on slide 8: We're curious if this is the same message flow that 2002 had, or is it a little bit different in 2004?

Erik: Yes. It's definitely different, because of the fact that the message box can be thought of as sort of a combination of the old BizTalk 2000/2002 shared queue database and the XLANG database. We no longer have any sort of separation between orchestration processes and messaging processes, in that there's one common message box now that stores both. And so you're going to see that things are a little different, in that you have one common message box where the information flows, versus if you had an orchestration and a messaging solution in 2002.

You might have the data coming in through a receive function we would call it, sort of like a receive location. And then some preprocessing takes place, and then it goes straight to a shared queue database, off to, possibly, orchestration through a message queue or a Microsoft message queue, and then back to messaging. Again, through a message queue, then back into the shared queue database, and then on off to its intended destination through some kind of an AIC or adapter, I guess you would call it.

So just think of the message box as sort of a new version of the shared queue/XLANG database, but totally redesigned for much improved performance and a lot of additional monitoring capabilities. And the pipelines, of course, are a whole new concept where you can do a lot more than you could do before, and add a lot of additional components into the pipeline. Whereas before you were pretty limited to adding additional steps into the process.

I also would like to introduce my colleague, who is going to be assisting with the Q&A portion. His name is Rajan Dwivedi. He works with me, and he will also have occasional feedback on questions. So Rajan wanted to mention something here.

Rajan: Yes. On this question I would like to add a couple of things that are quite interesting, when compared to the BizTalk 2002 model. Like here in orchestration you can have logical force. There is no physical binding. And then later on you can have some binding, depending on your production environment. And as Erik said, in the 2002 model there was a channel, and channels were associated with the ports, so that kind of concept is no longer here. And this concept in the 2004 model is very extensible and much more flexible with adapters and pipeline stages than the Tivoli pub and sub architecture. So if your message goes in the message box because of the elected receive location, then orchestrations are kind of like subscriptions, and they're waiting for the messages. So this architecture is very, very different than the BizTalk 2002 model.

Otto: Great. Thank you very much.

The next question that we have here: How does BizTalk integrate with Microsoft clustering services for load balancing and high availability?

Erik: Actually, that's still being defined, but what we found is with the type of architecture we have now, there's not such a need or a requirement on clustering services. The main point where you would use clustering services would be in your SQL database or your data lair, where the message box itself is. Because it is sort of a highly available, durable storage mechanism for BizTalk, you'll want to make sure that that message box database, if you want high availability and reliability, is running on a SQL Server, that it is running using Microsoft clustering services. And, of course, some of the other databases as well. You could run in that same database environment or on a separate database server, and it's up to you as to whether or not you want to cluster those as well: such as the tracking database or the management database.

There are also a number of other databases for the various components, like Human Workflow, rules engine, single sign-on, and things like that. So that's the main place where clustering is required.

Now the only other place in the previous version of the product that you needed clustering was orchestration, typically, or Microsoft Message Queuing. Because that Microsoft message queue might be a single point of failure. Or in orchestration, in the old BizTalk 2000 and 2002 days, you had to go into those environments and make sure that if that orchestration server went down, another server was in its place with the exact same virtual name, so that it could continue processing messages.

Those requirements are gone from BizTalk 2004. There's no longer a requirement, so that if a given server that's processing an orchestration goes down, another server can pick it up with a different server name. And, of course, as I mentioned, Microsoft Message Queuing is gone, as far as a requirement for posting messages to BizTalk. It now uses the message box directly. And you can post messages to BizTalk through what's called BizTalk Message Queuing. And the API looks the same as Microsoft Message Queuing. But it's actually re-implemented by the BizTalk team, so that it supports large message sizes, streams those directly into the message box, and so you can still call in to BizTalk as though it were a Microsoft message queue. On the outside, it looks like a Microsoft message queue. The APIs look the same. But in reality, the back-end message store is a message box database.

Rajan: To summarize it quickly, basically you can install BizTalk Server 2004 against any established resources of the cluster. So the cluster could be MSMQ, it could be SQL Server. And also, like for scale out, you could always add the host, or you can spread out the message boxes as subject databases. So that is the model that we are going to follow.

Otto: Great. Regarding the integration with Visual Studio 2003, can we finally print out maps from the mapper and schemas from the editor?

Erik: You know, I haven't actually tried to do that myself. That is a very good question about the printing capabilities. I haven't thought about that. While we go on the other questions, I'll open Visual Studio in the background.

Rajan: You can print out the orchestration for sure. I'm not sure myself on mapping. And you could probably also make out a print out of the schema. But for mapper, I'm not really sure, so we have to check on that. [Editor's note: See the follow-up answer later in the transcript.]

Otto: I can mark that one for offline follow up, in the interest of time here.

The next question here: We've installed 2004 and have had various success in getting HAT to actually function. There are also many problems with installing and configuring BTS that are not covered by support, in the newsgroups and such.

There are a couple of users who are wondering if there's going to be another version of the beta coming out before we RTM?

Erik: That would be something we would also need to follow up on as well. My understanding is that the beta will be the only version provided before RTM, but at this point I couldn't answer that for sure. So we would need to follow up.

Follow-up answer: The beta version of BizTalk Server 2004 currently available for download from http://www.microsoft.com/BizTalk/Beta/ is the only version that will be made available to the public prior to release of the product, in the first half of 2004. Premier Support customers can contact their Microsoft business development manager or technical account manager to receive best effort technical support and inquire about possible nomination to the BizTalk Jumpstart Program for access to later versions, prior to product release.

Otto: Okay.

Rajan: I think I can add something on that. There are some versions that are released specifically for some partners who are participating in some programs for our product teams, like Jupiter1 or EAP, or some other programs. So they have some other builds, but for the public we have only what is available on the beta Web site.

Erik: Premier customers could query their business development managers on the Microsoft side, or their technical account managers, about things like the BizTalk Jumpstart Program that are meant for partners who might want to do early development prior to RTM, and who would like to get newer versions with some capabilities, depending on their scenarios and their timelines, to possibly get newer versions as a premier customer. So just have them talk to their business development manger about the BizTalk Jumpstart Program.

Otto: Great. Thanks.

Erik: I guess the scenario I imagine there is that someone is computing something like a purchase order above or below a certain amount, and perhaps that takes days or weeks to run. And if that rule has to be executed again later, is it going to use the new version of the rule or the old version? It will continue using the old version of the rule. So the key there is that the rules engine allows for multiple versions. So you might have a version 1.0 that has 10 instances of the schedule that are long-running, that you're currently using. And five of those are complete and five are still in the long-running state when a new version of the rule, 2.0, comes out. And so maybe five new instances get created at that point, and those five new instances start using that new rule; but the five existing instances should continue using the existing rule, and so that's why you want to leave that old version 1.0 rule around. You do have the ability to eventually delete that older version when you realize there are no instances that require it. But it will stay out there for use by those long-running instances.

Rajan: This is valid not only if you have orchestration, and now you are trying to build a new version of orchestration. So whatever it is, it is going to use the old artifacts. And whatever is new, they're going to use the new policies, new versions, and everything. So that rule is pretty much valid with everything in BizTalk 2004 Server.

Otto: Okay. Would the Business Rule Composer handle issues to ignore duplicates? For example, when using the accelerator for HIPAA, there is an ISA segment that can be a sequence number, ISA 13, for instance? A real-world example would be the state of Arizona sending unique files based on the ISA 13 segment, which is an incremented number, and we don't want to continue processing that 12 times, because we already know that it's a duplicate.

Rajan: [I think that I had one customer who had very similar questions. In such situations the first sequence is picked up if there are duplicates or the same kind of line items or group of elements within the schema. You can do looping or select all of them through an XPath expression to do the processing for each of them. By default, as far as I know at this point in time, it picks up the first one only.]

Otto: Okay. Is the Human Workflow Services piece available in that current version of the public beta?

Erik: I believe so. I haven't used the Beta 1 in the last month or two, but I'm pretty sure if you say, File, New Project, one of the project types will be a new Human Workflow Services project type.

Otto: Okay.

Erik: By the way, I did go back and test out the printing capabilities from the maps and schemas, and sadly, that is disabled in Visual Studio. Other than a classic screen shot, kind of a copy and paste, and then print from PowerPoint or something like that, you won't be able to print your schemas or your maps directly from the tool. But you can print out orchestration designs from the tool.

Otto: Okay. Thanks for the follow-up.

It looks like we have only a couple of minutes left here. I'm going to get through these last couple of questions here.

Rajan: [I think this should be tackled in the pipeline stage. Right now as it is, out of the box, I don't expect BizTalk to support 100 percent native schema repositories of SharePoint or InfoPath. There are some tricks involved. You can build a custom adapter that can tackle this type of XML data. Currently, out of the box, you can not tackle an InfoPath-generated metadata/schema natively in BizTalk server. A simple example is handling the processing instruction for InfoPath (you have to deal with it in the pipeline stage if BTS is generating the docs for InfoPath).]

Erik: It might also be possible to manipulate that information in the actual .asmx page itself, because the .asmx page is published by the Web Service Publishing Wizard. And before you call into BizTalk, if it's necessary to do any kind of decryption, you could do it at that level. But, of course, the adapter pipelines are a capable of doing that. And I imagine with InfoPath integration with BizTalk being a pretty common request, there will probably be some work done on some samples to help with that.

Otto: Does BizTalk 2004 support processing documents greater than 20 MB outside the box?

Erik: Yes. Yes, they've done tests with up to like 100 MB or higher document size. So again, it's just a limitation of the amount of RAM on the system and the size of the SQL database, because it's now storing it as blobs in SQL, and using streams in the individual components, the adapters and pipelines and the processing itself, to be able to manipulate those documents efficiently.

Otto: Does the 2004 tracking database come with a sample Web application, like 2002 did? And what enhancements or changes have been made to the data tracking?

Erik: The tracking definitely has changed pretty significantly. There is, via WMI, an API for being able to query the tracking information for determining changes that you would track previously. But document tracking activity has changed a fair amount. So in the beta you may not see a whole lot of samples or details, or some of that information about the various tables and such that make up the doc tracking. And you'll see some more with the actual release of the product. So if you're not seeing that stuff in the beta today, look for additional documentation in the help file and samples in the 2004 released product.

Otto: In general, where do the business analysts come in to create the high-level process definition, for instance, in Visio, that can be exported for use in a development environment?

Erik: Yes, the high-level analysts, unless they want to install Visual Studio 2003 and then install BizTalk, there isn't a direct capability in the installed product. We assume that the business analyst simply wants to go into Visio. So there will be a download that can be taken from the Microsoft Web site, the Visio site, or BizTalk site. By release time there will be a template that you can actually use and open in Visio so that the business analyst can mock up something using the templated shapes, then save that, and then pass that off to the developer, to then import and use. They just need Visio on their side.

Otto: Okay. And the final question that we have in the queue today: Could you briefly contrast Microsoft Operations Manager and BizTalk 2004's monitoring capabilities?

Erik: Actually, they would be complimentary, just like with 2002. We released in 2002 a Microsoft Operations Manager Management Pack, or MOM Management Pack, that allows you to easily watch the various attributes or the system attributes and warnings and things that BizTalk would send out, and then appropriately define rules and actions that would take place when those various activities occurred.

For BizTalk 2004, it's still the same sort of scenario, where BizTalk is exposing any errors or processing that it's doing through a variety of means that are very similar to what 2002 gave, but also some additional capabilities. They provide information especially through the application event log for errors, or if a server starts or stops or anything like that. So again, MOM can monitor the application event log. They provide information via WMI for document tracking and activity. Suspended documents and things like that can be monitored via WMI, which is also true for how you could monitor the previous BizTalk version — it was also through WMI. So it's really sort of similar.

You also have a number of logging capabilities around performance objects, using Performance Monitor. And so there are a number of BizTalk objects and performance counters that BizTalk 2004 exposes that also can be monitored by MOM for thresholds, like processors, the number of running BizTalk orchestration instances, or if those exceed a certain threshold, or other things like that. Those various performance counters can be monitored by MOM and then at various thresholds they can send alerts and things like that.

So something like a management pack that was provided with BizTalk 2002, the product team is looking at providing that for BizTalk 2004. Not by the release of the product, but fairly soon after they would like to provide some type of management pack for MOM that would be useful for BizTalk 2004 folks as well.

But they can still use the BizTalk product and MOM and configure those counters themselves if they like using the BizTalk 2002 Management Pack as a guideline for how to build your WMI queries. Although they'll differ slightly for BizTalk 2004, in how to watch the performance counters and how to watch the application event logs. And we'll have information in the help file about those different monitoring mechanisms and operations, techniques in general that will be provided with the product when it releases.

Otto: Great. Thank you very much.

Well, with that, we've answered all of the questions that were submitted to the queue today, so I'm going to wrap up our session. I wanted to thank Erik for coming out and giving us a great presentation here.

I wanted to thank our listeners as well for coming out and tuning in to this broadcast. We hope that all of this information was useful to you and your business.

I hope that everyone has the opportunity to tune in again soon. Thanks, and have a great day.