August 2006 - Posts
Early this month in Redmon Jon showed me the (at the time) current version of the Atlas Windows Workflow Designer. I was really impressed with all the functionalities built into this tool. Now the bits are available to the community!! I’m having a lot of fun playing with it. Great job Jon!!
There are many typical scenarios in which Service Broker is the ideal solution for interactions between BizTalk and SQL Server. Last week one of our solution architects point to a scenario that he was facing with a customer. The challenge was to avoid simultaneous polling of the SQL Server adapter in a topology with two BizTalk Servers (no master MessageBox) hitting the same SQL Server database. Richard Seroter described this scenario really well a year ago. At the end we implemented the classic solution using SERIALIZABLE transactions to avoid concurrent reads. It worked perfectly but is well known that in other scenarios this technique can introduce unnecessary locks.
This brought to my mind one of the most important features of Service Broker: Conversation Locks. Service Broker uses conversation group locks to guarantee that only one application can process a related set of messages at any given time. Conversation group locks to guarantee that messages are processed exactly once, in order. Locking occurs for the conversation group rather than for the conversation ID.
Using conversation locking we can implement the explained scenario with no additional effort. Just need to associate the two locations with the same conversation group and the solution is ready to go. The additional advantage on this approach is that the entire DB is abstracted through the Service Broker queue. BizTalk Server has no knowledge of the internal database schema which removes any dependencies between the BPM and DB tiers.
I’m happy to announce our new member of the AdapterWorx family: SonicMQ adapter for BizTalk Server 2006. This adapter will complement MQSeries and TIBCO Rendezvous as the JMS-based technologies adapters.
SonicMQ adapter for BizTalk Server 2006 enables you to use SonicMQ messaging functionalities within BizTalk Server. SonicMQ is an efficient, secure, and scalable messaging system for business-to-business, networked, and internal integrated applications.
This adapter is composed for the SonicMQ Transmit and Receive adapters providing the following functionalities:
Transmit
- Send messages to SonicMQ Queues.
- Point to point and publish-subscribe messaging
- TCP and HTTP transport protocols.
- Multi Broker and Fault Tolerance connections
- AutoAcknowledge connections
- Transacted sessions
- Per message encryption
- Different authentication mechanisms like username-password or SSO.
Receive
- Periodically receive messages to SonicMQ Queues.
- Point to point and publish-subscribe messaging
- Durable Subscriptions
- TCP and HTTP transport protocols.
- Message filtering through message-selectror expressions.
- Multi Broker and Fault Tolerance connections
- AutoAcknowledge connections
- Different authentication mechanisms like username-password or SSO.
Until now the experience that we have had with customers on or TAP program has been great. A trial version is available on AdapterWorx. The formal release is scheduled for the next weeks.
For question regarding the adapter feel free to contact myself or our Director of Sales Gerard Demmer.
BEA Systems has acquired Flashline,the plans are to include their Metadata Repository as part of the Aqualogic family.
The folks of the Architecture & Strategy team (specially Fred Chong and Gianpaolo Carraro) has been doing an amazong job around the Software as a Service concepts. Part of this work is the new SaaS MSDN Developer Center. Great job guys!!
One of my readers asked me the other day about client(proxy) extensibility points on Windows Communication Foundation (WCF). Conceptually there a number of scenarios in which makes sense to extend proxy functionalities.
- Custom Message Validation. A user may want to enforce that a message is valid for a certain schema. This can be done by implementing the IClientMessageInspector interface and assigning the implementation to the MessageInspectors property.
- Custom Message Logging. A user may want to inspect and log some set of application messages that flow through an endpoint. This can also be accomplished with the message interceptor interfaces.
- Custom Message Transformations. Rather than modifying application code, the user may want to apply certain transformations to the message in the runtime (for example, for versioning). This can be accomplished, again, with the message interceptor interfaces.
- Custom Data Model. A user may want to have a data or serialization model other than those supported by default in WCF (namely, XmlFormatter, XmlSerializer, and raw Messages). This can be done by implementing the message formatter interfaces.
- Custom Parameter Validation. A user may want to enforce that typed parameters are valid (as opposed to XML). This can be done using the parameter inspector interfaces.
As part of our daily interaction with customers we (TwoConnect) had developed different demos to illustrate these features.
On the WCF model there are two main client extension classes ClientRuntime and ClientOperation. Both classes are intended to extend the service proxy. However ClientRuntime extends the proxy at the contract level while ClientOperation works at operation level. In order to insert extension points in both cases you should use behaviors. Obviously ClientRuntime provides a broader set of options given that extension points can be inserted in endpoint, contract, operation or service behaviors respectively. On the other hand extension points for ClientOperation are typically represented by operation behaviors.
The following example shows how to create a custom endpoint behavior and add a custom message inspector to it.
public class SampleCustomBehavior: IEndpointBehavior { public void AddBindingParameters(ServiceEndpoint serviceEndpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters) { } public void ApplyClientBehavior(ServiceEndpoint serviceEndpoint, System.ServiceModel.Dispatcher.ClientRuntime behavior) { //Add the inspector behavior.MessageInspectors.Add(new CustomMessageInspector()); } public void ApplyDispatchBehavior(ServiceEndpoint serviceEndpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher) { } public void Validate(ServiceEndpoint serviceEndpoint) { } } |
CustomMessageInspector class declaration looks like the following
public class CustomMessageInspector : IClientMessageInspector { #region IClientMessageInspector Members public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState) { } public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel) { Console.WriteLine(request.ToString()); return null; } #endregion } |
Finally the following code illustrates how to add the behavior to the service’s proxy
MyServiceClient proxy = new MyServiceClient(); proxy.Endpoint.Behaviors.Add(new SampleCustomBehavior()); |
Moustafa Khalil Ahmed did a great post about tracing Business rules execution outside Windows Workflow Foundation context.
The Web Services Policy Working Group has released First Public Working Drafts of the Web Services Policy 1.5. The Policy Framework defines a model for expressing the nature of Web services in order to convey conditions for their interaction. Attachment defines how to associate policies, for example within WSDL or UDDI, with subjects to which they apply.
More Posts