Dallas TechFest 2010 Registration Is Open

by | May 25, 2010 | BizTalk Community Blogs via Syndication

I’m thrilled to announce that registration is open for Dallas TechFest 2010 at http://dallastechfest.eventbrite.com

Who is speaking you ask?  Well our incredible team of web volunteers are hard at work on a refresh of our website, but in the meantime, here are some names and topics from the .NET Track:

  • ASP.NET MVC 2 and Azure Table Storage – Chander Dhall
  • Particle Physics Engine in Silverlight and ASP-mvc?! – Amir Rajan
  • The Rich Standard: Getting Familiar with HTML 5 – Todd Anglin
  • Hard Lessons Learned From Being Stupid About TDD – Matt Hinze
  • Intro To Generics 0 to 60 – Devlin Liles
  • M-V-V-M in Silverlight 4 – Caleb Jenkins
  • Unit Testing SharePoint using TypeMock – Kyle Kelin
  • 10 Practices every developer should start right now – Caleb Jenkins
  • Monotouch for the iPhone – Casey Watson
  • Dropping ACID: Building Scalable Systems That Work – Chris Patterson

 

Silverlight, SharePoint, iPhone, HTML5, as you can see we’ve got a packed schedule of .NET goodness and that’s not to mention the Flex, ColdFusion, PHP, and Java tracks!

IIS Hosted WCF Services using AppFabric Service Bus

by | May 25, 2010 | BizTalk Community Blogs via Syndication

Through a number of customer engagements we’ve heard time and again how extending current SOA investments to the cloud, through the use of Windows Azure AppFabric, has been transformative for our customer’s businesses.

Customers have accrued value in many areas, but one theme that gets repeated over and over again is taking current back-end systems and connecting those systems to AppFabric Service Bus. 

Whether companies are extending high-value on-premises systems to the cloud for mobile workforce access or partner access, AppFabric Service Bus, coupled with AppFabric Access Control, has allowed these customers to extend the life of their systems with new cloud-enabled scenarios.  The really interesting part here is that these customers have been able to cloud-enable existing systems without the cost and risk of rewriting and hosting them in the cloud. 

In cases where customers are aggressively moving their software assets to the cloud, they too have leveraged the connectivity provided by Windows Azure AppFabric to keep their Tier 1 applications running in their own datacenters.  With AppFabric, they are able to maintain control of these business critical systems, letting them run in their own datacenter(s), managed by their own IT staff, but cloud-enable them through AppFabric.

In an effort to further cloud-enable existing systems, one of our team members wrote a whitepaper that shows how to take WCF services hosted in IIS 7.5 and connect them up to the AppFabric Service Bus. This has been a frequently requested feature, so we’re excited to get this whitepaper out.

If you have WCF services hosted in IIS 7.5 and want to connect them to the cloud, this whitepaper will show you how to enable that scenario.

Thanks.

The Windows Azure platform AppFabric Team.

Downloads from the BizTalk Performance meeting at the Swedish BizTalk User Group

by | May 25, 2010 | BizTalk Community Blogs via Syndication

Thanks to everyone attending the BizTalk Performance talk at the Swedish User Group, last week. The webcasts are ready and will be posted on DevCenter shortly.

The downloads includes presentations and scripts used in the first talk. It also includes the Streaming and Large Message Transmission demo from the second talk. I did not include the Transformation demo, as you download that from Paolos blog:

(Part 1) How To Boost Message Transformations Using the XslCompiledTransform class

(Part 2) How To Boost Message Transformations Using the XslCompiledTransform class Extended

 

Thank you

Download presentation, demos and scripts

How to Support Component-Level Instrumentation Using BizTalk CAT Instrumentation Framework

by | May 24, 2010 | BizTalk Community Blogs via Syndication

In one of our recent publications, we explained the key usage patterns for the ETW-based instrumentation framework which was made available to the community on the BizTalk CAT Best Practices Code Gallery. We have received a number of insightful follow-ups and interesting questions and one of them has triggered the following post.

Scenario

