by community-syndication | Mar 18, 2009 | BizTalk Community Blogs via Syndication
We’ve been slowly migrating our services from asmx to WCF, but as we’re still using BizTalk 2006 with no support for WCF we’ve been exposing endpoints configured for basicHttpBinding and consume them using the SOAP adapter.
Generally speaking things have been going well, although we completely gave up on the idea of moving the services to WCF and NOT have to change the client, until yesterday we’ve stumbled into a serialisation issue –
The SOAP adapter, as part of its work deserialises the request message arriving through the send port into t he web service proxy class it generated, before calling the web service (which would result in the class now being serialised back into xml, which is another story); that deserialisation failed.
The error message was clear enough and indicated it failed to deserialise an enum parameter the service was expecting, and that ran a bell – I posted on exactly that back in September, but after carefully checking and re-checking everything we could swear that our message (which was now suspended) matches perfectly the schema generated by the add web reference wizard; what’s going on then??
After chasing our tail for a short while we brought up reflector to the rescue and found out the cause of our woe is a combination of a difference in behaviour between WCF and ASMX and the use of BizTalk – here are the details –
Consider the following asmx web method –
[WebMethod]
public string GetDataUsingDataContract(CompositeType.someEnum myEnum)
{
return "Hello World";
}
With CompositeType being
public class CompositeType
{
public enum someEnum
{
Value1,
Value2
}
}
(..and pretend CompositeType has many more things, but these are irrelevant to this topic)
The definition for myEnum in the WSDL looks like
<s:element minOccurs="1" maxOccurs="1" name="myEnum" type="tns:someEnum" />
Where the type tns:someEnum looks like
<s:simpleType name="someEnum">
<s:restriction base="s:string">
<s:enumeration value="Value1" />
<s:enumeration value="Value2" />
</s:restriction>
</s:simpleType>
As a result the definition of the enum in a proxy generated via the add web reference VS 2005 option (which is what BizTalk would use) looks like –
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.3053")]
[System.SerializableAttribute()]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://tempuri.org/")]
public enum someEnum
{
Value1,
Value2,
}
All makes sense.
Now, let’s look at what WCF does in the same case; consider the following service –
[ServiceContract]
public interface IService1
{
[OperationContract]
string GetDataUsingDataContract(CompositeType.someEnum myEnum);
}
[DataContract]
public class CompositeType
{
public enum someEnum
{
Value1,
Value2
}
}
The WSDL generated looks like
<xs:simpleType name="CompositeType.someEnum">
<xs:restriction base="xs:string">
<xs:enumeration value="Value1" />
<xs:enumeration value="Value2" />
</xs:restriction>
</xs:simpleType>
<xs:element name="CompositeType.someEnum" nillable="true" type="tns:CompositeType.someEnum" />
The key difference is that the name of the class containing the enum has made it into the type name for the enum, which never happened in the ASMX version.
As a result the proxy is generated as such –
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "3.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="CompositeType.someEnum",
Namespace="http://schemas.datacontract.org/2004/07/WcfService1")]
public enum CompositeTypesomeEnum : int
{
[System.Runtime.Serialization.EnumMemberAttribute()]
Value1 = 0,
[System.Runtime.Serialization.EnumMemberAttribute()]
Value2 = 1,
}
Again – note the name given to the element now contains the class name and, crucially, a dot (’.’).
On it’s own – nothing to malicious – although it’s another nail in the coffin for the idea that you can substitute web service with WCF service, configured them to use basicHttpBinding and all should be the same (ok – am I the only one still wishing this was possible?)
Enters BizTalk.
When you use the add web reference wizard to add a reference to the WCF service, BizTalk generates all the schemas and proxy for you, which is what you would use to create requests going to the service (and process responses).
Because the WSDL of the WCF service contains the longer name of the enum (with the class name, the dot and the enum name) the .net proxy generated is identical to the one created for the WCF service above; the schema, however, is generated incorrectly!
BizTalk “kindly” decides that having dots in the element name is not a good idea and removes it so the schema generated looks like this –
<xs:schema xmlns:tns="http://schemas.datacontract.org/2004/07/WcfService1" elementFormDefault="qualified"
targetNamespace="http://schemas.datacontract.org/2004/07/WcfService1"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="CompositeTypesomeEnum" type="tns:CompositeTypesomeEnum" />
<xs:simpleType name="CompositeTypesomeEnum">
<xs:restriction base="xs:string">
<xs:enumeration value="Value1" />
<xs:enumeration value="Value2" />
</xs:restriction>
</xs:simpleType>
</xs:schema>
“CompositeTypesomeEnum”??????
Well, we’ve seen this, and created a message with exactly that element, which – of course – the SOAP adapter failed to deserialise into
[System.Runtime.Serialization.DataContractAttribute(Name="CompositeType.someEnum",
Namespace="http://schemas.datacontract.org/2004/07/WcfService1")]
public enum CompositeTypesomeEnum : int
{
[System.Runtime.Serialization.EnumMemberAttribute()]
Value1 = 0,
[System.Runtime.Serialization.EnumMemberAttribute()]
Value2 = 1,
}
The solution was fairly simple – we’ve simple change our xsl to put the element name as the .net proxy requires it, and not as the schema describes it, and it all worked well.
by community-syndication | Mar 17, 2009 | BizTalk Community Blogs via Syndication
Recently a few of us were speaking about what would be the future of BizTalk after the 2009 release. I already had a few thoughts on what I think would be great additions to the product and what strategic directions it may move in. I have checked to ensure that none of my thoughts breach the MVP NDA and after getting the thumbs up I’ve listed my thoughts below so there might be a bit of discussion on these ideas.
|
Area
|
Thought
|
Notes
|
|
Improved or New Feature
|
Configuration Subsystem
|
Within BizTalk solutions we regularly need to store configuration somewhere for implementing a process. This is a real pain and there are multiple ways this can be done. The main problems are:
- There is no consistently appropriate store
- There is no easy management tool
-
There is no easy way to implement automation with this
I have previously wrote the following article about how we usually do this in the field:
http://geekswithblogs.net/michaelstephenson/archive/2008/05/25/122381.aspx
It would be great if there was a subsystem with BizTalk that would provide a good pattern to do this which addresses the above. This could possibly be an enhancement on top of SSO where the current configuration for ports etc is managed.
|
|
Suggestion
|
Velocity
|
There are a number of places where BizTalk uses caching or should use caching. I think BizTalk should be looking at how Velocity could be leveraged in future versions to make things easier for BizTalk people and also using it under the hood.
I have previously wrote an article about using Ncache with BizTalk Cross Referencing which shows some ways that distributed caching can be taken advantage of:
http://geekswithblogs.net/michaelstephenson/archive/2008/09/21/125353.aspx
And
http://geekswithblogs.net/michaelstephenson/archive/2008/09/21/125352.aspx
I think it could also offer an opportunity to look at this to help you with the low latency question in BizTalk. Possibly by having a distributed in memory message box and the normal database one. You could then do something like a provider pattern and allow a host to choose which kind of message box to work with.
Bit of an out there idea, but food for thought anyway.
|
|
Suggestion
|
Dublin Integration
|
One of the key things for BizTalk from now on in my opinion is how integration with Dublin is utilised and how solutions are developed taking advantages of both products.
I think it could be a good idea to look at how Dublin may take advantage of BizTalk features and visa versa.
Some of my thoughts on what a dublin solution might want to take advantage of from BizTalk are:
|
|
Map Enhancements
|
A whole bunch of thoughts about maps
|
-
Be able to use maps to design mappings without having to implement code. Sort of like an analyst/developer view of the same map
-
Able to easily highlight mapping of a particular field and make other field mappings hidden would be very useful for complex maps
-
Exposing maps using a provider model. This would allow ISV and community mapping tools to plug in as if they were a normal map rather than having to do a custom pipeline component
-
Apply maps at receive location level. This would allow the response messages to be mapped from 1 common message to multiple destinations if you have a request response port
- Allow maps to be applied at receive location level on request response ports (see http://geekswithblogs.net/michaelstephenson/archive/2008/05/09/122024.aspx)
|
|
Schemas/Messages
|
Bunch of suggestions
|
-
Generate message type classes behind the scenes as we always end up doing this anyway and it would be much better if it was just done
-
Support messages defined by dsl’s in M as well as xsd
-
With Generated schemas it would be useful to choose if it adds all of the orchestration and other stuff that you normally just delete once you have finished using the wizard
-
It would be good if you could easily add to your compile tasks to regenerate schemas from a defined contract. As an example I did a post where I regenerate schemas each time I build by pointing to the WSDL from a WCF service. This means if the contract is changed then I know and it breaks my build. We keep the contracts in a central repository usually. The article is below:
http://geekswithblogs.net/michaelstephenson/archive/2008/07/29/124078.aspx
|
|
Pipeline Components
|
Pipeline Component Wizard
|
Implement this as a visual studio component
|
|
Pipelines
|
Get rid of Pipelines
|
I believe that there is no value from the pipeline artefact. If you examine it in reflector you will see a pipeline is simply a class containing a string of xml which is made available as a property. The string of xml is a description of the pipeline components that should be executed.
I would prefer if this artefact was deprecated and instead you would define pipelines through the port bindings where you could list the pipeline components. This would have the benefit of being able to add and remove pipeline components to a port at runtime by an administrator.
It would also be great if in the bindings you could define a list of reusable groups of pipeline components (essentially defining a pipeline in the bindings and being able to reuse it on multiple ports.
The root thing is that in my opinion because the pipeline is just xml under the hood it shouldn’t need to be compiled.
|
|
Orchestrations
|
Again a whole bunch of suggestions
|
-
Allow namespace alias’s to shorten the code in expression shapes
-
Provide a designer view to an orchestration which shows the same kind of detail but in a more simplistic view and which does not require compiling a bit like the old business analyst tool but one that is useful
-
I would like a BAM Quick start, it would be great to be able to just click an orchestration and say report this to BAM and maybe set a few properties and get this reporting in a very simple way. This could be a leader into more complex BAM solutions done in the more traditional way. In most projects I see BAM is not an initial requirement because a customer just wants to implement their core requirements and BAM is seen as more work. If this simple quick start was implemented the a customer would see the benefits of BAM without having to do additional work and would be more likely to buy into a BAM solution early in projects
-
Persistence point indicator for newbies and analysis showing the number of persistence points
-
Patterns wizard in Visual Studio
|
|
BAM
|
Bunch of ideas
|
-
A nicer to use tool than the excel addins for BAM definitions
-
Integrate the generated type bam api tool into Biztalk so when we create a bam definition and it is deployed then an api is generated and added to the GAC for us to use easily from code
-
Is BAM going to stay in BizTalk or it is possibly better positioned as a SQL BI Component especially since it can commonly be plugged into from WF and WCF
-
A better web interface for BAM Portal
-
Sort out the BAM Notification dependancy on SSNS which currently means you need to download a old SQL 2005 component
-
It would be great if BAM was using some reporting services stuff from SQL Server and an easy model was provided to add new SQL Reports to the BAM Portal
-
Provide an easy way to incorporate BAM into your build process (see http://geekswithblogs.net/michaelstephenson/archive/2008/06/15/122870.aspx)
|
|
BRE
|
Bunch of suggestions
|
-
Provide a ws interface for Business rules to expose them for use in other applications. I’ve seen some projects where they have spent a money on just a business rules server. If BizTalk rules were easily exposed and available to other applications then it would be another cool feature for the enterprise.
-
The roadmap of BizTalk versus WF Rules is unclear. However the above comment could make Rules available as an enterprise service regardless of them being WF or BTS based.
- A web interface to allow Business users to view rules that have been executed to see how they were evaluated
|
|
Deployment
|
Bunch of suggestions
|
-
Samples and guidance for automated installs and server builds would be great in Vnext documentation
-
Ability to export Biztalk application as a WIX package to allow easier extension of the msi
-
Include the manual tasks as part of the group configuration process (eg: setting up SQL Jobs). This means when the group is installed and configured there shouldn’t need to be any manual tasks than an administrator needs to go chasing to do (or often forgets to do).
-
Deployment topology patterns which can help apply a lot the optimisations at setup rather than them having to be manually done
-
By default create a separate host dedicated for tracking called “Tracking Host” or run the jobs of the TDDS process in a background service which can not be misused through the BizTalk admin console. Everyone always does this anyway but it sometimes gets forgotten
|
|
Application Life Cycle
|
Bunch of suggestions
|
-
Easier to implement versioning
This is a bit of a nightmare to do properly at the moment and lots of times it is frightened away from. I’ve wrote the following about how we did it: http://geekswithblogs.net/michaelstephenson/archive/2008/12/18/128030.aspx
-
All management stuff should be made available by a managed API. At present it’s a combination of executables, WMI, managed API etc. It should be consistent and simple so anything not done out of the box can easily be done by extending the set of build tasks etc.
-
Would be great if we can have a set of MsBuild tasks and powershell scripts for the common tasks
-
Integration of orchestration profiler into Visual Studio
-
Integration of BizTalk documenter into Admin Console
- Integration of Best Practice Analyser and Messagebox Viewer into BizTalk Admin console
|
|
Binding Files
|
Another bunch of suggestions
|
-
A designer for binding files so you don’t always have to import them into BizTalk to edit them, you should be able to just open an xml file containing bindings in visual studio and edit them through a designer
-
Support for tokenised bindings to make it easier to configure between environments. Ive written an article about how we do this now:
http://geekswithblogs.net/michaelstephenson/archive/2008/01/27/118963.aspx
And
http://geekswithblogs.net/michaelstephenson/archive/2008/12/18/128024.aspx
-
An option to export sensitive data such as passwords if desired. It is sometimes a complete pain when the passwords are omitted. By default only the BizTalk Administrator can do this so he should be able to choose if he/she wants to hide passwords
-
A set of reusable tokenised values which are defined at application level and can then be referenced from Binding values
|
|
Operations
|
More –>
|
|
|
HAT
|
|
|
|
Cross Referencing
|
Bunch of suggestions
|
-
Expose Xref as a web service so it can be used by other applications
-
Improve the tools for managing BizTalk Cross Reference, there is currently none
-
Expose Xref in a management web site to allow non biztalk people to view it
-
Have a way of being able to map data when it doesn’t really match the restrictive xref model. Maybe this includes adding new tables or something. We always have to do custom databases for this
- Allow easy automation of loading xref data. Its not that great at the minute
|
by community-syndication | Mar 17, 2009 | BizTalk Community Blogs via Syndication
Over the past several months, I've been posting numerous screencasts on the WCF 3.5 REST programming model, the WCF REST Starter Kit (both Preview 1 and Preview 2), and their various features. I thought it might be helpful to provide readers with a consolidated index at this point:
WCF 3.5 REST Screencasts
- Building RESTful Services with WCF – Part 1
- Building RESTful Services with WCF – Part 2
- Calling RESTful Services with WCF
WCF REST Starter Kit Preview 1 Screencasts
- Getting started with the WCF REST Starter Kit (Preview 1)
- A lap around the new API extensions – Part 1
- A lap around the new API extensions – Part 2
- Resource singleton services
- Resource collection services
- Atom feed services
- AtomPub services
- HTTP plain XML (POX) services
- Multiple resource representations
- Implementing X-HTTP-Method-Override
WCF REST Starter Kit Preview 2 Screencasts
- Getting started with the WCF REST Starter Kit (Preview 2)
- Using HttpClient to consume Twitter in under 3 minutes!
- Consuming REST services with HttpClient
- HttpClient: Query string and form input
- HttpClient: Processing message content
by community-syndication | Mar 17, 2009 | BizTalk Community Blogs via Syndication
I recently published a new screencast video on Processing message content with HttpClient. Check out this post for more background.
This screencast shows you how to process different types of messages that you might get back from RESTful services on the Web. It shows how to use XLinq, DataContractSerializer, and XmlSerializer, and it shows how to process XML, Atom, and JSON messages.
Check out our growing collection of free .NET screencasts and videos. You can subscribe to the Pluralsight feed to be notified when new screencasts are published. In addition, check out our growing library of Pluralsight On-Demand! training courses.
