Major BizTalk Incompatibility – IIS 7 and WCF Publishing Wizard

On my current project the client has been dabbling with BizTalk 2006 R2 in a very unsupported configuration with Windows Server 2008, and SQL 2008. In previous posts I talked about Windows Server 2008 and some challenges installing BizTalk on this OS. Generally, Windows Server 2008 behaves well for BizTalk. SQL 2008 has behaved well and has not presented any problems for BizTalk other than the fact that it does not include Notification Services so you must install this optional component from the installer included with SQL 2005. This post describes some new difficulties I have identified when using BizTalk Server 2006 R2 with IIS 7.
 
Working in the unsupported environment has been very interesting because it has identified that there are issues with BizTalk’s WCF integration on Windows Server 2008. Windows Server 2008 includes IIS 7 which has been overhauled extensively. Several issues have been identified with IIS 7 and BizTalk Server 2006 R2:
 
– It is possible to run the BizTalk WCF Publishing Wizard through completely to create a .svc WCF endpoint and a virtual directory to host the WCF service but by default IIS 7 is not configured to support the .svc extension. In order to setup the .svc extension, use the IIS 7 directions at http://msdn.microsoft.com/en-us/library/ms752252.aspx.
 
– When running the BizTalk WCF Publishing Wizard sometimes IIS 7 will get dumped out completely. From time to time running the wizard the web.config at c:\Inetpub\wwwroot and all of the virtual directories in this folder get removed during the time that the WCF Publishing wizard is running. For this reason, I strongly recommend you backup the web.config in the web root and all virtual directories stored under the web root before running the WCF Publishing wizard on a box that includes IIS 7. If you just registered the .svc handler and IIS 7 gets dumped out you will need to create it again. Due to this issue, I also strongly recommend that if you need to work with HTTP or IIS related adapters, use Windows Server 2003 R2 with IIS 6 rather than Windows Server 2008 with IIS 7.
 
– The BizTalk WCF Publishing Wizard may require additional permissions when run on Windows Server 2008 than on Windows Server 2003 due to the secure by default nature of IIS 7. I identified issues with the NetMSMQ binding and MEX-only endpoints created with the BizTalk WCF Publishing Wizard in which permissions must be loosened while the wizard is running although they may be tightened afterwards.
 
Thanks,
 
 

BizTalk WCF Receive Adapters Wrap SOAP Body Content

On a recent project I was exposing a BizTalk orchestration as WCF for a Windows Forms client and a Windows Mobile client. For simplicity, a single BizTalk receive port was being used with multiple WCF receive locations. The BizTalk WCF publishing wizard allows this type of functionality through running of this wizard more than one time. This is by far one of the coolest WCF capabilities in BizTalk – the ability to expose multiple bindings (like you can do in WCF) for each BizTalk orchestration. For example, one BizTalk orchestration can be exposed for both a WCF-BasicHttp binding and a WCF-NetMSMQ binding through running the WCF publishing wizard twice, once choosing to publish a service endpoint for the WCF-BasicHttp binding, and then a second time as a Meta-data endpoint (MEX) for the WCF-NetMSMQ binding.
 
The message body properties for both of these receive locations was set to "Body" which is supposed to pull out the contents of the SOAP:Body from the WCF service call. When testing both of these bindings the contents of the SOAP:Body were being output but they were being wrapped in a part element like in the message given below:

<part i:type="a:string" xmlns:i="http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:a="http://www.w3.org/2001/XMLSchema">Hello World!</part>
 
