Updated the post: http://bloggingabout.net/blogs/gerben/archive/2010/02/25/ibm-websphere-mq-wcf-channels.aspx
New findings are that Microsoft is planning a WAS listener for IIS7 for their channel. Update for the IBM one is that they're relying on JMS messages under the covers.
I'll be doing a session about... (not surprisingly)... "WCF Best Practices" at the Dutch DevDays 2010!
Check out the DevDays website for more info: http://www.devdays.nl/Agenda.aspx?pid=66
Cool stuff, me and me colleagues at the Achmea Microsoft Center of Excellence have a meet and greet with "The Gu" and Brain Keller at the end of the month. We have a chance to chat for a while with these guys. So if you where in my position what would you like to ask these guys?
Intro
Windows Communication Foundation out of the box ships with quite some transport mechanisms. By default it comes with http, tcp, msmq, etc. A channel for the quite widely used IBM WebSpere MQ (WMQ) transport is missing. Guess this probably is because Microsoft wants you to use their queuing transport: MSMQ.
To clarify terms up: the WCF thing that really puts the messages on the wire if generally referred to as a channel, transport or transport channel. To able to use that thing in WCF in config you need a binding. A transport combined with a binding is often called an adapter.
Due to history though quite some companies are still using WMQ. In the past I've extended WCF with a custom channel for WMQ for a company I worked for and that works fine. Though you actually don't want to build these kinds of things since they're quite complex. Especially if your need robust high volume processing. Luckily enough though both Microsoft and IBM have recently shipped a WCF transport for WMQ. Microsoft ships it with Host Integration Server 2009 which is part of BizTalk. IBM had a transport in alpha for while but it now ships it with WMQ version 7. I evaluated both of these transports and below are my findings.
Microsoft HIS Channel
WCF Channel for WebSphere MQ: Provides messaging support to remote MQSeries Queue Managers, using the WebSphere MQ Base Client (non-transactional), WebSphere MQ Transactional Extended Client APIs or local Queue Managers using the WebSphere MQ Server APIs.
Message patterns
Oneway send and receive supported.
Request reply not supported.
Distributed transactions also supported.
Ships with
Host Integration Server 2009 or BizTalk Server 2009 adapters for host systems.
You don't need to install or have BizTalk. One of the two above install the assemblies and it are just the assemblies you need to get it working.
Documentation / Samples
Quite some samples ship with the SDK.
\Program Files\Microsoft Host Integration Server 2009\SDK\Samples\MessageIntegration\MQChannel
There are only some readmes with the samples. Haven't found any documentation about the channel.
Licensing
Despite that you only need the assemblies and no BizTalk to get it working licensing is still via BizTalk. Cheapest way if you're just using the assemblies on non BizTalk server is to go with the branch edition.
Details at:
http://download.microsoft.com/download/3/9/E/39EB3E63-997C-47CA-9316-AA0B6CD7F9B8/Microsoft%20Host%20Integration%20Server%202009%20FAQ.docx
http://www.microsoft.com/biztalk/en/us/pricing-licensing.aspx
Dependencies
IBM WebSphere MQ Client 6.0 with Fix Pack 6.0.1.1 or higher
IBM WebSphere MQ Client 7.0 with Fix Pack 7.0.0.1 (required for 64-bit).
Communication with MQ
Not sure how the adapter under the covers communicates with MQ. Seem not to be using the standard WMQ .NET API (AMQMDNET.DLL).
Hosting
Currently no WAS listener available for IIS7. So if you need to listen for messages on a queue you have to host outside IIS. WAS listener is planned for next version.
IBM Channel
Message patterns
Oneway send and receive supported.
Request reply supported.
Distributed transactions not supported.
Assured delivery mechanism supported to prevent message loss. Uncaught exception in service rolls back message to queue.
Ships with
IBM WebSphere MQ Client or Server 7.0
Documentation / Samples
\Program Files\IBM\WebSphere MQ\tools\wcf\samples
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzav.doc/un12000_.htm
Quite some samples and good documentation available.
Licensing
Ships with MQ client 7.
Dependencies
The WebSphere MQ custom channel for WCF can only connect to WebSphere MQ V7 or higher queue managers.
Communication with MQ
Connecting via XMS.NET / JMS stuff under the covers. Always constructs JMS messages. Makes an JMS byte message with RFH2/JMS headers in it. Channel also expects this when receiving.
Hosting
Also no WAS listener available for IIS7.
Conclusion
It all looked very nice at first that both Microsoft and IBM are shipping a WCF channel for WMQ. Major disadvantages for me for the Microsoft one are the licensing model and that they don't support request-reply. The IBM channel doesn't have these problems but is missing WMQ 6, distributed transactions and non JMS support on the other side.
Yes I know queues aren't meant for request-reply communication. But there are still quite some old systems around that only are accessible via WMQ, that's why I want request-reply over WMQ.
A nice update and overview by Lars: http://startbigthinksmall.wordpress.com/2010/02/17/what-is-left-of-microsoft-oslo-what-now-with-sql-server-modeling-early-2010/
Not a lot happening in this space lately. I only see the team blogging about OData. Still curious where this will go, especially for the M / Grammer part.
Quite some confusion around what AppFabric is lately. Probably due to all the name changes. It breaks down in an on premise and cloud variant:
1. Windows Server AppFabric (on premise)
It's a set of integrated technologies that make it easier to build, scale and manage Web and composite applications that run on IIS. Consists of:
- Distributed Caching (code named "Velocity")
- Service and Workflow Management (code named "Dublin")
2. Windows Azure Platform AppFabric (in the cloud)
Code named .NET Services or BizTalk services longer ago.
It helps to connect apps and services between Windows Azure and on-premises deployments. Consists of:
- AppFabric Access Control
- AppFabric Service Bus
Guess that the confusion comes from that the two variants actually don't have anything in common.
Whooo... it's done! Had these articles in the pipeline for quite a while :-). They come from my years of WCF experience started around 2005 with the CTPs until now.
Hope you find the posts usefull, let me know. Best place is to start is with the introduction post.
In addition to the WCF Best Practices that are already around. WCF Best Practice #6: Know the limits of reliable Messaging with WCF.
WCF has an implementation of WS-ReliableMessaging. Due to its name it’s often thrown in as the solution to all reliability problems. But messages still can get lost with this mechanism if for example the service is shutdown.
Clemens Vasters describes it here. The summary:
"If you need end-to-end durable reliable messaging with full support for transactional I/O you need an infrastructure that's in control of both ends of the communication path and as it happens, such an infrastructure is part of the Windows operating system family. If these are your requirements, your WCF binding of choice is likely the NetMsmqBinding. If you are mostly worried about not losing messages under less-than-optimal networking conditions or require session support – which are the more common use cases – the reliable session support in WCF is the right choice and a great leap forward when compared to the previous Web Services stacks."
Be aware though that MSMQ messages are limited to 4MB in size.
Reliable messaging also isn’t very handy with load balancers:
http://blogs.msdn.com/drnick/archive/2007/07/13/sticky-sessions.aspx
Sticky sessions can be become troublesome in intranet scenarios.
In addition to the WCF Best Practices that are already around. WCF Best Practice #5: One-way is not always really one-way:
Be aware that the client.Close() can block until the service operation is done. Yes you read it right even when oneway closing a client can block until the service side is done. This is happening in quite some cases where bindings are configured to maintain sessions. This happens for example with Message security and or reliable session support.
There is a difference though in this behavior depending on how your contract is composed. This is between contracts with only oneway operations, which I'll call "Oneway contracts" and contracts that do have oneway operations combined with request-reply operations which I'll call "Mixed contracts".
Below is a table for the most common bindings. Check out if Proxy.Close() isn't blocking in the case where you want to do oneway operations:
| Binding |
SecurityMode |
reliableSession |
Close blocks (Oneway only) |
Close blocks (Mixed) |
|
basicHttpBinding (default)
|
None |
- |
No |
No |
| wsHttpBinding |
None |
False |
No |
No |
| wsHttpBinding |
None |
True |
Yes |
No |
|
wsHttpBinding (default)
|
Message |
False |
Yes |
Yes |
| wsHttpBinding |
Message |
True |
Yes |
No |
| netTcpBinding (default) |
Transport |
False |
Yes |
Yes |
| netTcpBinding |
None |
False |
Yes |
Yes |
| netTcpBinding |
None |
True |
Yes |
No |
| netTcpBinding |
Message |
False |
Yes |
Yes |
| netTcpBinding |
Message |
True |
Yes |
No |
Possible solutions if you don`t like the blocking proxy.Close():
- for wsHttpbinding: you could disable use of sessions in service contract via SessionMode.NotAllowed.
- for netTcpbinding: You can't disable sessions since they're used by the tcp transport. You could use streamed transfer mode. Be aware though that this is not working in combination with message security and or reliable sessions. basic, wsHttp or some queuing binding with binary encoding could be an alternative.
Also One-way != asynchronous. Lowy described this one here: http://msdn.microsoft.com/en-us/magazine/cc163537.aspx. The section I’m talking about:
"One-way calls do not equate to asynchronous calls. When one-way calls reach the service, they may not be dispatched all at once and may be queued up on the service side to be dispatched one at a time, all according to the service configured concurrency mode behavior and session mode. How many messages (whether one-way or request-reply) the service is willing to queue up is a product of the configured channel and the reliability mode. If the number of queued messages has exceeded the queue's capacity, then the client will block, even when issuing a one-way call. However, once the call is queued, the client is unblocked and can continue executing while the service processes the operation in the background. This usually gives the appearance of asynchronous calls. All the Windows Communication Foundation bindings support one-way operations."
So be aware of the situations in which a client still can block.
In addition to the WCF Best Practices that are already around. WCF Best Practice #4: know your tools:
Tools from the SDK:
The framework sdk comes with quite some tools that are essential for the WCF developer:
They are listed here: http://msdn.microsoft.com/en-us/library/ms732015.aspx
Svcutil.exe, SvcConfigEditor.exe and SvcTraceViewer.exe will be your new best friends :)
REST starter kit
Toolkit from the WCF Team itself to help with building REST-full services:
http://aspnet.codeplex.com/wikipage?title=WCF%20REST&referringTitle=Home
AppFabric
Hosting part previously code named “Dublin”. When released will help with hosting and tracking and tracing your WCF Services.
Web Services Software Factory (WSSF)
WSSF by Microsoft’s pattern and practices (P&P) team can help with building WCF services. It contains visual designers to build services according to good practices. Check it out at http://servicefactory.codeplex.com
The tool is quite ok but I’m not an enormous fan of it. The designers don’t add a whole lot of abstraction to building WCF Services over code. Plus stuff that comes out from the P&P team is not officially supported. It will work with VS2010 but no guarantees for a longer lifecycle.
David Slot and I wrote an extension a while ago to hook WSSF one up with Enterprise Library: http://entlibextensionswssf.codeplex.com
Enterprise Library (EntLib)
EntLib has some nice integration with WCF for the following blocks:
1. Exception Handling Application Block
ExceptionShieldingBehavior can be specified on a service contract. Calls the Exception Handling Application Block to shield exceptions from the caller
Logging Application Block
2. Logging Application Block
EntLibLoggingProxyTraceListener can be configured to enable the Logging Application Block to process WCF trace events. XmlTraceListener can be used with the block to output events in the format consumable by WCF diagnostics tools.
3. Validation Application Block
ValidationBehavior can be specified on a service contract to enable validation of data contracts
Check out the EntLib documentation for the detailt. WCF info is listed under the documentation of the blocks under the “Key Scenarios” section. For the logging block the info is under the “Developing…” section.
WSCF.Blue
Helps when you want to do contract first development with WCF: http://www.codeplex.com/WSCFblue/
Approach and tool described here:
http://msdn.microsoft.com/en-us/magazine/ee335699.aspx
Additional tools on codeplex
Not familiar with these ones probably worth checking out:
http://wcfloadtest.codeplex.com
http://www.codeplex.com/WCFVisualizer
http://wcfcontrib.codeplex.com/
http://wcfsecurity.codeplex.com/
http://wcfextensions.codeplex.com/
Missing tools
Let me know if I missed some important tools.
In addition to the WCF Best Practices that are already around. WCF Best Practice #3: Contract first:
Not really a best practices but still an important thing to know if you’re new to WCF. WCF isn’t very good at developing contract first. By default you build services CLR based. WCF on runtime creates a WSDL and XSD’s of the CLR based servicecontract and datacontracts.
Important thing to know especially if you come form a world where contract first with XSD’s and WSDL’s is the approach like with BizTalk server.
If you do want to do contract first then check out WSCF.Blue this can help with this in WCF.
http://www.codeplex.com/WSCFblue/
http://msdn.microsoft.com/en-us/magazine/ee335699.aspx
In addition to the WCF Best Practices that are already around. WCF Best Practice #2: Don't forget XmlNamespace settings:
By default WCF puts the “http://tempuri.org/” namespace in your wsdl and contracts. Normally you don’t want this. You can control this from three places:
- In your config file in the services/service/endpoint/bindingNamespace attribute
- In your servicecontract: [ServiceContract(Namespace="http://myuri.net/")]
- In your servicebehavior: [ServiceBehavior(Namespace="http://myuri.net/")]
In addition to the WCF Best Practices that are already around. WCF Best Practice #1: Don't build a WCF service:
Be sure to know why you’re building a service for something. WCF has impact on development time, deployment, performance, etc. Don’t do it if you can’t articulate clearly why you need your logic as a WCF Service. I’ve seen quite people build services for almost anything while an assembly with a good interface also suited their needs.
WCF is already around for a while, though best practices aren’t very well known in the developer community. In my search for resources that summarize them best I can recommend the following ones:
- Mehran Nikoo indexed the Microsoft articles that are around.
- Christian Weyer collected a nice selection of tips and tricks form the field.
- Brian Noyes also collected quite some best practices.
My top most useful practices out of these from my experience in the field are:
- Watch out with the using statement with proxies.
- Use WCF tracing and message logging to see what’s going on. Some bad things sometimes don’t come up as an exception, but only as errors or warning in the traces.
- Out of the box WCF is configured pretty conservative for performance, you almost always have to change the default settings.
Although the above resources contain quite some practices, I’m still missing some. I’ll describe these myself in separate posts and these are:
#1 Don't build a WCF service
#2 Don't forget XmlNamespace settings
#3 Contract first
#4 Know your tools
#5 One-way is not always really one-way
#6 Know the limits of reliable messaging with WCF
Came back from the LEAP 2010 trip to Redmond last weekend. For those who aren’t familiar with LEAP, it stands for Lead Enterprise Architect Program [1]. It’s a program organized by Microsoft in the Netherlands. It starts with five master classes in the Netherlands on the following topics: Software + Services, Business Intelligence, Infrastructure, Identity + Access Management and Information Worker.
After these five classes there is a trip to the Microsoft Campus in Redmond. Nothing was planned on the first day so we had some time to visit downtown Seattle. Worked and lived in Seattle for a while in 2006 so it was nice to be back again.
The rest of the week was filled with sessions which were held at the Microsoft Conference center on the campus. Various topics presented by pretty well known speakers of the product teams. There were sessions on Azure, SharePoint, Software Lifecycle Management, System Center, etc. Also some nice side trips organized to the Microsoft Company store and the Microsoft Home [2].
Besides the jetlag it was a pretty cool week. Everything was well organized like food, transportation and even evening programs. Found the master classes in the Netherlands not so valuable if you`re already working in the Microsoft space for a while, though the trip to Redmond makes it still a nice program to join :). Guess LEAP will probably run again next year, so check it out if you haven`t done it yet.
[1] http://leaphaip.msnlevents.net
[2] http://www.microsoft.com/presspass/events/mshome/default.mspx
More Posts
Next page »