Hi All,
We have been attending BTS 2006 R2 webcasts for the last few weeksand going through what we have been watching, R2 is definitely the next big thing in BizTalk Server World. Unfortunately, most of them are NDA andhence i wont be able to share the information with you all. However, you can get more […]
Hi All,
As you are aware, a new version of SQL Server named “Katmai”is going to be released soon from Microsoft ….Microsoft gives a peek of this version of SQL Server at a business conference.
Read about this and more from here:
http://www.informationweek.com/software/showArticle.jhtml?articleID=199500164&subSection=Development
and http://www.microsoft.com/sql/prodinfo/futureversion/default.mspx
Enjoy!
Well, its groundbreaking and earth shattering, if you’re either Me or if you care in any way about my career. That of course limits the impact of this news to about 4 people, all of which are closely related to me (and none of which read this blog).
However, as of today I am now a “Consultant”. I have justhad my first day in Microsoft Consulting Services as a BizTalk Consultant. So far it feels the same as being an Engineer so maybe they forgot to give me myupgrade to my social/influencing skills. Also they seem to have forgotten to retrieve from me my hardcore geek, brain upgrade kit that I had from my last job.
Anyway needless to say I’m “super excited” to be starting this new job although a little sad to be leaving my old team. But life goes on right?
So if you’re either of my loyal blog readers and you need a BizTalk operations consultant, I’m now OPEN FOR BUSINESS.
Mark
So I’m wiped…. my first day of TechEd behind me and Party with Palermo complete.
It was a great day, particularly the Pre-Conference training I attended by Jon Flanders
of Pluralsight and Richard B. of DevelopMentor.
I learned quite a bit, I already had alot of the basics down, but the more advanced
look into what WF could do was great. In particular I hadn’t learned anything
about Dynamic Change or custom services prior to this class.
Jon and Richard did a great job, and I’m glad I’ve planned to attend most of Jon’s
session for the rest of the week.
I arrived in Orlando yesterday after a long old flight from London and should make the Party with Palermo tonight which looks like it’ll be fun but as I’m presenting tomorrow it’ll be a quiet night!
My two sessions are shown below, the second session being a very informal chalk/talk style session without any slides so if you want to know more about BizTalk Performance & Scalablity testing or have some questions, come along!
A book signing has been organised at the TechEd bookstore following my session on Monday, come along between 1815 and 1845 and Ewan and I will be signing copies!
My sessions this week are:
SOA306 – Building an Enterprise-Wide Instrumentation Solution Using the Microsoft BizTalk BAM Infrastructure
Monday 4th June: 1645 to 1800
Track(s): SOA and Web Services
Level: 300
Speaker(s): Darren Jefford
Business Activity Monitoring (BAM) is a powerful feature of BizTalk Server and is often marketed as allowing “the business” to understand what is happening within your BizTalk solution. BAM does this really well, but it can in fact be used in a variety of other ways which can deliver huge value to customers and address a number of issues they have with BizTalk based solutions and non-BizTalk based solutions.
In this session, we cover some of the fundamentals of BAM and detail how you can utilize BAM to collect a variety of information and produce a “tracking portal” which you can use to support your application, perform manual repair of messages, and generally observe your solution.
We also show how BAM is not just for BizTalk solutions and how it can be used to produce an enterprise-wide instrumentation solution that is highly scalable and flexible; we touch on the new Windows Workflow Foundation and Windows Communication Foundation (WCF) BAM Interceptor technology that enables data to be collected from Workflows and WCF services enabling a true end-to-end instrumentation solution.
SOA13-TLC – Microsoft BizTalk Performance Testing
Thursday 7th June: 1630 to 1745
Track(s): SOA and Web Services
Level: 400
Speaker(s): Darren Jefford
Testing is a critical area for any solution and BizTalk is no exception. In this session, we start by covering the foundations that you need to put into place before beginning any performance testing, covering the most common environment problems that cause problems during testing and highlighting a number of tools to make testing easier including BizUnit and LoadGen.
Then, we cover how you should monitor your solution during testing; highlighting the key performance counters that should be monitored and explaining how throttling works. We finish by covering a number of common symptoms that you’re likely to experience during testing; we explain why these occur, how to spot them, and more importantly how to resolve them.
I came across a good explaination recently from Joel.
Snip….(from Joel’s blog – see his for more details)
Next, what prescan is looking for…
I arrived in Orlando yesterday after a long old flight from London and should make the Party with Palermo tonight which looks like it’ll be fun but as I’m presenting tomorrow it’ll be a quiet night!
My two sessions are shown below, the second session being a very informal chalk/talk style session without any slides so if you want to know more about BizTalk Performance & Scalablity testing or have some questions, come along!
A book signing has been organised at the TechEd bookstore following my session on Monday, come along between 1815 and 1845 and Ewan and I will be signing copies!
My sessions this week are:
SOA306 – Building an Enterprise-Wide Instrumentation Solution Using the Microsoft BizTalk BAM Infrastructure
Monday 4th June: 1645 to 1800
Track(s): SOA and Web Services
Level: 300
Speaker(s): Darren Jefford
Business Activity Monitoring (BAM) is a powerful feature of BizTalk Server and is often marketed as allowing “the business” to understand what is happening within your BizTalk solution. BAM does this really well, but it can in fact be used in a variety of other ways which can deliver huge value to customers and address a number of issues they have with BizTalk based solutions and non-BizTalk based solutions.
In this session, we cover some of the fundamentals of BAM and detail how you can utilize BAM to collect a variety of information and produce a “tracking portal” which you can use to support your application, perform manual repair of messages, and generally observe your solution.
We also show how BAM is not just for BizTalk solutions and how it can be used to produce an enterprise-wide instrumentation solution that is highly scalable and flexible; we touch on the new Windows Workflow Foundation and Windows Communication Foundation (WCF) BAM Interceptor technology that enables data to be collected from Workflows and WCF services enabling a true end-to-end instrumentation solution.
SOA13-TLC – Microsoft BizTalk Performance Testing
Thursday 7th June: 1630 to 1745
Track(s): SOA and Web Services
Level: 400
Speaker(s): Darren Jefford
Testing is a critical area for any solution and BizTalk is no exception. In this session, we start by covering the foundations that you need to put into place before beginning any performance testing, covering the most common environment problems that cause problems during testing and highlighting a number of tools to make testing easier including BizUnit and LoadGen.
Then, we cover how you should monitor your solution during testing; highlighting the key performance counters that should be monitored and explaining how throttling works. We finish by covering a number of common symptoms that you’re likely to experience during testing; we explain why these occur, how to spot them, and more importantly how to resolve them.
These are the slides and demos from my Tech Ed Session from Tech Ed 2007 in Orlando.
The demos show Dynamic Mapping, Self-Correlation Ports, Untyped Messages, and WCF Calls in Messaging. The WCF demos will require BizTalk Server R2. These demos are “as is” and may need some configuration changes to work on your system.
PowerPoint 2007 is required to view the slides.
Session Abstract:
“Business processes are a required component in most Enterprise Integration solutions today. Business processes are modeled, designed, and built inside BizTalk Server 2006 R2 using Orchestrations. Orchestration can range from a few simple shapes to a complex multi Orchestration, Transactional process. This session focuses on highlighting key Orchestration features to shorten development time and increase overall Business Process reusability. Also, messaging-only scenarios using WCF are discussed, and the power of BizTalk as a Web service routing system is shown. Topics covers are: Untyped Messages, Dynamic Transforms, Starting Orchestration and Passing Port Parameters, using Helper .NET Components, and Message Only WCF Calls.“
As we all know BizTalk provides two core functionalities, the Message engine which is responsible for routing messages and the Orchestration engine which provides the execution environment for processing Orchestrations. Messaging ports, are BizTalk’s connection to the outside word and are generally created and managed by BizTalk Administrators however the orchestration ports are created by developers. When creating new ports in orchestrations we are presented with three choices for receive ports. Send ports have a fourth option. The choices that we make in creating orchestrations have a profound effect on the performance and the flexibility of our processes, thus making the right choice is a pretty big decision.
Most organizations are making BizTalk a central part of their Service Oriented Architecture (SOA) environment, as well they should. One of the tenants of SOA dictates that loose coupling is important. Some of the port binding options are better than other in this regard. Let’s evaluate each of these options.
Specify Now – This port binding is frequently referred to as early bound. The principal benefit of early binding is that the process of creating the physical (messaging) port happens when the assembly containing the orchestration is deployed thus avoiding the extra step of port creation. Of the binding choices this is the most tightly coupled and therefore from an SOA perspective the weakest choice. Although changes to these ports can be made after deployment, (for that matter they can even be totally replaced), when redeployment occurs the ports will be recreated as originally configured and may conflict with the existing ports. Early bound ports should probably only be used for “quick-and-dirty” testing scenarios while in development and will have limited application in production.
Specify Later – In scenarios where the developer knows in advance that communication outside of BizTalk, to a queue, another application, or a database is required, late bound ports provide a better option over early bound ports. When using late bound ports the boundary between implementation and instrumentation is maintained. The developer defines only the communication pattern, one or two way while its left to the administrator to configure the physical port for endpoint communication. This option while more loosely coupled still assumes prior knowledge of how the component (orchestration) is to be used. This would be a poor choice if for example I want to send a message to another orchestration as it will requires I/O to an external location.
Dynamic – Only available for send ports, dynamic ports allow developers the flexibility to define within the orchestration how a port is to be configured on a per instance basis. This can be useful in scenarios where you wish to send a message in some cases to an ftp site or in other cases to an email address using the same logical port. Hard coding this decision into an orchestration may be a poor design choice, but using the Business Rule Engine can provide flexibility in this design. Although it requires additional planning a better option in these situations would frequently be using role-links.
Direct – Our final port choice is the most loosely coupled and most flexible, though it can be difficult to use correctly. When selecting direct-bound ports three options are available, orchestration to orchestration, self-correlating, and direct bound to the message box. From an SOA perspective ports directly bound to the message box are often the “best” choice. When orchestration ports are direct bound, there no need to provide a binding to the a physical port. It is still necessary to create the physical port, but these ports simply deliver the message to the Message box. The messaging engine uses the correlation set(s) or filter defined on the receive shape along with the message type to determine the subscription. This design allows for flexibility in design since there is no explicit coupling between the logical and physical ports. Care should be taken when choosing direct bound ports as it is very easy to get into a endless loop situation. Coincidentally this design also supports some of the other SOA tenants such as contract first and explicit boundaries.
I hope that this review of the various port binding options and a discussion of the various benefits of each, (SOA speaking at least) will assist you as you endeavor to create your BizTalk based SOA solutions.
The opinions expressed in this article reflect those of the author in his experience as a BizTalk consultant and trainer.
As we all know BizTalk provides two core functionalities, the Message engine which is responsible for routing messages and the Orchestration engine which provides the execution environment for processing Orchestrations. Messaging ports, are BizTalk’s connection to the outside word and are generally created and managed by BizTalk Administrators however the orchestration ports are created by developers. When creating new ports in orchestrations we are presented with three choices for receive ports. Send ports have a fourth option. The choices that we make in creating orchestrations have a profound effect on the performance and the flexibility of our processes, thus making the right choice is a pretty big decision.
Most organizations are making BizTalk a central part of their Service Oriented Architecture (SOA) environment, as well they should. One of the tenants of SOA dictates that loose coupling is important. Some of the port binding options are better than other in this regard. Let’s evaluate each of these options.
Specify Now – This port binding is frequently referred to as early bound. The principal benefit of early binding is that the process of creating the physical (messaging) port happens when the assembly containing the orchestration is deployed thus avoiding the extra step of port creation. Of the binding choices this is the most tightly coupled and therefore from an SOA perspective the weakest choice. Although changes to these ports can be made after deployment, (for that matter they can even be totally replaced), when redeployment occurs the ports will be recreated as originally configured and may conflict with the existing ports. Early bound ports should probably only be used for “quick-and-dirty” testing scenarios while in development and will have limited application in production.
Specify Later – In scenarios where the developer knows in advance that communication outside of BizTalk, to a queue, another application, or a database is required, late bound ports provide a better option over early bound ports. When using late bound ports the boundary between implementation and instrumentation is maintained. The developer defines only the communication pattern, one or two way while its left to the administrator to configure the physical port for endpoint communication. This option while more loosely coupled still assumes prior knowledge of how the component (orchestration) is to be used. This would be a poor choice if for example I want to send a message to another orchestration as it will requires I/O to an external location.
Dynamic – Only available for send ports, dynamic ports allow developers the flexibility to define within the orchestration how a port is to be configured on a per instance basis. This can be useful in scenarios where you wish to send a message in some cases to an ftp site or in other cases to an email address using the same logical port. Hard coding this decision into an orchestration may be a poor design choice, but using the Business Rule Engine can provide flexibility in this design. Although it requires additional planning a better option in these situations would frequently be using role-links.
Direct – Our final port choice is the most loosely coupled and most flexible, though it can be difficult to use correctly. When selecting direct-bound ports three options are available, orchestration to orchestration, self-correlating, and direct bound to the message box. From an SOA perspective ports directly bound to the message box are often the “best” choice. When orchestration ports are direct bound, there no need to provide a binding to the a physical port. It is still necessary to create the physical port, but these ports simply deliver the message to the Message box. The messaging engine uses the correlation set(s) or filter defined on the receive shape along with the message type to determine the subscription. This design allows for flexibility in design since there is no explicit coupling between the logical and physical ports. Care should be taken when choosing direct bound ports as it is very easy to get into a endless loop situation. Coincidentally this design also supports some of the other SOA tenants such as contract first and explicit boundaries.
I hope that this review of the various port binding options and a discussion of the various benefits of each, (SOA speaking at least) will assist you as you endeavor to create your BizTalk based SOA solutions.
The opinions expressed in this article reflect those of the author in his experience as a BizTalk consultant and trainer.