Here’s the background: I love using fully qualified domain names (FQDN) for my IIS sites when doing some sweet EPiServer-development. Like this: local.<customer>.website.
Like so in…
Daniel Berg’s blog about ASP.NET, EPiServer, SharePoint, BizTalk
Well some people are still not convinced BizTalk is here to stay, today some very nice information popped up in bloglines (my favorite RSS reader) about the futur of BizTalk. Almost every new technology MS has released are mentioned, to name a few: WCF…(read more)
The big seven factors that often come about when negotiating an SLA with a cloud provider are:
Privileged User Access
– Know as much as you can about those who touch your data
Regulatory Compliance
– Ensure the provider is willing to undergo an audit
Data Location
– Ensure legal privacy standards are upheld by location
Data Segregation
– Identify the need for encryption, or providing some separation of your data from the data of others in the cloud
Recovery
– Ascertain what will happen when the service or data is unavailable, and how long a complete restore will take
Investigative Support
– What capabilities and support does the provider offer to investigate illegal activities
Long-term viability
– What happens if the provider is acquired
In the instance of multiple datacenters, however, it’s oftentimes unclear as to exactly where your data resides, and the privacy standards set forth by the cloud provider.
Microsoft has just released a whitepaper titled Privacy in the Cloud Computing Era. In it Microsoft sets forth ten guiding privacy principles by which policies surrounding privacy in the cloud are directed. The whitepaper also addresses legal and regulatory issues as part of Microsoft’s foray into Cloud Computing.
The whitepaper may be found here.
If you have been wondering why we have been quiet for so long – well we have been busy lately and for a good reason – within a week from now we are going to present some very exciting sessions and demos at the Professional Developers Conference in LA.
The first session will provide a sneak peak to BizTalk’s future with a demo of some cool innovations that will dramatically enhance BizTalk developer productivity and will make BizTalk more appealing to .NET developers using WF and WCF technologies.
Following are the details of the BizTalk sessions:
Speaker: Balasubramanian Sriram in 502A on Tuesday at 3:00 PM
Abstract: Learn how BizTalk Server 2009 lets you focus on writing the code to do the hardcore business logic and let BizTalk take care of moving the data. Hear how your development skills with Windows Communication Foundation (WCF), and Windows Workflow Foundation (WF) work seamlessly with the powerful integration platform of BizTalk. Find out how BizTalk aligns with the Microsoft application server in the longer term.
Session title: Connecting Applications with the Microsoft BizTalk Enterprise Service Bus
Speakers: Syed Rasheed, Dmitri Ossipov in 515B on Tuesday at 4:30 PM
Abstract: See how the BizTalk Enterprise Service Bus (ESB) enables you to build services that can be quickly located and connected, whether they live behind the firewall or in the cloud, without creating a brittle point-to-point link. Learn how to dramatically improve the service lifecycle of development, testing, and deployment by using the powerful messaging, routing, and transformation capabilities of the BizTalk ESB in your solution today, and get a glimpse of future plans for BizTalk service bus/pub-sub pattern.
Additionally we will host the following interesting chalk talk:
Title: BizTalk and StreamInsight: A Better Together Story (Session 3 – Theatre Chalk Talk on Tuesday at 1:00 pm)
Speaker: Mark Simms
Abstract: SQL Server 2008 R2 introduces StreamInsight, providing a powerful platform for developing and deploying complex event processing (CEP) applications. Come and learn how StreamInsight can be used to enable new capabilities in BizTalk for providing real-time monitoring and analytics for infrastructure and business events at scale.
Also at PDC we are hosting the following two BizTalk labs:
Last but not least stop by the BizTalk demo booth in the Microsoft Products Pavilion if you want to chat with members of the BizTalk product team and other BizTalk experts. We will be presenting cool demos and would love to help you figure out how to leverage the most of BizTalk Server regardless of your level of knowledge of the product.
You can also meet us at the “Ask the Experts” session on Wednesday 5:30 – 7:00 PM.
See you next week,
The BizTalk team.
Everyone knows (read that as: should know 😉 that enabling the BizTalk jobs “Backup BizTalk Server” and “DTA Purge and Archive” is a good thing. Even on simple test machines, and perhaps (preferably) even on your developer laptop. What happens some times though is that, when you end up using the dump-to-disk approach, you fill up your disks. This happens because by default the BizTalk Backup and DTA Purge and Archive jobs doesn’t clean house. In your production and staging environments the “IT guys” will usually have your back in this case and make sure that doesn’t happen. For those environment where that isn’t the case here’s an easy to use script provided by our IT guys to help keep things tidy. It uses the forfiles statement as the bulk of its logic.
@echo offset BACKUP_PATH=%1set RET_INTERVAL=%2if "%BACKUP_PATH%"=="" exit 1if "%RET_INTERVAL%"=="" exit 1Forfiles /P %BACKUP_PATH% /S /M *.BAK /D -%RET_INTERVAL% /C "cmd /C Del @path"exit %ERRORLEVEL%Now all you need to do is to call this script from somewhere. A suggestion might be from a SQL job. This way you configure the backup and the cleanup of the backup files from a single location. Like this:
exec xp_cmdshell 'script.cmd C:\Backup 4'script.cmd should be the full path to your script, while C:\Backup should be the full path to your backup directory. Remember to surround paths by “ should they contain spaces. The 4 in this case says that any files 4 days and older will be removed. Schedule as you see fit.
For people interested in both PowerShell and BizTalk, I just finished a getting started guide to introduce the basics of the PowerShell provider for BizTalk (version 1.0 beta). The guide can be downloaded from here.
Tagged: BizTalk, BizTalk Management, BizTalk tools, PowerShell 
I’m not surprised at all about this announcement from Doug Purdy about the changes coming to the “Oslo” tools. Ever since the Connected Systems group was “merged” with the data group, it seemed a foregone conclusion that the modeling work would begin to heavily focus on the Microsoft data stack. I’ll wait to see how the tools evolve before making an opinion about their usefulness. I’m actually optimistic that in the end, more Microsoft developers will be better off as the tools will be more likely to help them in their everyday development. As it was, the M language and associated tools seemed to be targeting a niche market of language developers. Looking forward to PDC and hearing all about how these new tools are going to help me model my application data and hopefully help build up a good deal of the infrastructure for my data access layer.
I like to divide BizTalk based integrations into three different patterns.
Point-to-point integration
Broker-based integration
ESB-based integration
I am sure someone could come up with fancier names but I will in this post try and dig into each of them, explain what I mean by them. I will also try and highlight some issues with each of the patterns.
This is where a lot of us started. The idea is that the sending system has information and knowledge about the receiving system.
This usually means that the messages are exported in a message format that is tailored to the format of the particular receiving system’s needs. It also means that we usually get one integration process for each receiving system there is.
The example in the figure on the right shows a sending system that sends information about invoices to two different receiving systems (“System A” and “System B”). Using a point-to-point pattern in this scenario we end up with two different types of messages that are exported. Each of the exported messages that are suited and tailored to the format of the receiving system.
The main problem with this kind of point-to-point integration, where the sending system has detailed knowledge about the receiving systems, is that this knowledge translates into a coupling between the systems. When we tie the export message format from the sending system to the format of the receiving, all changes in the receiving system will also cause changes in the sending system.
Suppose there is a sudden need to change the format of the receiving system – as we use that format as our export format we now also have to change it there.
Another problem is the lack of agility. In this invoice scenario all other system that also has the need of invoice based information has to get this by going all the way back to the sending system and develop a whole new specific integration – separate to the existing ones.
In the broker-based scenario the integration platform is used as a broker of messages.
This means that only one canonical format is exported from the sending system. The broker then handles the routing to the different systems and the transformation to the message formats that the receiving systems expects.
The main advantage between this approach – where the sending system do not know anything about the receiving systems – and the point-to-point pattern is agility.
If there now is a need for invoice information in a third, new system, we do not have to change the export from the sending system (as long as we have all the information need that is) or develop a whole new integration. All we have to do is to route the invoices so that they also are sent to the third system and transformed into the format that the system expects. A new BizTalk map and port and we are done!
In my point of view this approach to integration has a lot of advantages over the point-to-point integrations previously discussed. And in a lot of simpler, stabile scenarios it works just fine and is the way to go.
But in some scenarios it kind of breaks down and becomes hard to work with. The problems is related to configuration and how we define the routing information in BizTalk. In BizTalk we can either create an orchestration and “hardcode” the process that defines which systems the messages should be sent to. We can also create a “messaging” scenario where we configure this routing information in the different BizTalk port artifacts by setting up filters.
Regardless if we choose a “messaging” or orchestration based solution the routing information becomes hard to update as the solution grow in size. We either get very complicated orchestrations or loads of ports to maintain.
Furthermore the whole process is very coupled to the one canonical schema which makes versioning and updates hard. If the canonical schema needs to be updated and we still need to be able to send information using the old schema (so we have a “version 1” and “version 2” of the schema side-by-side) all artifacts needs to be more or less duplicated and the complexity of the solutions grows fast.
This makes business agility hard and any changes takes long time to develop and deploy correctly.
I guess these issues has more to do with how BizTalk works than the integration pattern itself – but this is a BizTalk blog!
ESB-based integration in BizTalk is today achieved using ESB Toolkit from Microsoft.
One of the ideas of ESB-based integration is that the integration platform should not have hardcoded routing information. These routing rules should either be looked up at run time or travel with the actual payload of the message (called “dynamic routing”).
This in combination with having generic on- and off-ramps instead of loads of separate ports to maintain promises to create more agile and configurable solutions (called “Loosely coupled service composition” and “Endpoint run-time discovery and virtualization”).
The figure again shows the invoice scenario used previously. In this case we export a “Invoice 1.0”-format from the sending system. The format is not directly bound to a schema in the port (as we are used to in BizTalk) but it is basically possible to send any message format to the on-ramp.
The on-ramp then identifies what kind of message it received (for example using the XML-namespace) and looks up the routing rules for that specific message (the message “itinerary”) in a repository.
In this scenario there could be rules to route the message to a orchestration or directly to a send port. _All the configuration for this port is however configured as part of the itinerary and applied at run-time on the generic off-ramp port. And as itineraries are simple XML documents they are super light to update and deploy in the repository! _
So if we now wanted to update the “Invoice”-format to “version 2.0” all we would have to do is to create a new XML itinerary for the “Invoice 2.0” message type and possibly create new orchestration to handle the new message type. No new ports, no new bindings etc, etc. The configuration and deployment would be a lot simpler than before! We would end up with a lot fewer artifacts to maintain.
And the itinerary for “Invoice 1.0” would still be applied to all incoming Invoice 1.0 messages. Thus we have achieved what used to be so hard with a lot less development power!
With agility and dynamic capabilities comes complexity in debugging when something bad happens … I also feel that we give up a lot of validating and control capabilities that we had in the more schema-coupled patterns previously discussed.
I am new to this ESB-based model and I would love to hear your experiences, problems, stories etc!
I am however sure that this is the way to go and I would not be surprised if ESB like patterns will play an ever bigger role in future BizTalk versions!
SQL Server Management Studio now has support for SQL Azure. The download is now available on MSDN at
http://blogs.msdn.com/ssds/archive/2009/11/10/9920168.aspx