47,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
SOA is about architecture, not products and SOA enables you to create better business processes faster than ever. While BizTalk Server 2009 is a powerful tool, by itself it cannot deliver long-lasting, agile solutions unless we actively apply tried and tested service-oriented principles.
The current BizTalk Server books are all for the 2006 version and none of them specifically looks at how to map service-oriented principles and patterns to the BizTalk product. That's where this book fits in. In this book, we specifically investigate how to design and build service-oriented solutions using BizTalk Server 2009 as the host platform.
This book extends your existing BizTalk knowledge to apply service-oriented thinking to classic BizTalk scenarios. We look at how to build the most reusable, flexible, and loosely-coupled solutions possible in the BizTalk environment. Along the way, we dive deeply into BizTalk Server's integration with Windows Communication Foundation, and see how to take advantage of the latest updates to the Microsoft platform. Chock full of dozens of demonstrations, this book walks through design considerations, development options, and strategies for maintaining production solutions.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 418
Veröffentlichungsjahr: 2009
Ähnliche
Table of Contents
SOA Patterns with BizTalk Server 2009
Richard Seroter
SOA Patterns with BizTalk Server 2009
Implement SOA strategies for BizTalk Server solutions
Copyright © 2009 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: April 2009
Production Reference: 1200409
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-847195-00-5
www.packtpub.com
Cover Image by Vinayak Chittar (<[email protected]>)
Credits
Author
Richard Seroter
Reviewers
Charles Young
Ewan Fairweather
Zach Bonham
Acquisition Editor
James Lumsden
Development Editors
Nikhil Bangera
Siddharth Mangrole
Technical Editor
Gagandeep Singh
Indexer
Rekha Nair
Production Editorial Manager
Abhijeet Deobhakta
Editorial Team Leader
Akshara Aware
Project Team Leader
Lata Basantani
Project Coordinator
Neelkanth Mehta
Proofreader
Camille Guy
Production Coordinator
Shantanu Zagade
Cover Work
Shantanu Zagade
About the author
Richard Seroter is a solutions architect for an industry-leading biotechnology company, a Microsoft MVP for BizTalk Server, and a Microsoft Connected Systems Advisor. He has spent the majority of his career consulting with customers as they planned and implemented their enterprise software solutions. Richard worked first for two global IT consulting firms, which gave him exposure to a diverse range of industries, technologies, and business challenges. Richard then joined Microsoft as a SOA/BPM technology specialist where his sole objective was to educate and collaborate with customers as they considered, designed, and architected BizTalk solutions. One of those customers liked him enough to bring him onboard full time as an architect after they committed to using BizTalk Server as their enterprise service bus. Once the BizTalk environment was successfully established, Richard transitioned into a solutions architect role where he now helps identify enterprise best practices and applies good architectural principles to a wide set of IT initiatives.
Richard maintains a semi-popular blog of his exploits, pitfalls, and musings with BizTalk Server and enterprise architecture at http://seroter.wordpress.com.
First off, I need to thank my exceptional technical reviewers and editors for doing such a fine job. Charles Young, Zach Bonham, and Ewan Fairweather all made significant contributions in their role as technical reviewers and this book is of a higher caliber as a result of their insight and wisdom. Tim Wieman also took time to review the book content and his real-world perspective was a welcome addition. I have to thank James Lumsden, Neelkanth Mehta, Nikhil Bangera, Gagandeep Singh and the whole top notch team from Packt Publishing for doing such a seamless job shepherding this book from inception through delivery.
I'd have been much worse off in this endeavor without the assistance from Microsoft. Thanks to Richard Hughes and Emil Velinov for acting as facilitators to the Microsoft technical team and efficiently routing my questions to the appropriate individual. These capable Microsofties include Dmitri Ossipov, David Stucki, John Taylor, Sarathy Sakshi, and Rong Yu.
I'm thankful every day that I work with some of the brightest and most creative technologists that you'll ever come across. They have contributed greatly to my architectural maturity and helped me (unwittingly or not!) craft many of the patterns that you'll find in this book. These people include my peerless manager Nancy Lehrer and colleagues Fred Stann, Ian Sutcliffe, Chris Allen, Simon Chatwin, Jaydev Thakkar, Elizabeth Waldorf, Felix Rabinovich, Aki Hayashi, and Victor Fehlberg.
Finally, I had wondered before I wrote this book why everyone always thanks their families in a book's "acknowledgements" section. Now I know. I couldn't have gotten this task done without the support of my wife Amy and son Noah. Actually, Noah's too young to have put up a real fight, but he's a trooper nonetheless. Thanks you two for putting up with the late weeknights and stolen weekends. Hopefully my book residuals are enough to take us all to a nice dinner.
About the reviewers
Charles Young has more than twenty years' experience of software architecture, design, and implementation, and has worked on numerous projects as a developer, trainer, and consultant. He works as a Principal Consultant at Solidsoft, a UK-based company specializing in integration, workflow, and business process management on the Microsoft platform. Charles has wide experience of applying BizTalk Server, WCF, and WF to real-world problems. He has blogged extensively on the use of BizTalk Server and Business Rules, and is a regular speaker at architectural conferences and seminars.
Ewan Fairweather has worked for Microsoft for four years. He currently works as a Program Manager in the BizTalk Product Group on the Customer Advisory Team (CAT). The BizTalk CAT is responsible for improving customer experience with BizTalk through: defining and delivering the enterprise services that the product requires, providing prescriptive guidance on best practices to all customers, and improving future versions of the product through customer feedback and key learnings.
Prior to this, Ewan spent over three years working for Microsoft UK in the Premier Field Engineering team. In this role he worked with enterprise customers, helping them to maintain and optimize their BizTalk applications. This involved providing both proactive and reactive onsite assistance within the UK and the rest of Europe. Ewan has also worked in a dedicated capacity on some of the world’s largest BizTalk deployments, predominantly within financial services.
Ewan co-authored the successful Professional BizTalk Server 2006 book and has written many whitepapers for Microsoft including the Microsoft BizTalk Server Performance Optimization guide which is available on Microsoft’s MSDN website. Prior to joining Microsoft Ewan worked as a Cisco Certified Academy Instructor (CCAI) for a regional training organization delivering advanced routing and networking courses. Ewan holds a first class honors Bachelor of Science degree in Computing with Management from the University of Leeds. Outside of work, Ewan’s hobbies include reading, taking part in as many sports as possible, and regularly going to the gym.
Zach Bonham is a software developer working primarily with Microsoft's connected systems technology. Zach is active in the Dallas/Fort Worth user group community and is a member of Microsoft's Connected Technologies Advisor Group. You can catch up with Zach at http://zachbonham.blogspot.com.
I would like to thank Richard Seroter for taking the time to write this book as well as for his contributions to the online community. I would also like to thank Ray Crager for being the "smartest man alive" and a great teacher. There are an incredible number of BizTalk community members who need to be thanked, too many to list here, but you know who you are! Finally, I would like to thank my wife, Sally, and our two children for their love and support.
Preface
Repeat after me: SOA is something you do, not something you buy.
--David LinthicumThat may seem an odd quote to use when beginning a book about employing a particular product to facilitate the implementation of a service-oriented architecture (SOA). However, I think it sets the tone for what I'd like to accomplish here.
There are countless books available on service-oriented architecture, and nearly as many independent definitions of what SOA actually is. Is it about web services, event-driven design, enterprise architecture, reusability, or maybe just a retread of existing object-oriented design? Depending on whom you ask, any of those preceding themes would be deemed correct. If you're looking to implement a SOA, you would find numerous vendors who claim to offer "SOA in a box" where becoming service oriented is as straightforward as installing a product. However, I prefer to define SOA as an architectural discipline based on loosely-coupled, autonomous chunks of business functionality, which can be used to construct composite applications. There are plenty of vital characteristics that can be teased out of that definition, but the most important point is that building a successful SOA requires an enterprise commitment and a particular way of thinking about software design, which cannot be achieved by simply hitching your wagon to the SOA product de jour.
That said, a service-oriented architecture cannot be implemented using only high-minded strategies recorded with paper and pencil. It requires a technology solution that can realize the goals and vision of the business architecture. In this book, we're going to specifically investigate how to design and build service-oriented solutions using BizTalk Server 2009 as the host platform. The crop of high quality BizTalk Server books currently available all admirably cover the entire suite of capabilities which make up the product. And BizTalk by nature has many built-in service-oriented concepts such as loose coupling and message-oriented design, which are discussed in the existing books on hand. However, there is no book currently available that specifically looks at how to map service-oriented principles and patterns to the BizTalk product. That's where this book fits in.
One might look at Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) and ask why it matters to keep talking about BizTalk Server. Aren't these exciting technologies shepherding in a new era of Microsoft-based enterprise software design that makes a messaging bus like BizTalk obsolete? Fair question. Today, WF and WCF are foundational platform technologies on which future Microsoft applications will be built upon. They are both excellent at servicing particular problem areas around unified communication and workflow. BizTalk Server is Microsoft's enterprise class product, which enables process integration across disparate entities (such as organizations, platforms, applications) through a robust event-driven infrastructure that provides durable messaging, load balancing, and reliability. Similarly, while one can build a portal solution on top of Microsoft Internet Information Services (IIS) and ASP.NET technologies, the premier, complete portal offering from Microsoft is the SharePoint Server. I can attempt to build my own messaging solution using WCF and WF, but trying to design, build, and test such a solution takes me away from my primary goal of helping my organization solve business problems.
What about the upcoming "Oslo" wave of products from Microsoft, which include the "Dublin" server, "Oslo" repository, and modeling toolset? The "Dublin" server, which fits into IIS and provides a powerful host for WCF and WF applications, solves specific problems around hosting and managing WCF and WF solutions. It is not a replacement of BizTalk Server and serves a different purpose. The "Oslo" modeling platform offers a compelling way to visualize solutions and construct rich models which can turn into actual applications. It is meant to solve problems around overall application design and does not provide any sort of infrastructure for actually running applications.
Take a look at Chapter 12 for more about these upcoming technologies.
Much has been written about the business aspect of SOA and achieving enterprise momentum for designing software in a service oriented fashion. If you are looking at how to engage your CEO or business stakeholders and expound on the virtues of SOA, this book is not your best resource.
You will find that this book is a technical resource for folks looking to implement service-oriented patterns while exposing new services or consuming existing ones. We will take a deep look at how BizTalk Server works with the new WCF service model. We will also see how to take advantage of the BizTalk engine to build asynchronous processes and reusable orchestrations.
This book, at its core, is an explanation of how to construct flexible solutions that are built for change.
Is BizTalk Server the only product that can help you reach a service-oriented nirvana? Of course not. You can very successfully build a SOA without using BizTalk Server, or any single product, for that matter. In fact, your SOA strategy should NOT be dependent on a single vendor or product, but rather support an ecosystem of service enabled platforms. This protects you from future change, while encouraging general SOA patterns that are not product-specific.
That said, I plan to show you that BizTalk Server is an excellent platform for advancing your service-oriented architecture and creating new opportunities for making your environment more agile and flexible. As we work together through the examples in this book, I hope that you'll be able to visualize exactly how to utilize BizTalk Server in the most efficient manner within your organization's IT environment.
What this book covers
This book is put together in a way that encourages you to follow along and build up your comfort level and knowledge as we progress from chapter to chapter. Throughout this book, I will make use of simple pharmaceutical scenarios to demonstrate key concepts. This industry is where I spend my time nowadays, and the demos that we build should have a common theme. That said, if you have no experience in the pharmaceutical industry, there's nothing to worry about. The examples we work through will involve basic "patient" and "drug evaluation trials" scenarios that are easily understood and don't distract from the underlying technology message.
Chapters 1–3 are designed to introduce you to BizTalk and WCF and show you how to build a BizTalk services solution from scratch. This will help you keep up with the brisk pace of the later chapters. Chapters 4–12 build upon this knowledge and help you design and apply increasingly complex patterns and scenarios.
In Chapter 1, we will look at what exactly BizTalk Server is, review the core architecture of the application, and show how to build an end-to-end solution.
WCF is still a relatively new technology and many BizTalk customers are still comfortably using the classic ASP.NET web services framework. However, the future of the communication subsystem of Microsoft products is WCF, and it's an important technology to understand. In Chapter 2, we take a look at what problem WCF is attempting to solve, and how to actually build and host WCF services.
After having a solid foundation on BizTalk and WCF, we will look at how to actually use services in the BizTalk environment. In Chapter 3, we build a number of common scenarios using BizTalk and WCF services.
By Chapter 4, you will be comfortable with how BizTalk and WCF work, and how to build BizTalk solutions that take advantage of services. At this point it's crucial to investigate exactly what a service-oriented BizTalk solution looks like. What types of services should I expose? How can I exchange messages through the BizTalk bus? We'll answer these questions and much more at this stage of the book.
A critical part of the technology portion of your service design is the contract definition. What are you sharing with the outside world? In addition to the contract, the actual transportation channel is a vital selection for your service. In Chapter 5, we will look at building service-oriented contracts and how to effectively work with BizTalk's service endpoints.
BizTalk relies upon asynchronous communication, and in Chapter 6, we will look at how to take advantage of asynchronous messaging to build robust service-oriented solutions. We'll also cover the tricky concept of providing acknowledgements or results to clients that call services in a fire-and-forget fashion.
You can use BizTalk orchestration to design new service logic or, build new composite applications based on existing services that have been discovered. In Chapter 7, we will look at how to build reusable orchestrations, accommodate transactions, and work with service aggregation.
It's hard to build for change but it's a fact of life for every IT department. Fiddling with a service contract is a delicate operation, and in Chapter 8, we will investigate the options for minimizing the impact of service modifications.
BizTalk Server 2009 offers a brand new WCF-based SQL Server adapter. In Chapter 9, we will investigate common usage patterns for polling data and updating data.
Microsoft's UDDI Services have moved from being part of Windows Server to now being included only with BizTalk Server 2009. In Chapter 10, we will take a look at how to use the UDDI server to register and resolve services.
Microsoft's Enterprise Service Bus Guidance is a key part of a service-oriented BizTalk solution and in Chapter 11, we will dig through the various components and build a series of examples.
The Microsoft team responsible for BizTalk Server has an array of offerings on the upcoming slate. In Chapter 12, we will take a look at the role of .NET Services, what "Dublin" is, what's in store from "Oslo", and where BizTalk is heading in the future.
Who this book is for
There are multiple target audiences for this book. First off, I'm writing this book as a resource for developers who have been tasked with building service-oriented BizTalk Server solutions. Developers will be able to use this book to implement common patterns to design services in way that fosters reuse and encourages flexibility. When developers are tasked with using BizTalk to consume existing services, they can also use this book to review strategies and considerations they need to take into account.
This book is also targeted at architects, who are responsible for envisioning an enterprise solution and implementing the software blueprint. We will cover a variety of ways to use BizTalk in a service-oriented fashion that will help architects decide the best way to distribute the system processing.
As I mentioned earlier, this book is not a pure tutorial on BizTalk Server or WCF. So, I'll expect that you are somewhat familiar with BizTalk Server 2006 development, and have seen a WCF service in action before.
Also, I'll be spending plenty of time using Visual Studio.NET to demonstrate development tasks, so it would be useful if you have used Microsoft's development environment in the past.
That said, I will be providing a brief overview of both BizTalk Server and WCF, so if you are new to either, or both, I'd like to think that you will still find this book a valuable resource in your library.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply drop an email to <[email protected]>, and mention the book title in the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code for the book
Visit http://www.packtpub.com/files/code/5005_Code.zip to directly download the example code.
The downloadable files contain instructions on how to use them.
Errata
Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in text or code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration, and help us to improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to any list of existing errata. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. Building BizTalk Server 2009 Applications
Creativity is the power to connect the seemingly unconnected.
--William PlomerLet's begin our journey by investigating what BizTalk Server actually is, why to use it, and how to craft a running application. This chapter will be a refresher on BizTalk Server for those of you who have some familiarity with the product.
In this chapter, you will learn:
What is BizTalk Server?
So what exactly is BizTalk Server, and why should you care about it? In a nutshell, Microsoft BizTalk Server 2009 uses adapter technology to connect disparate entities and enable the integration of data, events, processes, and services. An entity may be an application, department, or even an altogether different organization that you need to be able to share information with. A software adapter is typically used when we need to establish communication between two components that do not natively collaborate. BizTalk Server adapters are built with a common framework which results in system integration done through configuration, not coding.
Traditionally, BizTalk Server has solved problems in three areas. First, BizTalk Server acts as an Enterprise Application Integration (EAI) server that connects applications that are natively incapable of talking to each other. The applications may have incompatible platforms, data structure formats, or security models. For example, when a new employee is hired, the employee data in the human resources application needs to be sent to the payroll application so that the new employee receives his/her paycheck on time. Nothing prevents you from writing the code necessary to connect these disparate applications with a point-to-point solution. However, using such a strategy often leads to an application landscape that looks like this:
Many organizations choose to insert a communication broker between these applications as shown in following figure.
Some of the benefits that you would realize from such an architectural choice include:
BizTalk Server solves a second problem by filling the role of business-to-business (B2B) broker that facilitates communication across different organizations. BizTalk supports B2B scenarios by offering Internet-friendly adapters, industry-standard EDI message schemas, and robust support for both channel- and message-based security.
The third broad area that BizTalk Server excels in is Business Process Automation (BPA). BPA is all about taking historically manual workflow procedures and turning them into executable processes. For example, consider the organization that typically receives a new order via email and the sales agent manually checks inventory levels prior to inserting the order into the Fulfillment System. If inventory is too low, then the sales agent has to initiate an order with their supplier and watch out for the response so that the Inventory System can be updated. What problems are inevitable in this scenario?
By deciding to automate this scenario, the company can reduce human error while streamlining communications between applications and organizations.
What's one thing all of these BizTalk Server cases have in common? They all depend on the real-time interchange and processing of discrete messages in an event-driven fashion. This partially explains why BizTalk Server is such a strong tool within a service-oriented architecture. We'll investigate many of BizTalk's service-oriented capabilities in later chapters, but it's important to note that the functionality that exists to support three top-level scenarios above (EAI, B2B, and BPM) nicely fits into a service-oriented mindset. Concepts such as schema-first design, loose coupling, and reusability are soaked into the fabric of BizTalk Server.
Note
Critical point
BizTalk Server should be targeted for solutions that exchange real-time messages as opposed to Extract Transform Load (ETL) products that excel at bulky, batch-oriented exchanges between data stores.
BizTalk Server 2009 is the 6th release of the product, the first release being BizTalk Server 2000. Back in those days, developers had access to four native adapters (file system, MSMQ, HTTP, and SMTP); development was done in a series of different tools, and the underlying engine had some fairly tight coupling between components. Since then, the entire product was rebuilt and reengineered for .NET and a myriad of new services and features have become part of the BizTalk Server suite. The application continues to evolve and take greater advantage of the features of the Microsoft product stack, while still being the most interoperable and platform-neutral offering that Microsoft has ever produced.
BizTalk architecture
So how does BizTalk Server actually work? BizTalk Server at its core is an event-processing engine, based on a conventional publish-subscribe pattern. Wikipedia defines the publish-subscribe pattern as:
An asynchronous messaging paradigm where senders (publishers) of messages are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into classes, without knowledge of what (if any) subscribers there may be. Subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what (if any) publishers there are.
Note
Critical point
This pattern enforces a natural loose coupling and provides more scalability than an engine that requires a tight connection between receivers and senders. In the first release of BizTalk Server, the product DID have tightly coupled messaging components, but thankfully the engine was completely redesigned for BizTalk Server 2004.
Once a message is received by a BizTalk adapter, it runs through any necessary pre-processing (such as decoding) in BizTalk pipelines, before being subjected to data transformation via BizTalk maps, and finally being published to a central database called the MessageBox. Then, parties which have a corresponding subscription for that message can consume it as they see fit. While introducing a bit of unavoidable latency, the MessageBox database makes up for that by providing us with durability, reliability, and scalability. For instance, if one of our subscriber systems is offline for maintenance, outbound messages are not lost, but rather the MessageBox makes sure to queue messages until the subscriber is ready to receive them. Worried about a large flood of inbound messages that steal processing threads away from other BizTalk activities—no problem! The MessageBox makes sure that each and every message finds its way to its targeted subscriber, even if it must wait until the flood of inbound messages subside.
There are really two ways to look at the way BizTalk is structured. The first is the traditional EAI view, which sees BizTalk receiving messages, and routing them to the next system for consumption. The flow is very linear and BizTalk is seen as a broker between two applications.
However, the other way to consider BizTalk, and the focus of this book, is as a service bus, with numerous input/output channels that process messages in a very dynamic way. That is, instead of visualizing the data flow as a straight path through BizTalk to a destination system, consider BizTalk exposing services as on-ramps to a variety of destinations. Messages published to BizTalk Server may fan out to dozens of subscribers, who have no interest in what the publishing application actually was. Instead of thinking about BizTalk as a simple connector of systems, think of BizTalk as a message bus which coordinates a symphony of events between endpoints.
This concept, first introduced to me by the incomparable Charles Young (http://geekswithblogs.net/cyoung/), is an exciting way to exploit BizTalk's engine in this modern world of service-orientation. In the diagram below, I've shown how the central BizTalk bus has receiver services hanging off of it, and has a multitude of distinct subscriber services that are activated by relevant messages reaching the bus.
Tip
If the on-ramp concept is a bit abstract to understand, consider a simple analogy. In designing the transportation for a city, it would be foolish of me to create distinct roads between each and every destination. The design and maintenance of such a project would be lunacy. I would be smart to design a shared highway with on and off ramps, which enable people to use a common route to get between the numerous locations around town. As new destinations in the city emerge, the entire highway (or road system) doesn't need to undergo changes, but rather, only a new entrance/exit point needs to be appended to the existing shared infrastructure.
What exactly is a message anyway? A message is data processed through BizTalk Server's messaging engine, whether that data is transported as an XML document, a delimited flat file, or a Microsoft Word document. The message content may contain a command (for example InsertCustomer), a document (for example Invoice), or an event (for example VendorAdded). A message has a set of properties associated with it. First and foremost, a message may have a type associated with it which uniquely defines it within the messaging bus. The type is typically comprised of the XML namespace and the root node name (for example http://CompanyA.Purchasing#PurchaseOrder). The message type is much like the class object in an object-oriented programming language; it uniquely identifies entities by their properties. The other critical attribute of a message in BizTalk Server is the property bag called the message context. The message context is a set of name/value properties that stays attached to the message as long as it remains within BizTalk Server. These context values include metadata about the transport used to publish the message, and attributes of the message itself. Properties in the message context that are visible to the BizTalk engine, and therefore available for routing decisions, are called promoted properties.
How does a message actually get into BizTalk Server? A receive location is configured for the actual endpoint that receives messages. The receive location uses a particular adapter, which knows how to absorb the inbound message. For instance, a receive location may be configured to use the FILE adapter which polls a particular directory for XML messages. The receive location stores the file path to monitor, while the adapter provides transport connectivity. Upon receipt of a message, the adapter stamps a set of values into the message context. For the FILE adapter, values such as ReceivedFileName are added to that message's context property bag. Note that BizTalk has both application adapters such as SQL Server, Oracle, and SAP as well as transport-level adapters such as HTTP, MSMQ, and FILE. The key point is that the adapter configuration user experience is virtually identical regardless of the type of adapter chosen.
Receive locations have a particular receive pipeline associated with them. A pipeline is a sequential set of operations that are performed on the inbound message in preparation for being parsed and processed by BizTalk. For instance, I would need a pipeline in order to decrypt, unzip, or validate the XML structure of my inbound message. One of the most critical roles of the pipeline is to identify the type of the inbound message and put the type into the message context as a promoted property. As discussed earlier, a message type is the unique characterization of a message. Think of a receive pipeline as doing all the pre-processing steps necessary for putting the message in its most usable format.
A receive port contains one or more receive locations. Receive ports have XSLT maps associated with them that are applied to messages prior to publishing them to the MessageBox database. What value does a receive port offer me? It acts as a grouping of receive locations where capabilities such as mapping and data tracking can be applied to any of the receive locations associated with it. It may also act as a container that allows me to publish a single entity to BizTalk Server regardless of how it came in, or what it looked like upon receipt. Let's say that my receive port contains three receive locations, which all receive slightly different "invoice" messages from three different external vendors. At the receive port level, I have three maps that take each unrelated message and maps it to a single, common format, before publishing it to BizTalk.
Tip
Critical point
By default, all messages pass through BizTalk Server as a stream of bytes, not as an XML message loaded into the server's memory. Therefore, when the message is published to the MessageBox, BizTalk Server has yet to look inside the message unless:
Note that custom pipeline components may also peek into the message content. If the message has promoted properties associated with it, then the disassembler pipeline component will extract the relevant data nodes from the message and insert them into the message context.
Now that we have a message cleaned up (by the pipeline) and in a final structure (via an XSLT map), it's published to the BizTalk Server MessageBox where message routing can begin. For our purposes, there are two subscribers that we care about. The first type of subscriber is a send port. A send port is conceptually the inverse of the receive location and is responsible for transporting messages out of the BizTalk bus.
It has not only an adapter reference, adapter configuration settings, and a pipeline (much like the receive location), but it also has the ability to apply XSLT maps to outbound messages. If a send port subscribes to a message, it first applies any XSLT maps to the message, then processes it through a send pipeline, and finally uses the adapter to transmit the message out of BizTalk.
The other subscriber for a published message is a BizTalk orchestration. An orchestration is an executable business process, which uses messages to complete operations in a workflow. We'll spend plenty of time working with orchestration subscribers throughout this book.
Setting up new BizTalk projects
What do you need to set up a brand new BizTalk project? First, you will want to have a development environment with Windows Server 2008, IIS 7.0, SQL Server 2008, Visual Studio 2008, and BizTalk Server 2009, installed in that order.
Consider using a standard structure for all of your BizTalk Server solutions. This makes it easier to package and share source code, while also defining a consistent place to store solution artifacts in each project. To build the structure below, I put together a VBScript file, which is available on my blog at: http://seroter.wordpress.com/2007/03/29/script-for-automatically-creating-biztalk-solution-structure/.
Note that BizTalk Server 2009 solutions can (and should) be centrally persisted in standard source control applications such as Subversion or Microsoft Team Foundation Server.
You can tell if you have successfully installed BizTalk Server in your development environment if you are able to see BizTalk Projects in the Visual Studio.NET New Projects menu option.
When a new BizTalk Project is added to a Visual Studio.NET solution, you should immediately right-click the project and select the Properties option. In BizTalk Server 2009, we can now set properties in the familiar C# project properties pane, instead of the BizTalk-only properties window. The BizTalk project type has been redesigned so that BizTalk projects are now simply specialized C# project types.
The first value that you need to set is under the Signing section. You can either point to an existing strong name key, or now in BizTalk Server 2009, generate a new key on the fly. BizTalk Server projects are deployed to the Global Assembly Cache (GAC) and must be strong named prior to doing so. After setting the necessary key value, navigate to the BizTalk-specific Deployment section, and set the Application Name to something meaningful such as BizTalkSOA.
Once you have a project created, the strong name key set, and application name defined, you're ready to start adding development artifacts to your project.
What are BizTalk schemas?
Arguably the building block of any BizTalk Server solution (and general SOA solution) is the data contract, which describes the type of messages that flow through the BizTalk bus. A contract for a message in BizTalk Server is represented using an industry-standard XML Schema Definition (XSD). For a given contract, the XSD spells out the elements, their organizational structure, and their data types. An XSD also defines the expected ordering of nodes, whether or not the node is required, and how many times the node can appear at the particular location in the node tree. Following is an example XSD file:
Having a strict contract can reduce flexibility but it greatly increases predictability as the message consumer can confidently build an application, which depends on the message being formatted a specific way.
Schema creation and characteristics
While producing completely valid XSD syntax, the BizTalk Schema Editor takes a higher-level approach to defining the schema itself. Specifically, instead of working purely with familiar XML concepts of elements and attributes, the BizTalk Schema Editor advances a simpler model based on records and fields, which is meant to better represent the hierarchical nature of a schema. Do not let this fact mislead you to believe that the BizTalk Schema Editor is just some elementary tool designed to accommodate the drooling masses. In fact, the Editor enables us to graphically construct relatively complex message shapes through a fairly robust set of visual properties and XSD annotations.
There are a multiple ways to create schemas in the BizTalk Schema Editor. These include:
If you're like me, you often sketch the schema layout first, and only later worry about concepts such as data types, repeating nodes, and entry restrictions. By default, each new node is assigned a string data type and is assumed to only exist once in a single XML document. Using the BizTalk Server Schema Editor, you can associate a given node with a wide variety of alternate data types such as dateTime, integer, andbase64Binary. One thing to remember is that while you may use a more forgiving schema for inbound data, you should be strict in what you send out to other systems. We want to make sure to only produce messages that have clean data and stand little chance of being outright rejected by the target system.
Changing the number of times a particular node can appear in an XML document is as simple as highlighting the target node and setting the Max Occurs property. It's also fairly straightforward to set limits on the data allowed within certain nodes. What if we want a ZipCode field to only accept a maximum of 10 characters? Or what if the data stored in an AddressType node should be constrained to only 3 allowable choices? By default, these options are not visible for a given node. To change that, you can select a node and set the Derived By equal to Restriction. A flurry of new properties becomes available such as Maximum Length or Enumeration.
Property schemas
A critical BizTalk schema concept to examine is the property schema. Earlier in this chapter, I mentioned the notion of promoted properties which expose a message's data content to the BizTalk messaging layer. This in turn allows for a message to be routed to subscribers who are specifically interested in data condition (for example OrderNumber12345). Promoted properties are defined in a property schema, which is a special schema type within BizTalk Server. The property schema contains a flat list of elements (no records allowed) that represent the type of data we want the BizTalk messaging engine to know about. Once the property schema is created, we can associate specific fields in our message schema with the elements defined in the property schema. As we will see in practice later in this book, one key benefit of property schemas is that they can be used by more than one XSD schema. For instance, we could create a NewEmployee and ModifiedEmployee message that both map to a single EmployeeID property field. In this manner, we can associate messages of different types which have common data attributes.
The BizTalk Schema Editor is a robust tool for building industry-standard XSD schemas. In a service-oriented architecture, the data contract is key, and understanding how to construct an XSD contract within BizTalk Server is an important skill.
What are BizTalk maps?
Rarely does data emitted from one system match the structure and content expected by another system. Hence, some sort of capability is needed to translate data so that it can be digested by a variety of consumers. Extensible Stylesheet Language Transformations (XSLT) is the industry standard for reshaping XML documents and the BizTalk Mapper is the tool used by BizTalk developers to graphically build XSLTs.
W