A BizTalk solution running in a production environment manifests a noticeable performance degradation. The operations team investigates the problem and arrives to a conclusion that it might be related to a bottleneck in a custom component used by a number of orchestrations in the BizTalk solution. The operations team would like to collect detailed diagnostic information to assert the validity of the above assumption. They want to be able to understand the component behavior as it relates to functions being invoked, measuring accurate durations of the method calls as well as tracing parameter values being used for execution.

Luckily, the BizTalk solution was fully instrumented using the ETW instrumentation framework by following the technical guidance and best practices from the BizTalk Customer Advisory Team (CAT). The operations team has full access and all the required privileges to be able to enable ETW tracing in the production environment. However, they might face with a new challenge.

Challenge

The complexity of the BizTalk solution in question has led to implementing a number of custom components spreading across the end-to-end architecture. Virtually all custom components have been enriched with relevant tracing and instrumentation events. When enabled, the ETW trace log contains thousands of events generated by these custom components. This makes it time consuming to locate the events produced by the suspected component causing a performance degradation. In addition, many events are being written by multiple components running simultaneously on separate threads and this increases the complexity in performing trace log data analysis.

The operations team would like to streamline the troubleshooting process by capturing only those events which are directly related to the component being investigated. Ideally, they want to be able to have these events written into a separate trace log so that it can also be shared with the developers to get their input. The operations staff opens a dialogue with the development team and finds that there is a solution provided by the developers and is already available in the production codebase.

Solution

When implementing core custom components for the BizTalk solution, the development team has made a decision to support the extra level of granularity and add instrumentation at the individual component level. The advantage of this approach is that trace events produced by individual .NET components can be captured in isolation from the others. This approach opens the opportunity for collecting the detailed behavioral and telemetry data related to a specific component whilst ensuring that any events produced by other custom components will not interfere with the trace log content.

The underlying implementation has rather been very straightforward.

First, the TraceManager class from the Microsoft.BizTalk.CAT.BestPractices.Framework.Instrumentation namespace was enriched with a new public static method:

// Returns an instance of a trace provider for the specified type. This requires that the type supplies its Guid 
// which will be used for registering it with the ETW infrastructure.
public static IComponentTraceProvider Create(Type componentType)
{
    GuidAttribute guidAttribute = FrameworkUtility.GetDeclarativeAttribute<GuidAttribute>(componentType);

    if (guidAttribute != default(GuidAttribute))
    {
        return new ComponentTraceProvider(componentType.FullName, new Guid(guidAttribute.Value));
    }
    else
    {
        throw new MissingMemberException(componentType.FullName, typeof(GuidAttribute).FullName);
    }
}

Secondly, every .NET component which required to be individually instrumented was decorated with a Guid attribute available in the System.Runtime.InteropServices namespace.

Next, a new protected readonly static field was added into each non-sealed instrumented .NET component. For sealed classes, the private readonly static modifier was used. This class member is statically initialized with an instance of the framework component implementing the IComponentTraceProvider interface which provides a rich set of tracing and instrumentation methods.

 

Lastly, all important aspects of the custom components’ behavior were wisely instrumented by calling the relevant tracing methods provided by the above static class member as opposed to using TraceManager.CustomComponent:

 

 

Summary

This article was intended to demonstrate the simple and very powerful approach to supporting the  code instrumentation in the custom .NET components to be able to capture trace events for individual components. The benefits of this technique lies in the ability to collect only those events which are necessary to perform troubleshooting of specific components in the BizTalk solutions, eliminate  “noisy events” which may come from other components, reduce the amount of events in the trace log and greatly reduce the time required to analyze the trace log data.

Placement of functoids on the mapper grid

Placement of functoids on the mapper grid

by | May 24, 2010 | BizTalk Community Blogs via Syndication

Hi all

I am just playing around with the new mapper in BizTalk 2010 beta (get it here).

I am happy to announce that the restrictions form the old versions of BizTalk regarding
placement of functoids that have the output from other functoids as input has been
removed.

In the “old” days (pre-BizTalk 2010 beta), you would have some of the mapper grid
marked as inaccessible when you dragged a functoid that has the output form another
functoid as input like this:

image

With BizTalk 2010 Beta you can place the functoids were you like. All links have a
small arrow on them indicating the flow of information and you can therefore have
a setup like this:

image

Very nice and more flexible, I think.

—

eliasen