I was on a conference call with those characters from SOA Software and they were demonstrating their BizTalk Management Pack. They also spent a lot of time covering their in-development WCF binding.
Moving forward, SOA Software is releasing Microsoft-friendly agents for …
- IIS 6.0 (SOAP/HTTP)
- WCF (any transport)
- BizTalk (any transport)
- BizTalk-WCF (any transport)
All of these (except the BizTalk agent) support policy enforcement. That is, the BizTalk agent only does message recording and monitoring whereas the other agents support the full suite of SOA Software policies (e.g. security, XSLT, etc).
So what is the difference between the BizTalk agent, and the BizTalk-WCF agent? The relationship can be represented as such:
The BizTalk-only agent is really a pipeline component which captures things from inside the BizTalk bus. This means that it will work with ANY inbound our outbound adapter. Nice. The SOA Software WCF binding is at the WCF adapter layer, and allows for full policy enforcement at the adapter layer. However, this is ONLY for the BizTalk WCF adapters, not the other adapters.
So if I had a WCF endpoint that I wanted to play with SOA Software, I could first attach the out-of-the-box SOA Software pipelines to the receive location.
Next, in the WCF-CustomIsolated adapter configuration, I can specify the new soaBinding type.
I don’t HAVE to do the pipeline AND the WCF binding if I have a WCF endpoint, but, if I want to capture the data from multiple perspectives, I can. For that binding, there are a few properties that matter. Mostly importantly, note that I do NOT have to specify which policy to apply. The appropriate policy details are recovered at runtime, so making changes to the policy requires no changes to this configuration.
From within the SOA Software management interface, I can review my BizTalk endpoints (interpreted as operations on a WSDL that represents the BizTalk “application”).
Notice that this is a managed BizTalk receive location. If I sent something through this managed receive location (with a policy set to record and monitor the traffic) I could see a real-time chart of activity, and, see the message payload.
Notice that I see all the context values, AND, the payload in a CDATA block. This supports BizTalk flat file scenarios.
As for the WCF binding, you would install the SOA WCF binding on the client machine, and it becomes available to developers who want to call the SOA-managed WCF service. The binding looks up the policy details at runtime, again shielding the developer from too much hard coding of information.
So what’s cool here? I like that the BizTalk agent works for ALL BizTalk adapters. You can create a Service Level Agreement (SLA) policy where more than 10 faults to an Oracle adapter send port results in an email to a system owner. Or if traffic to a particular FILE receive location goes above a certain level (per day), then raise an issue. From the WCF side, it’s very nice that all WCF transports are supported for service management and that service policy information is dynamically identified at runtime versus embedded in configuration details.
If you’re a BizTalk shop, and you have yet to go nuts with SOAP and services, you can still get some serious value from using the BizTalk agent from SOA Software. If you’ve fully embraced services, and are already on the WCF bandwagon, the upcoming WCF binding from SOA Software provides a vital way to apply service lifecycle and management to your environment.
Technorati Tags: BizTalk, SOA Software, WCF
Richard Seroter's Architecture Musings 