In January this year I participated in a SOA architect workshop and after 5 exams I officially became certified SOA architect. The certification was issued by SOA schools which is an initiative of the well known SOA author Thomas Erl.
It was a very interesting course which discussed concepts I already knew, but wasn’t really aware of. During the course I more and more was able to map the concepts of SOA to Microsoft technology. One of the SOA characteristics is vendor neutrality so the course didn’t really discuss implementations.
Two course modules discussed design patterns (http://www.soapatterns.org/) and one of them is the ESB compound design pattern. It is called a compound pattern because it is build of other design patterns.
I started to recognize and map parts of BizTalk Server onto the ESB design pattern, but I didn’t have the full picture yet. In this blog post I take the ESB design pattern as a starting point to find out how and if BizTalk Server can be called an ESB based on this design pattern.
The ESB compound design pattern consists of the base pattern with these design patterns:
- Asynchronous Queuing
- Service Broker
- Data Model Transformation
- Data Format Transformation
- Protocol Bridging
- Intermediate Routing
and the extended version is:
- Reliable Messaging
- Policy Centralization
- Rules Centralization
- Event-Driven Messaging
BizTalk Server (together with the ESB Toolkit) is Microsofts product for implementing an ESB. To what extend does the vendor neutral design pattern map to the functionality in BizTalk Server?
Let’s start with the base pattern.
Asynchronous Queuing
In the SOA world this means that a service should be able to exchange messages with its consumers via an intermediary buffer, allowing service and consumers to process messages independently by remaining temporally decoupled.
BizTalk Server is asynchronous by nature, because all messages flowing through BizTalk are stored in the SQL Server message box thereby disconnecting consumers from services.
This SOA design pattern is explained here.
Service Broker
The service broker design pattern covers some of the most basic concepts necessary for application integration. This is about conversion of messages and the capability to receive messages via various types of protocols.
- Data Model Transformation
- A data transformation technology should be incorporated to convert data between disparate schema structures.
- Data Format Transformation
- Intermediary data format transformation logic needs to be introduced in order to dynamically translate one data format into another
- Protocol Bridging
- Services using different communication protocols or different versions of the same protocol should be able to exchange data.
Both types of transformations are solved in BizTalk Server using maps. Model transformation is about transforming one XML Schema to another and format transformation is transforming one message format to another, for example flat file or CSV to an XML Schema.
Protocol bridging is implemented in BizTalk Server using adapters and is about the ability of communication between different communication protocols like different versions of SOAP or something totally different like FTP.
Intermediate Routing
From a SOA perspective this is about the ability to dynamically determine message paths though the use of routing logic. Intermediate routing is typically implemented using service agents. A service agent is an event-driven program that doesn’t require explicit invocation, it just intercepts the messages. There are two types of service agents, active and passive. Active service agents not only read the message but also modify the message contents. Passive service agents only read the message and will or will not take action on the message content but doesn’t change it.
In BizTalk Server intermediate routing is implemented by means of a message agent. This agent is monitoring the message box to handle subscriptions to messages. In BizTalk everything is routed via the message box, so it can be implemented with only promoted properties or there can be complete routing logic in orchestrations or via business rules.
Reliable Messaging
This is about assuring that a message is actually received to the service. In a SOA world this is a technology concept to enable reliable communication with services. Commonly this is solved by a combination of the WS-ReliableMessaging standard and guaranteed delivery extensions like a persistent repository.
In BizTalk Server this is called guaranteed delivery, which assures to the caller that once a message is received in BizTalk Server it never will be lost. This is the persistent repository in the section above. The WS-ReliableMessaging standard is not supported by BizTalk due to its architecture.
Policy Centralization
In the context of SOA a service contract can be comprised of one or more XML Schemas, the WSDL, one or more Policies and an SLA. A policy adds information to the service commonly applied using the WS-Policy standard. This information can for example consist of the service window of a service or that it is only capable of handling so many requests an hour. Policy centralization is about applying centrally maintained policies to services.
Looking at BizTalk Server it seems like the ESB Toolkit supports some kind of policy centralization, but that appears to be related to itinerary centralization. Policy centralization probably should be maintained by a 3rd party product and cannot be maintained in BizTalk Server or with the ESB Toolkit.
Rules Centralization
Business rules are critical to companies and having the rules spread across a company is not a sustainable solution. The rules centralization design pattern is about centrally accessing, storing and managing business rules.
Business rules are part of BizTalk Server by means of the Business Rules Engine(BRE). This is even a separate component that can be used without other BizTalk components. Rules can be centrally accessed, stored and maintained in there. In a SOA approach the BRE would be wrapped into a service so it’s functionality is accessible in a standardized way from other technologies besides BizTalk Server. Wrapping such a component into a service raises other issues like introducing a single point of failure and capacity issues. These issues can be solved by applying other SOA design patterns
Event-Driven Messaging
From a SOA perspective this is about notifying customers of events. Commonly this is solved by subscribing customers to service events via one-way and asynchronous data transfer.
This is one of the most known concepts in BizTalk Server, because it refers to the publish-subscribe pattern as it is used in BizTalk Servers messaging architecture with the SQL Server message box as the heart of the system.
Conclusion
In this blog post we’ve been discussing the official ESB compound design pattern as defined by Thomas Erl. At least one of the requirements cannot be fulfilled by BizTalk Server, and that is Policy Centralization. So officially BizTalk Server is not an ESB product according to these requirements.
On the other hand, policy centralization is one of the least used requirements in an ESB implementation at the moment. And besides that, BizTalk Server implements many more design patterns than just the ones mentioned in the ESB design pattern.
On of the most recognizable design patterns for BizTalk Server is the Orchestration compound design pattern.
Although this compound pattern is targeted at synchronous processing, it does consist of interesting design patterns we can also find in BizTalk Server:
- Process Abstraction
- This is about abstracting logic into a parent processes (task services). In BizTalk Server processes can be constructed of combined (agnostic) services using orchestrations. An orchestration is an abstraction of such parent processes which can be called by services without knowledge of the underlying logic.
- Process Centralization
- This is to prevent process logic to be spread across the company. All processes in BizTalk Server are centralized into one repository thereby fulfilling this requirement.
- State Repository
- This is about offloading state to a repository to release resources when they are not necessary at that time. BizTalk Server supports this by means of hydration and dehydration of processes.
- Compensating Service Transaction
- To prevent system locks during long running processes, compensating measures can be taken in case of an exception. BizTalk Server supports compensating service transactions as part of orchestration building blocks.
- Atomic Service Transaction
- To be able to rollback changes if one of the services in a chain of service calls fail, atomic service transactions can be used. BizTalk Server supports atomic service transactions in it’s WCF adapter.
- Rules Centralization
- Is also part of the ESB compound design pattern
- Data Model Transformation
- Is also part of the ESB compound design pattern
Didago IT Consultancy
Back in December 2011 Microsoft released the first CTP of the Azure Service Bus EAI/EDI. It showed what direction Microsoft is heading with bringing BizTalk like functionality to the cloud. Or to quote Microsoft:
“Windows Azure Service Bus EAI and EDI Labs provides integration capabilities for the Windows Azure Platform to extend on-premises applications to the cloud, provides rich messaging endpoints on the cloud to process and transform the messages, and helps organizations integrate with disparate applications, both on cloud and on-premises. In other words, Service Bus EAI and EDI Labs provides common integration capabilities (e.g. bridges, transforms, B2B messaging) on Windows Azure Service Bus”
If you want to read more about this, please take a look at my two previous blog posts about this topic:
BizTalk in the Cloud, one step closer (part 1)
BizTalk in the Cloud, one step closer (part 2)
Now Microsoft has released the second preview:
Service Bus EAI and EDI Labs - April 2012 Release
Download the April 2012 Release
So what’s new in this April 2012 release?
Regarding the EAI Bridges, we’ve got the following enhancements. BizTalk developers will recognize parts that currently only are available in BizTalk….
- FTP Source Component. In the December 2011 release it was already possible to connect WCF endpoints via the publish/subscribe pattern. In this refresh another endpoint type has been added: FTP, which can be used as a source component on the configuration bridge. In the BizTalk world this would be the FTP adapter, but so far it is reading only.
- Flat File Support. This is also a familiar concept in the BizTalk world. Combined with the FTP source component, flat files for example can be read and converted into XML now. But also via HTTP flat files can be read and processed. The available flat file wizard looks quite the same as currently can be found in BizTalk Server.
- Schema Editor. Previously only available in BizTalk, now also part of the Service Bus EAI/EDI release. Used to create and edit XSD and flat file schemas
- Service Consuming Wizard. Also straight from BizTalk Server, the possibility to generate the necessary artifacts to be able to consume WCF services. The difference with EAI is that it only generates an XSD and no other output files like binding info and an orchestration.
- Operational Tracking of messages processed by the bridge. This is also something from BizTalk Server. Within a bridge, a message undergoes processing under various stages and can be routed to configured endpoints. Specific details of the message such as transport properties, message properties, etc. can be tracked and queried separately by the bridge developers to keep a track of message processing.
For Service Bus Connect, there are the following enhancements.
- Support for Windows Authentication while connecting to on-premise SQL Servers
- User Interface enhancements
- Support for SSL
The transforms also have been improved.
- New map operations. In BizTalk this is called ‘Functoids’ but are named operations here. Added are:
- Number format operation, to format an input number using a given format
- Date/Time operation, to manipulate date/time
- Generate ID operation, to generate a unique ID of a given length
- Runtime behavior configuration. This is also interesting for BizTalk developers, because like Microsoft says:”In this release, users can configure the runtime behavior for how the transform handles exceptions, errors, null values, and empty data input. This configuration can be done for each transform”. This sounds exciting and probably something we’ll be seeing in the next version of BizTalk Server.
Finally the EDI or Business to Business Messaging, which now has support for:
- Processing batched EDI messages. You can now use the TPM portal to configure agreements that can process batched messages coming from trading partners
- Tracking and archiving EDI messages. You can now use the TPM portal to track messages as they are processed using the agreements
I’m looking forward dive into the details! BizTalk Server in the cloud again one step closer!
Didago IT Consultancy
In my previous post I discussed a part of the recently released CTP of Windows Azure Service Bus EAI and EDI. I went over installation and the steps to take to create schemas and mappings (in this post I use different schemas and mapping, because of Visual Studio issues I had to start over).
This post is about how the schemas and mappings are used in Windows Azure. Like we’re used to with BizTalk we need the schemas to define the message types and we need the mappings to transform one message type to another. But how does this all fit together?
When you create a new ‘ServiceBus’ project, you’ll notice a new “BridgeConfiguration.bcs” file:
This file will contain the definition of the ‘Bridge’ between two systems connected to Azure. If you open the “bcs” file you’ll get an empty canvas and in the toolbox there are many options to fill the bridge configuration with:
For example pick the ‘Xml One-Way Bridge’. This is one-way WCF service endpoint, opposed to the ‘Xml Request-Reply Bridge’ of which you probably guessed it to be a request/response WCF service endpoint. The canvas looks like below:
In the solution explorer you’ll find the two schemas (SourceSchema.xsd and TargetSchema.xsd) and a mapping (Source_to_Target.trfm) I use to test with. The schema by the way is a simple mapping with a concatenation and the new if-then-else functoid (which isn’t called a functoid anymore).
Also a configuration file has been added to the solution: “XmlOneWayBridge1.BridgeConfig”, which in the end is just an XML configuration file but a so called ‘Bridge Editor’ has been created for ease of editing. Double clicking the file results in this.
In this we recognize the BizTalk pipeline! In the message types module you specify the schema's you wish to be accepted by this endpoint. The validator is just an XML validator of which I assume it can be replaced by a custom component in the future. However keep in mind that this is running in the cloud so Microsoft will be careful with custom components which might impact the performance and stability of Azure.
Enriching is interesting, it feels like property promotion in BizTalk. It opens the opportunity of content based routing. You can enrich from SOAP, HTTP, (SQL) Lookup and XPath. In the picture below I created XPath properties in the SourceSchema.xsd.
The transform module also looks familiar to BizTalk developers. Obviously only the maps that are defined as a message type in the bridge show up here:
If you build the solution now, you’ll get errors. The errors indicate that without a so called ‘Connected Entity’ the message send to this end point cannot be processed. So we need to add one to the bridge configuration. In this case I’ll write the message to a queue, but that can also be an external service that the message is relayed to. When the Queue is dropped on the canvas, it can be connected to the XmlOneWayBridge by using a ‘Connection’. Be aware you can only connect on the red dots and dragging the queue shape doesn’t create a queue on the ServiceBus.
Building this still results in an error about a filtering expression. This is caused by the fact that by default a filter expressing is specified on the connection to the Queue. To fix this click on the connection, select ‘Filter Condition’ and set the filter to ‘Match All’ (or specify a filter).
Now the project will build and the next step will be deploy to Azure!
Because Azure EAI still is in a lab phase, you need to go to a different portal than the regular Azure Management portal: https://portal.appfabriclabs.com/Default.aspx
Go there and create a so called “labsubscription”. If you haven’t created such a subscription before deployment you’ll receive an error: “The remote name could not be resolved: '<servicenamespace>-sb.accesscontrol.appfabriclabs.com'”
From the project file menu select ‘Deploy’ and the regular Azure deploy dialog shows up. Specify the Shared Secret and the project will be deployed:
Now it is time for fun by testing the bridge with the tools that come with the SDK. The set of tools contains the ‘MessageSender’ tool, which takes the account credentials, bridge URL, sample message and content type. This message was sent to the bridge:
<?xml version="1.0" encoding="utf-8"?>
<SourceSchema xmlns="http://MyFirstAzureEAI.SourceSchema">
<FirstName xmlns="">FirstName1</FirstName>
<LastName xmlns="">LastName1</LastName>
<Age xmlns="">1</Age>
<Country xmlns="">Country1</Country>
<BirthDate xmlns="">1900-01-01</BirthDate>
</SourceSchema>
Now the message is sent to the bridge and went through the pipeline where it was transformed from ‘SourceSchema’ to ‘TargetSchema’. After the pipeline processing has been done the message is written to the queue, TestEAIQueue in my case.
With another tool also from the SDK you can read messages from the queue: ‘MessageReceiver’.
In the message read from the queue you can derive the FirstName and LastName field from the SourceSchema have been concatenated in the TargetSchema. Also it has been derived that someone with and age of 1 is not an adult (IsAdult=false).
Wow, my first BizTalk-in-the-cloud-round-trip is working!
There is a lot more to discover and it is a CTP but this is working quite nice already. One thing we’re lacking in BizTalk today is the possibility to debug by pressing F5. I’m wondering if that will change with Azure EAI in the future.
Didago IT Consultancy
We all know Microsoft is putting an enormous amount of effort in their cloud initiative called Azure. It started with compute and storage but in the mean time it has grown and more and more products are released in a cloud version before the on-premise version is released. An example is Microsoft Dynamics CRM Online.
Since the September 2011 release of Azure the Service Bus is part of it. In the service bus we find things we know from BizTalk. The most well-known ones are Queues, Topics and Subscriptions. This so called ‘Brokered Messaging’ introduces message queuing and durable publish/subscribe messaging, which is the basis of BizTalk messaging.
Of course BizTalk is capable of a lot more, but Microsoft released today the CTP of Windows Azure Service Bus EAI and EDI. If we take a look at this release we immediately recognize the BizTalk influences in there. It is a CTP but it is showing the direction Microsoft is going.
Let’s focus on EAI for now. To install the SDK you just need a regular development machine with Windows 7/2008, .NET4 and VS2010. Download the SDK here. Installing the SDK will install some new VS templates under the section ‘ServiceBus’.
When the EAI project is created, the Solution Explorer looks like this:
And also new toolbox items are present, in which you’ll recognize the ServiceBus features Queues and Topics:
So the first step in BizTalk development would typically be to add a schema. This can be done by the regular ‘Add Item’ option in the Solution Explorer. There the first real BizTalk items show up! We all know the Maps and Schemas!
One thing that caught my eye was the extension of the mapping file, not BTM but TRFM. I can only speculate what the extension stands for.
Adding the schema is nothing new since adding XSD’s has been part of Visual Studio 2010 from the beginning.
Next step is creating a map, after adding the item another familiar screen shows up!
As well as selecting the source and destination schema. Unfortunately it isn’t possible to drag the schemas onto the mapping canvas.
And of course the toolbox is also familiar, although some items are missing, new or named differently from BizTalk.
This is definitely a preview of the new mapper as it will show up in the next version of BizTalk. Although the mapper has improved in BizTalk 2010, this one is even more advanced (and worth a blog post by itself!). For example I put the ‘If-Then-Else’ expression on the canvas:
This is really awesome!
Testing the map works quite the same way as in BizTalk, however it isn’t possible yet to generate a sample message from the schema so you need to create one yourself.
Typically you would also create artifacts like orchestrations, pipelines, etc, but they are missing in this CTP. However it won’t be a surprise that at least orchestrations will show up with WF4 in the near future.
So now we have a schema and a mapping, now what to do with it? Keep in mind that this is all Azure stuff so we need to deploy it into the cloud.
I’ll discuss these steps in my next blog post, but we’re definitely moving towards BizTalk in the cloud! Exciting stuff!
Didago IT Consultancy
Just before my holiday started, I got the great news that my article on the BizTalk Software Factory had been published on the Dutch .NET magazine site! It is my first article ever!
The BizTalk Software Factory is a community tool that helps BizTalk developers build consistent solutions.
Together with Mr. Dijkstra I wrote an article to explain the advantages of using the BizTalk Software Factory. The concepts of the BizTalk Software Factory can be applied to other technologies as well though.
You can find the article here, but keep in mind it is in Dutch…
Didago IT Consultancy
With the release of the BizTalk Software Factory for BizTalk Server 2010 a lot of people ask me what it takes to customize the way it works. They know the factory could help them with development of BizTalk applications, but current company standards are preventing them.
The BizTalk Software Factory (BSF) contains best practices and coding + naming conventions and they typically are not the same in all companies. This fact limits the usage of the BSF or the company need to adjust its coding convention to the BSF, which is not very likely.
This blog post outlines how easy it is to change the default behavior of the BSF to suit your companies coding conventions. Extensibility in Visual Studio 2010 became so much easier that is shouldn’t hold you from adjusting the BSF to your needs.
If you’re new to the BSF I recommend to read the documentation first.
Adjusting the BSF actually is quite easy, the GAT/GAX prerequisites are already installed. First, grab the code from CodePlex by clicking on the ‘Download’ button.
You’ll end up with a ZIP file with all sources from all versions of the BSF. Extract it and just delete the versions you don’t need and keep the ‘BizTalkSoftwareFactory for BizTalk Server 2010’. Open the solution in Visual Studio 2010 and you’ll see this project structure.
In general the actions done by the BSF are stored in so called ‘Recipes’. A recipe contains the steps, dialogs/wizards and actions that are to be executed when a recipe is started. The main recipe for generating the project structure can be found in the ‘Recipe’ folder and is called ‘CreateSolutionRecipe.xml’. If you’re curious take a look at it, but be warned that it is quite difficult to read (let alone debug). The actions called from within a recipe are partly included in the GAX/GAT libraries and the custom ones are in the ‘Actions’ folder.
What template is being used for a certain recipe is specified in the ‘BindingRecipe.xml’. If you open that file you’ll see for example that context menu item ‘Add Map’ is bound to the ‘Items\BizTalkMap.vstemplate’ (in the templates folder) and that file refers to a recipe named ‘NewItemMap’ (which is the name of the recipe stored in the file ‘NewItemMapRecipe.xml’.
This was just to show you the complexity behind the BSF, but changing the template is not complex at all.
The most important part of the solution for this blog is the ‘Templates’ section. There you’ll find the templates that are used during generation of the project structure.
For creating the project structure and adding the individual items, templates are being used like the ones specified in the ‘Templates’ folder.
- Items – template items that can be added from the context menu, like a map or schema
- Overview – contains documentation
- Projects – template projects used in the solution generation, like BizTalk or Class Library projects
- References – assemblies that are being used in the projects or items
- Solutions – template solution used in generating the solution generation
- Text – T4 templates used with adding individual items, used for the deployment framework and unit test generation
Items
Every item needs a vstemplate and one or more source files. The vstemplate file contains the recipe that will be executed and sometimes files that should be copies as part of the recipe. A good candidate for customization is the ‘BizTalkOrchestration’ item. Many companies have a standard way of setting up an orchestration, for example with default exception handling or logging. By creating a template for it, it will be generated by the BSF every time the ‘Add Orchestration’ is selected from the context menu.
Projects
Projects contain the non-BizTalk projects, like can be seen in the picture. Here you also find the vstemplate file which specifies which files need to be copied. Looking a the class library, the ‘SampleClass.cs’ is what is added to the class library by default. Customizing this file to your needs will speed up development. In this sample class as well as the csproj file you’ll find variables for naming.
These variables are replaced by Visual Studio when the recipe is executed. By adjusting these values you can use your own naming conventions. You’ll find these variables in every project file. More variables are available on MSDN.
Solutions
This contains the BizTalk project that is the template for all generated BizTalk projects in the solution. You can customize this as well by adding for example a default file that you need in all projects.
Text
The text section contains the files that are generated using T4 templates. While generating the project structure the ‘Deployment’ section is customized and the ‘UnitTest’ section is used when a new unit test is added using the context menu.
Generating a unit test is initiated from a recipe, which is bound to a context menu. The recipe is of course stored in the ‘Recipe’ folder. By opening for example the ‘NewItemUnitTestMapRecipe.xml’, you’ll find the location where the variables are inserted into the T4 template.
The output is a customized class file which is saved to the project by the next action. You can customize the unit test file by only adding some standard code to the class file or you can further enhance it by inserting more values, which is of course a bit more complex.
Well you have changed the templates, now what?
Like any Visual Studio project you need to recompile the solution. Make sure that you’ve uninstalled the BSF using the Extension Manager.
After compilation you can install the BSF again and run Visual Studio to test your changes.
I hope this post gave an insight in how the BSF works and that it is not that complex to customize it to your needs.
In case you run into any issue or you need assistance, let me know and I’m happy to help you.
Didago IT Consultancy
It took a while but now I can proudly announce the release of v3.0 of the BizTalk Software Factory!
This version supports:
Opposed to the BSF versions for BizTalk 2006 and BizTalk 2009, this release no longer supports the creations of custom pipeline components. It would have meant quite some work and wouldn’t add much value. To create a custom pipeline component, I would recommend using the Pipeline Component Wizard on Codeplex.
Things are quite different in Visual Studio 2010 regarding the creation of guidance packages, but installation is much simpler now. You can just use the extension manager to add the prerequisites and the actual BSF package.
If you’re looking for guidance on installation and usage, I would advise you to use the documentation that accompanies this release.
The bits are on Codeplex.
Please let me know what you think of it!
Didago IT Consultancy
This is more or less a note-to-self because every time I need to write a custom behavior I have to lookup the way to do it. This post should assist me in the future.
A custom behavior is often used to add functionality to the service that basically is not part of the functionality of the service itself like parameter validation. If you put the validation behavior into a separate assembly you can adjust the validation without affecting (and having to re-test) the service. Most of the time writing a custom behavior is not that difficult, it is the configuration that causes trouble. One little mistake and the service refuses to start.
I’m not going to start with explaining what custom behaviors are, because that is described in this excellent MSDN magazine article from 2007 that still applies to WCF 4. If you’re not familiar with this article, I would strongly advise you to read it.
In my sample project I created a sample WCF service on which I want to apply a custom input validation behavior that validates the input based on a regular expression. This regular expression should be adjustable in the web.config of the service.
Behaviors can be applied using attributes in code or via the web.config. Depending on your requirements you need to implement some interfaces. Because I want my behavior to be configurable, I need to implement these interfaces:
- IEndpointBehavior
- this determines the scope of the behavior. Options are IServiceBehavior, IContractBehavior and IOperationBehavior
- IParameterInspector
- this determines where the behavior intercepts the call.
- BehaviorExtensionElement
- this allows a custom configuration element in the web.config
How the IEndpoint behavior and IParameterInspector work or have to be implemented can be found in many blog posts so it will be briefly discussed here. I would like to focus on the way to get configuration from the web.config.
To get information from the web.config into your application or service, there are two options:
- AppSettings section
- Attribute field on the behavior configuration
Because the setting is behavior specific, I’m in favor of the second option. In this way it is clear that the setting has something to do with the behavior. In the end this would result in such a configuration record.
This is implemented using the code of the class overriding BehaviorExtensionElement. In this class you define the attributes that will be part of the configuration.
Here I declared a ‘ConfigurationProperty’ with the name you find in the web.config and I specified that this setting is a string value and is required. If necessary it is also possible to add the ‘default’ element to the ‘ConfigurationProperty’ attribute to set a default value.
Next this value must be stored in the behavior somewhere, to be used later on in the parameter inspector. Remember that the configuration is read during launch of the WCF service, even without having received one client call!
The value is stored the IEndpoint behavior implementation and then passed to the ParameterInspector. In the picture above this is done in the ‘CreateBehavior’ method. The code below shows the Behavior where also the check is done if the configuration setting is actually there.
If no configuration setting is found, running this service would throw an error on start because the attribute is marked as ‘required’. If the value is empty, then the custom exception is thrown:
Also in the IEndpointBehavior picture you can see that the behavior is only a service side (ApplyDispatchBehavior) behavior and is not applied to the client side (ApplyClientBehavior). These methods are used to inject the behavior in the stack.
Finally we end up in the parameter inspector, where the configuration setting actually is used. The configuration value is passed via the constructor and stored there in a private variable.
With all elements in place it is time to finish the configuration. The section below is located in the ‘system.serviceModel’ section.
Important things to remember:
- The name of the extension = name of the behavior! So the ‘InputValidator’ extension is added, and that is the tag name of the behavior.
- The behavior tag is sometimes not recognized by the Visual Studio editor. It is complaining that the behavior has an invalid (=InputValidator) child element and that only some elements are allowed. Ignore this message!
- Make sure the assembly type of the extension overrides ‘BehaviorExtensionElement’.
- If you normally use the SvcConfigEditor tool to edit the web.config regarding WCF configuration, then you might run into issues. The tool at first cannot find the behavior and once you point it to it the tool refuses to accept it. Or at least that is what I experience.
Finally it is time to test the behavior. In the sample project there is a ‘Host’ project. Build the solution and run ‘Host.exe’ as administrator.
Next there is a ‘TestAppSampleService’ which will call the service with a valid and an invalid value. You can step through the client to find out what happens. Also the output is written to the console, which can be picked up by DebugView. This results in these test results:
The sample project can be found here.
Every new version of BizTalk Server deserves its version of the BizTalk Software Factory (BSF). Due to time constraints I was unable to deliver a 2010 version of the BSF last year, but after a couple of weeks work I managed to finish the beta.
Some things have been changed between the BSF 2009 and BSF 2010. First of all nUnit is no longer part of it. It has been replaced by MS Test that is part of Visual Studio. If you want to use nUnit, you can easily change the unit test project to utilize it. Also the installation is different. Microsoft simplified the way (guidance) packages are deployed, so now there is no need to run a MSI anymore. Instead you run the VSIX file and it will show up in the Extension Manager.
The prerequisites for the BSF 2010 are:
Like with any new version of Visual Studio, Microsoft released new versions of the Guidance Automation Extensions (GAX) and Guidance Automation Toolkit (GAT) and these are necessary to run the BSF.
The great thing is that now you can install them via the Visual Studio Extension Manager and you don’t have to download and install them yourself anymore.
First find the Extension Manager in the menu bar of Visual Studio:
Install in this order the SDK, GAX and GAT from the online gallery:
Next install the BSF 2010. Get the VSIX from the BSF Codeplex site. If you double click the VSIX file, the following dialog is displayed:
Just press ‘Install’ and watch the package getting installed. This process is substantially faster than it was with previous versions of GAT/GAX, and that especially handy during development of the package :-)
Now the BSF 2010 has been installed, it shows also up in the Extension Manager where you can remove it again if requested.
Please note that this is a beta version of the BSF 2010. Please give it a try and supply me with feedback so I can create a release version.
WCF bindings describe the set of rules that client and service agree upon in order to communicate. The set of rules to use is determined by the most restrictive of the two. This blog post is meant to assist you in making the right decision.
There are already some good examples on the internet, like this one, but they are limited to WCF 3. To have a customizable drawing available and to extend the drawing with the WCF 4 bindings, I decided to make my own.
Although more aspects determine the exact binding, it is my experience that in about 90% of the cases there are basically 2 questions you need to answer:
- Is it an intranet or an internet facing service?
- Do you need to support legacy clients or not?
For intranet scenarios you’ll end up with the netTcpBinding most of the time. If you need to support legacy clients then the only alternative is basicHttpBinding, otherwise wsHttpBinding is what you need.
The bindings in this diagram are the default bindings. If you want to customize for example the basicHttpBinding to be secure, then you actually create a custom binding based on a default binding. If you change things like that you need to have the bindings configuration in the web.config, which can be omitted if you go for the default binding.
On MSDN there is a great resource with information about the so called system provided bindings. The table below is also taken from there.
| Binding | Inter operability | Mode of Security (Default) | Session (Default) | Trans actions | Duplex |
| BasicHttpBinding | Basic Profile 1.1 | (None), Transport, Message, Mixed | None, (None) | (None) | n/a |
| WSHttpBinding | WS | None, Transport, (Message), Mixed | (None), Transport, Reliable Session | (None), Yes | n/a |
| WS2007HttpBinding | WS-Security, WS-Trust, WS-SecureConversation, WS-SecurityPolicy | None, Transport, (Message), Mixed | (None), Transport, Reliable Session | (None), Yes | n/a |
| WSDualHttpBinding | WS | None, (Message) | (Reliable Session) | (None), Yes | Yes |
| WSFederationHttp Binding | WS-Federation | None, (Message), Mixed | (None), Reliable Session | (None), Yes | No |
| WS2007FederationHttp Binding | WS-Federation | None, (Message), Mixed | (None), Reliable Session | (None), Yes | No |
| NetTcpBinding | .NET | None, (Transport), Message, Mixed | Reliable Session, (Transport) | (None), Yes | Yes |
| NetNamedPipeBinding | .NET | None, (Transport) | None, (Transport) | (None), Yes | Yes |
| NetMsmqBinding | .NET | None, Message, (Transport), Both | (None) | (None), Yes | No |
| NetPeerTcpBinding | Peer | None, Message, (Transport), Mixed | (None) | (None) | Yes |
| MsmqIntegration Binding | MSMQ | None, (Transport) | (None) | (None), Yes | n/a |
With the release of the new version of BizTalk Server, it is time to build a new virtual environment to play with.
I have a quad core server with 12 Gb memory at my disposal for this purpose so I’m ready to create a Hyper-V image.
The first step is install the basics, in my case:
- Windows Server 2008 R2 Standard Edition
- SQL Server 2008 R2 Developer Edition
- SQL Server 2005 Notification Services
- Visual Studio 2010 Ultimate Edition
- SharePoint Foundation 2010
- Office 2010
Next, get the install files for:
If you download the BizTalk Server 2010 Developer Edition, you’ll have a packed executable. When unpacked, it is expanded into 10060(!) files. The files are split up into two folders with:
- BizTalk Server 2010 Installation files, including:
- Adapter Pack (Oracle, SAP, Siebel, SQL)
- UDDI
- RFID
- AppFabric Connect
- BizTalk Server 2010 Accelerator files, including:
The prerequisites CAB file that is so familiar to BizTalk installations is mentioned in the documentation and is not enclosed in the installation files.
Installation and configuration of BizTalk Server 2010 are basically nothing new. However if you don’t follow the installation guide, you might run into configuration errors. One issue I ran into was that I forgot to set IIS to native 64-bit mode. This is also missing in the installation guide. You can use the following statements for this:
- cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
- C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727>aspnet_iisreg -i
This is one area where BizTalk still can be improved, because the error log text file is hard to read and understand. One thing the team did add to the documentation is a “troubleshooting” document.
Next, installation of the LOB Adapters which is an option on the setup screen of the main BizTalk setup. Just follow the steps:
- Install Microsoft WCF LOB Adapter SDK
- Install Microsoft BizTalk Adapter Pack
- Install Microsoft BizTalk Adapter Pack(x64)
- Install Microsoft BizTalk Adapters for Enterprise Applications
When BizTalk and the adapter pack are installed, then also the new AppFabric Connect is installed.
Next, the ESB Toolkit 2.1. This is just a matter of running the correct MSI. The installation documentation specifies the pre-requisites.
The ESB Toolkit 2.1 must be configured using the ESB Configuration tool, that can be found in the start menu after the toolkit is installed. There you can configure the ESB Exception and Itinerary database and services you want to use. Before you can configure the services, you first need to apply the database configuration. Finally you need to specify the type of configuration to use, File or SSO. For single server installations File is recommended, SSO is more suitable for multi server installations.
Next the individual components of the ESB Toolkit 2.1 can be deployed into BizTalk. In the ProgramFiles folder there is a Microsoft BizTalk ESB Toolkit 2.1 folder with the necessary MSI installer files that can be imported into BizTalk.
There is quite an installation document for the ESB Toolkit 2.1 you can follow. This document contains some catches like the samples depend on the fixed path “C:\Projects\Microsoft.Practices.ESB” and a call to ServiceModelReg with a not existing parameter “-y”.
The ESB portal is in the ESB Sources that can be found in the ESB Toolkit 2.1 folder. I had some difficulties setting up the ESB Portal, because the SharePoint Foundation 2010 site was in its way so I had to change the port number of the default website. The portal still runs on .NET 3.5 instead of v4.0. and I assume that not much has changed on the portal, also because the assembly info for the portal mentions “Microsoft ESB Guidance for Microsoft BizTalk 2006 R2” and the UDDI code file contains an obsolete call to the configuration namespace. The UI also looks the same.
Finally installation of AppFabric. Default the hosting services are selected but I also want the caching services to be installed. Installation is a matter of waiting and the configuration is also straight forward.
Now I have a (virtual) base image to do some BizTalk 2010 testing on. :-)
Today the long awaited release date of the 7th version of BizTalk Server was announced: October 1st, 2010
For this announcement Microsoft refreshed its BizTalk website. There you can already download the 120-day trial version. What’s interesting and new with this release is the free developer edition which was also already released. In previous BizTalk versions the developer edition cost around $500.
On the product team blog there is a nice post about the upcoming release.
Enjoy!
Via a blog post it came to my attention that the BizTalk user groups of Australia and New Zealand organise a combined event around BizTalk Server 2010. It is called BizTalk Saturday. It looks like a very nice event, so if your in the neighbourhood you should attend.
One of the presentations I found scheduled is about the ESB Toolkit 2.1. Off course I know about the ESB Toolkit 2.0, but 2.1 hasn't had so much attention yet.
It is a release especially for the platforms supported with BizTalk Server 2010 like Visual Studio 2010. Information can be found here.
So, what is new in this release? From the Microsoft site:
The Microsoft BizTalk ESB Toolkit 2.1 extends the capabilities of BizTalk Server 2010. The following list summarizes the additional support extended in Microsoft BizTalk ESB Toolkit 2.1:
- Added support for Visual Studio 2010 Visualization and Modeling SDK for the Itinerary designer.
- Support both .NET Framework version 4 and .NET Framework 3.5.
- Supports the use of itineraries developed in Microsoft BizTalk ESB Toolkit 2.0.
- The Itinerary designer now supports copying and pasting itinerary shapes.
- A new itinerary project template, BizTalk ESB Itinerary designer, provides an easy option to create itinerary projects under BizTalk Projects.
- Opening a new project in the Itinerary designer sets the export mode to Strict by default.
- Added a new itinerary model property, Require encryption certificate, in the Itinerary designer to enable and disable encryption certificate while validating the itinerary. This flag is set to True by default.
The picture below shows the ESB Toolkit 2.1 core engine components. Although I haven't spend a lot of time on this release yet, one thing that caught my eye was the mentioning of Enterprise Library 4.0 while Enterprise Library 5 has been released for some months. Also the UDDI 2.0 is in the picture, while the toolkit requires UDDI 3.0 according to this documentation.
.gif)
So althought the ESB Toolkit 2.1 download isn't mentioned as a beta download (while BizTalk 2010 is), the documentation is marked as prerelease and inconsistent in some places.
One of the major differences between SQL Server 2008 and the R2 version is Master Data Services or MDS. Microsoft has added this feature to give users the ability to centrally store and manage master data.
But what is ‘master data’ exactly?
Master data is the data that is supposed to be uniquely available within an organization. Examples are:
- Geographical information
- Product information
- Customer information
It is typically data of which you want to have just a single source of truth. In a lot of companies this information is stored in several databases and locations. This is very risky because changes to that data might not be available to all employees. However it is not only about a single source of information but also about versioning and managing this important information.
Master data services is supposed to solve this.
Microsoft didn’t build this feature from scratch but acquired Stratature in June 2007 for that. It was code named ‘Bulldog’ and the first preview with MDS was released back in November as a CTP, but the RTM was released in May this year.
Prerequisites for MDS are similar to SQL Server 2008 R2, but for MDS also the IIS role is necessary because the MDS manager is an ASP.NET application. The full prerequisites regarding IIS can be found here.
When you start the SQL Server 2008 R2 installation you won’t see anything about MDS, because it is a separate install. So first start the regular installation of SQL Server 2008 R2.
Next, you can find the MSI of MDS in a separate folder on the installation disk.
Run the MSI to install MDS. After installation the configuration is launched. This configuration checks if the prerequisites are met. If that is not the case, close the configuration and install the missing pieces. From the start menu you can launch the configuration manager again.
Next step is to create and configure the databases.
MDS requires a database to support the MDS manager web application and web services. Click ‘Create Database’ and the wizard is launched.
Specify the Database server and instance to use.
Specify the name of the database to create.
Specify the service account, which will be used by the web application and services to connect to the database.
Specify the administrator account. Take note of the small remark: “You can configure only one account with this permission and cannot change this account later”
Last screen is the summary and the creation and configuration process can start. If everything went ok then the following screen is shown.
If you click finish you’ll close the dialog and return to the main configuration screen. Before configuration the system settings were empty but they are filled in now. You can adjust the settings to your needs.
One of the options is to create a database mail profile so the system can send alerts.
Next step is the Web configuration:
With a clean install you can only select the ‘Default Website’, but if you do that the message “This Web site has no Master Data Services application” shows up. To solve this you can create an application in the default web site or create a new site. I decided to create an application.
With the web application in place, you can select the database to use. This typically is the database that you’ve created previously in the create database wizard.
With this set up, the configuration looks like this.
Click ‘Apply’ to apply the configuration and a confirmation message shows up.
After logging on the ‘Getting started’ page of the web application is displayed. This page gives the opportunity to deploy some sample models and data to be able to play a bit with MDS. The application itself looks like this.
Now MDS is installed and configured and ready to be used.
I’m involved in some EF 4 development now and I ran into an error I couldn’t understand. Fortunately I wasn’t the first to experience this so it could be solved. However this is an example of an error description that could have been clearer.
The error was:
“Cannot convert lambda expression to type 'string' because it is not a delegate type”
The solution was:
Add the System.Linq using statement to the code……
I found the solution here.
More Posts
Next page »