The application that was being implemented was one in which the body data needed to be passed along intact and not further wrapped. The MSDN documentation on the Message Body properties (http://msdn.microsoft.com/en-us/library/bb226478.aspx) did not mention that additional data would be passed along to wrap the content that was passed to the WCF receive location. The additional part element caused problems with the next system to receive the message. So I used the Path option rather than Body for the message body and used the XPath expression of /*[local-name()=’part’] to remove the additional wrapping of the data. This provided what I would expect to be included in the body part of the SOAP:Body – the data passed to the WCF operation and nothing more.
 
This tip should help you avoid one challenge of working with the new WCF features of BizTalk. Thanks!

BizTalk 2006 R2 Repair Fails with Visual Studio 2008 Installed

A few months ago I had posted on a way to run both Visual Studio 2008 and BizTalk Server 2006 R2 with Visual Studio 2005 so that you could take advantage of the new environment for developing WCF and WF projects while continuing to work with BizTalk. I had setup this software combination on my local development box in Windows XP and had been working fine without any significant issues. Although there are a few known issues about TFS compatibility across solutions that include BizTalk projects as well as .NET 3.5 projects, I had not encountered any issues with my BizTalk installation until today.
 
During some development I realized that I likely needed to do a repair on my BizTalk installation due to an error I was receiving about a key violation error in one of my BizTalk databases. It is a common recommendation that the installation be repaired through the Add/Remove programs repair part of the installation wizard when certain issues are encountered with BizTalk. So I loaded the BizTalk installation image and started the repair and everything worked fine until near to the end of the repair. Then all of a sudden I started receiving errors about the WCF adapters that are included with BizTalk Server 2006 R2. Here is an example error:
 
Failed to add adapter: WCF-NetNamedPipe, Error C0C025CA
 
A similar error occurred for nearly every one of the R2 WCF adapters with the name of the adapter being the only thing different in the error message. I clicked OK for every one of the error messages and this was apparently not a significant-enough error because it did not prevent the repair from continuing. The repair completed successfully without any other reports of problems. I checked in the Event Viewer and there were not any additional error messages to provide more information on what went wrong.
 
At this point I think the reason this problem occurred is because I have a version of Visual Studio on my system that is not currently compatible with BizTalk because I know that the BizTalk repair wizard did not have this problem running before I had installed Visual Studio 2008 side-by-side. Until I find more information about this error I have to say this is a known issue for BizTalk development where you have a side-by-side of Visual Studio 2005 with the BizTalk extensions and a separate Visual Studio 2008. At this point I am not sure whether the WCF adapters have suffered any sort of actual casualty by the repair wizard issues. But I think if you want to run the repair wizard successfully without any issues, be sure to uninstall Visual Studio 2008 prior to starting the repair wizard. Good luck with your BizTalk environment configuration!
 

Another Way to Explain BizTalk Role Links

I am working on a project where I am extending a BizTalk application so that I can route messages from a single FILE port to different BizTalk applications and various orchestrations through the use of role links. Role links are one of the less frequently used and discussed tools of an experienced BizTalk developer. Getting my mind around role links was difficult because of the number of configuration details required to setup a role link. I am indebted to Eric Stott’s blog post at http://blog.biztalk-info.com/archive/2006/10/25/BizTalk_Role_Links_explained.aspx, but I think it would seem easier to describe role links as a precursor to the WCF binding architecture. I will describe some architecture notes on role links next but to see my thoughts on how role links are like WCF, skip on down a few paragraphs.  
 
Role links are essentially the opposite of dynamic ports. A dynamic port consists of one port that then has multiple variations of configurations based on the dynamic expressions applied to this port for one adapter. A role link is a static configuration but is essentially a collection of ports of different adapters. For a dynamic port there is not always an explicit party concept; in a dynamic port a message is being sent from one organization to some other variable organization. And in a role link a message is either being sent or received and is then one of a collection of organizations for each endpoint. Role links are based on ports that are designated as being associated with some BizTalk party. The party can have one or more aliases which act as destination tokens when used with role link based routing.
 
So here are a few examples of how role links could be used:
– When you need to have dev, test, and production parties all hosted in a single BizTalk application and merely need to differentiate logic for these parties based on ports
– When you need to expose a single business process to multiple parties without creating more than one orchestration to handle all of them.
– When you need more than 1 backup port in a BizTalk application
– When you are struggling to manage so many BizTalk artifacts and are looking for a way to reduce the number of orchestrations
– When you want a lightweight built-in BizTalk routing mechanism that has a simple but flexible mechanism for specifying a routing destination.
– When you want to expose more than one adapter for some organization as connectivity options
 
This last example of a role link use helped me think about a more contemporary example of a role link. In WCF when you expose a service, it is possible to expose more than a single endpoint for a service so that the organization that connects to the service can use either HTTP or TCP or some other protocol or set of binding options to connect to the service. This is frequently used to expose a WSI basic profile service for interoperability and a WS-* or SOAP 1.2 service for newer clients as in the following example: http://keithelder.net/blog/archive/2008/01/17/Exposing-a-WCF-Service-With-Multiple-Bindings-and-Endpoints.aspx. WCF provides the binding infrastructure so that it is possible for a client to have various options for connectivity. In the same way, role links provide a way to provide to a client multiple integration options that all get consumed into the same business process.
 
So role links are very similar to the binding infrastructure in WCF due to the trasnport-level flexibility both enable. If you are a BizTalk developer, you should take role links for a spin because they provide some very valuable extensibility options. It does take a while to get used to role link abstractions so I recommend taking WCF as a good example of what role links seek to accomplish and then throw adapters and parties in the mix and it makes much more sense. Have fun with role links!

Future of Send/Receive Ports

Today I attended a session on the Windows Workflow enhancements included with .NET 3.5. Two new WF shapes were introduced for sending messages to other workflows or WCF services. These two new shapes are the send and receive activities. Here is a link to a good article on these enhancements: http://msdn.microsoft.com/en-us/magazine/cc164251.aspx. In the BizTalk world, processes are defined using the orchestration designer and the send and receive parts of the process are defined on sides of the designer windows and are connected visually with lines that correspond to the send and receive activity shapes. Here is an example image which shows these lines: http://www.traceofthought.net/content/binary/btmsmq.jpg. From a visual perspective, if you have a lot of send and receive ports, especially in scenarios where you are sending lots of messages or multiple messages from a single send shape, there can be a lot of lines all over the design surface which can get messy very quickly. In fact, the lines can become a huge distraction in designing an orchestration. In .NET 3.5 the send and receive activities use arrows to denote the messaging direction rather than using connective lines. While the connective line does provide a visual cue in the orchestration designer whether the port is setup properly, I think not having the lines is much cleaner and more manageable.
 
The ContextExchange class was talked about and I got a glimpse of how context properties are receivable through the Inner Channel (Context Channel) of this class. This is an important BizTalk feature I was looking for a replacement feature for. Here is a good powerpoint that describes this: http://download.microsoft.com/download/5/8/1/5810d618-361f-4f47-943c-b20c0d420178/DEV340.ppt.
 
I also learned that the WF workflow instance Id is important for calling back into a long-running WCF service marked with the DurableService attribute. The thing to know is that this Guid value must be stored somewhere in a custom application because the WF infrastructure will not provide a built-in location for this. Use of this value when passed back into a method of a long-running process will activate the dehydrated (persisted) workflow instance.
 
Thanks for tuning in about my TechEd sessions!

WCF the REST way

Today I attended a session on using WCF through the REST model of web service interactions. This remote method model is based on HTTP requests and includes the following HTTP actions: GET, POST, PUT, and DELETE. This model relies more heavily on the role of URIs as a way to more clearly define resource endpoints. Jon Flanders talked about techniques in defining well-known URLs based on the general experience most people have with the web and URLs. Resources in the REST model are useful because they more clearly identify entities within a business object model. So rather than have a service method called GetWidgets you would have a Widgets resource and send in a GET action to get the Widgets.
 
Recently, I have been reading through the book Learning WCF (by that Indigo girl) and it spends some time explaining the role of endpoint base addresses and full addresses. Base addresses are based on a configuration entry for the address and then a Service URI that indicates the service at which the base address then exists. Here is a link about the use of Base Address: http://www.dasblonde.net/CommentView,guid,756f2aee-7146-4bc3-8406-d0e3530dc507.aspx (the CSS styling is not working right on her site so select the text on the article to see the text.) I did not hear much in the REST session about the role of base addresses and full addresses, but it seems like this would be a more natural approach than building an extra long url like a Flickr url (http://www.flickr.com/photos/mzalikowski/530036109/) where the date is a meaningful URI and one of a couple different resource addresses possible with Flickr.
 
I think the REST model will serve to simplify the addressing schemes used with web services but I am a little worried about interoperability. For example, if a SOAP service exposes a web service endpoint that provides WSDL, it would also make sense to expose an endpoint that provides REST since it is a different invocation standard. WSDL has very widespread adoption, whereas REST is not implemented by everyone and could take a while before all vendors provide a compatible implementation. I am worried about web service integration that does not recognize PUT or DELETE operations and the possibility that these may be handled inproperly if a SOAP engine or HTTP engine processes these incorrectly. More to follow on whether I find any incompatibilities or gotchas with REST…
 
Tune in tomorrow for a post on the last day of TechEd. Thanks to anyone who has been reading my posts.

Distributed Technologies for Embedded Devices

Today I had planned on taking a few more sessions on WCF and SOA but got pulled into the first session on Windows Embedded because an implementation for one of our Magenic clients was being discussed. In the course of the session, SOA actually came up as central to the current strategy and vision for Windows Embedded technologies. Recently, some Windows Embedded devices have become 32-bit an IP addressable which means they can handle more sophisticated operations and communication over addressable technologies. This was quite interesting and eye-opening to me because I typically classify Windows embedded technologies within the Windows Mobile or Compact Framework technology stack. The role of device-based technology became my focus for the day.
 
Later in the day I was exploring the Technology Learning areas at the conference where different technologies are represented by Microsoft employees and partners who can answer technology questions. The format at TechEd was useful because each technology included a mini-booth where there was a flat-screen that the expert could demonstrate technology rather than just describe it on a whiteboard. I walked around and talked to people representing BizTalk. I focused most of my time on the BizTalk RFID and Server booths but also talked with the Host Integration Server people as well. At the BizTalk RFID booth I was asking questions about the role of standardization within the RFID platform and I learned that RFID devices are basically standardized on frequency and communication technology and BizTalk RFID basically takes advantage of this standardization to provide integration capabilities. I had heard RFID discussed at the Business Process/SOA conference back in October 2007 but it did not really take hold in my mind how this could be useful. One partner company representative from Cathexis (http://www.cathexis.com/about-cathexis/partners/biztalk-rfid.aspx) demonstrated the use of a handheld device and an RFID scanner which illustrated to me how easily WCF or other distributed technologies could easily be connected to an RFID application. So after these sessions I was very interested in how mobile or embedded devices could act as clients within a distributed data model which was enabled through BizTalk, WCF, and SOA.
 
At the end of today I attended a session on parallel computing which describe a new Microsoft product called Windows HPC (http://www.microsoft.com/hpc). In BizTalk I am frequently asked about how to properly design the best cluster or handle vertical or horizontal scalability. When BizTalk is concerned, you have internal BizTalk cluster design through hosts as well as all of the existing Windows cluster stack and NLB to take advantage of. With multi-core processing and Hypervisor virtualization, even more options for application partitioning are now available. It was interesting to hear a classical software engineering perspective on the topic of parallel computing and that Microsoft is making strides to improve its cluster product set over the existing Windows cluster product. I anticipate that the role of parallelism may occupy a BizTalk setting much like other BizTalk tuning or throttling in future versions of BizTalk.
 
Tune in tomorrow for more details from Tech Ed sessions!

BizTalk and the Cloud

Today I was at the pre-conference part of TechEd in Orlando. I attended the WCF/SOA overview by Juval Lowy and picked up a few interesting details. In my personal learning I have been working through the Learning WCF book by that Indigo girl (http://www.oreilly.com/catalog/9780596101626/) and have been working through it on my train ride into Chicago. Lowy has another book in O’Reilly series and I found the content of his talk today to be roughly parallel to the content of the Learning WCF book. The Learning WCF book targets a lower audience level than the Programming WCF services book that Lowy has (http://www.oreilly.com/catalog/9780596526993/index.html) but I wanted to have a better foundation on WCF. Ok, enough of the rambling.
 
So a few topics on WCF that I thought were most interesting. Lowy talked about the DurableService attribute, which can be added to a WCF service implementation to provide some of the persistence typically associated with WF in .NET 3.5. This is a closely related feature to BizTalk’s concept of orchestration dehydration. For more information on DurableService see (http://weblogs.asp.net/gsusx/archive/2007/06/14/orcas-durable-services.aspx – unfortunately is an Orcas post so no guarantees). DurableService enables a WCF service to function as a long-running process, similar to BizTalk long-running transactions. It is very interesting to see a couple of different options available for service persistence and the flexibility to choose to either use this via WCF or WF or both. In BizTalk design you might typically use a tier of servers for processing messages received through adapters, and this capability of separating the service persistence in either WCF or WF means that it will be possible to separate a service across more than one physical server and have WCF used on a separate physical tier while maintaining process persistence.
 
Here at TechEd there are many hands-on-labs (HOL) available running concurrently while the other conference sessions are occuring so if you want to dive into something you can jump right in. I was looking at a HOL on Developing Workflow Services via VS 2008. This showcased further .NET 3.5 technology which goes a long way towards replacing the business process functionality of BizTalk. I was amazed that it is possible to expose a WF process as a WCF service and it was very interesting to hear that when a WF sequential process calls a WF state-machine, you can use correlation to coordinate messages between the processes. If you are experienced on BizTalk you can slowly see Microsoft introduce technologies that will eventually replace BizTalk functionality and its interesting determining which ones match BizTalk functions. One area I have been wondering about until today was which WF or WCF technology would handle message correlation for the various forms of message exchange patterns in which correlation is required. This HOL shows how to handle service correlation which should match the BizTalk functionality as long as the integration partner exposes a WCF endpoint.
 
Overall, it has been very interesting today. I will be continuing to post throughout my time here so check back later! Now its time for me to get some food. Bye!

Blog at WordPress.com.

Up ↑