In my previous post I had discussed the differences between WCF and Web-Services. In this post I am going to show the difference between the various bindings in the WCF.
Class name
Description
Transport
Message encoding
Security
BasicHttpBinding
A binding that is suitable for communication with WS-Basic Profile conformant Web Services like ASMX-based services. This binding uses HTTP as the transport and Text/XML as the message encoding.
HTTP
Text
None
WSHttpBinding
A secure and interoperable binding that is suitable for non-duplex service contracts.
HTTP
Text
Message
WSDualHttpBinding
A secure and interoperable binding that is suitable for duplex service contracts or communication through SOAP intermediaries.
HTTP
Text
Message
WSFederationHttpBinding
A secure and interoperable binding that supports the WS-Federation protocol, enabling organizations that are in a federation to efficiently authenticate and authorize users.
HTTP
Text
Message
NetTcpBinding
A secure and optimized binding suitable for cross-machine communication between WCF applications
TCP
Binary
Transport
NetPeerTcpBinding
A binding that enables secure, multi-machine communication.
P2P
Binary
Transport
NetNamedPipesBinding
A secure, reliable, optimized binding that is suitable for on-machine communication between WCF applications.
Named Pipes
Binary
Transport
NetMsmqBinding
A queued binding that is suitable for cross-machine communication between WCF applications.
MSMQ
Binary
Message
MsmqIntegrationBinding
A binding that is suitable for cross-machine communication between a WCF application and existing MSMQ applications.
MSMQ
doesn’t use a WCF message encoding – instead it lets you choose a pre-WCF serialization format
Transport
Further the most commonly used binding are BasicHttpBinding andWsHttpBinding. The difference between these two is as follows:
Criteria
BasicHttpBinding
WsHttpBinding
Security support
This supports the old ASMX style, i.e. WS-BasicProfile 1.1.
This exposes web services using WS-* specifications.
Compatibility
This is aimed for clients who do not have .NET 3.0 installed and it supports wider ranges of clients. Many of the clients like Windows 2000 still do not run .NET 3.0. So older version of .NET can consume this service.
As its built using WS-* specifications, it does not support wider ranges of client and it cannot be consumed by older .NET version less than 3 version.
Soap version
SOAP 1.1
SOAP 1.2 and WS-Addressing specification.
Reliable messaging
Not supported. In other words, if a client fires two or three calls you really do not know if they will return back in the same order.
Supported as it supports WS-* specifications.
Default security options
By default, there is no security provided for messages when the client calls happen. In other words, data is sent as plain text.
As WsHttBinding supports WS-*, it has WS-Security enabled by default. So the data is not sent in plain text.
Ever since the launch of Biz Talk Server 2009 there has been some confusion over the features and functionalities that were in Biz Talk Server 2006 and those that are in Biz talk server 2009. Here I am going to touch upon some important points which would make clear that what all has changed or have been upgraded.
The following component/feature has been deprecated and no longer available in Biz Talk Server 2009:
BizTalk Deployment Command Line Tool
HWS Design Tools
Human Workflow Services Runtime Components
Human Workflow Services Base Assemblies
Human Workflow Service Administration Tools
BAS Schema Editor Extension
BizTalk Message Queuing
Deployment Wizard
Health and activity monitoring tool (Moved to BTS Admin Console)
Also the following features/Components has been deprecated:
VS ExplorerUI (BizTalk Explorer)
Web Services Publishing wizard (ASMX)
Line of Business Adapters for SAP/Oracle DB/Siebel
The old SQL Server Adapter
Base EDI Adapter(exists as Standard EDI Adapter)
BTS Accelerator for HIPAA (exists as EDI feature)
Web Services Enhancements adapter WSE (Replaced by WCF)
MSMQt Adapter (newMSMQ adapter)BTSDeploy.exe Utility (replaced by BTSTask.exe)
From now on there is support for Windows 7 and windows 2008 r2, also support for Visual Studio 2010 as expected, from the previous release a platform shift is required.
The BizTalk Administration console has gone for a few enhancements, making it easier to use particularly in live production environments, where lots of things might be happening at once, adding to the cool things in 2009, when HAT went away and tracking was available from the administration console.
The BizTalk mapper has had a few enhancements, things you would have thought should have been there long ago, and there are still many improvements here that never made it out of the product group that would make life much nicer.
FTP you say, we have been asking for SFTP for a long time, I hear whispers that it might be in this release… along with a whole bunch of new FTP features, keep your mouth open for this one, it looks good to me.
There are some new features introduced, and some enhancements to existing features, not as many as I would have liked… These lie round EDI, there is a focus on making this better in each release as we saw in 2009. EDI is not dead, just as Cobol is not dead.
There are plans to deprecate some features, why you would want to do this? However there are plans, not major or drastic, and you will have to wait and see all of them.
The SOAP Adapter is on the cards for removal, replaced by the WCF-BasicHttp, there is some contention amongst the industry as this adapter still provides some features not found in WCF.
SQL Adapter, this has been coming for some time and nothing thats not expected with most adapters, the old SQL Adapter may go and be replaced by a WCF SQL Adapter.
New Web Services Registry UDDI (Universal Description, Discovery, Integration) includes a UDDI 3.0 registry which provides support for registry affiliation, extended discovery services, digital certificates and extensibility for a subscription API.
New Messaging Changes
Recoverable interchange (XMLValidator, map – SuspendMessageOnMappingFailure property)
Choose the transaction isolation level in the WCF-Custom Send Adapter
Support for .NET Framework 3.5 SP1 and Visual Studio 2008 SP1
Support for Windows Server 2008 , and for sure support for the Hyper-V virtualization that provide the meaning of reducing the costs through lower hardware, energy, and management overhead, plus providing a dynamic IT infrastructure.
Improved Failover Clustering, By taking advantage of Windows 2008 clustering, BizTalk Server is now able to be deployed in multi-site cluster scenarios, where cluster nodes could reside on separate IP subnets and avoid complicated VLANs.
Support for SQL 2008 has also been included in Biz Talk Server 2009.
New Adapters have been introduced:
Oracle E-Business Suites
SQL Server (much improved over the existing SQL adapter)
Host Integration Server 2009 & BizTalk Adapters for Host Systems (BAHS) 2.0
New WCF WebSphere MQ channel to integrate directly with WebSphere MQ.
New WCF Service for Host Applications has been added to expose the traditional Transaction Integrator to .NET Framework developers.
Support for the most recent versions of CICS, IMS, CICS HTTP transport, DB2, DB2/400, DB2 Universal Database, and WebSphere MQ.
Support for Team Foundation Server (TFS), now the development teams can automate builds, bug tracking, Project Server integration, source control and team development support
Standard used for creating Web service registries.
Provide new ESB Guidance plugins inside Visual Studio 2008, ESB Guidance 2.0 that is used for applying ESB usage patterns, improved itinerary processing, itinerary modeling using a visual Domain Specific Language (DSL) tools approach also it comes with enhanced ESB management portal.
BizTalk 2009 has the same failover clustering capabilities as Windows Server 2008 for greater reliability
Enhanced Business Activity Monitoring , the combination of BizTalk 2009 and SQL 2008 provide support for UDM cubes and scalable real-time aggregations which enhances support for Microsoft PerformancePoint Server 2007
Connectivity with intelligent RFID devices:
Support for RFID 1.1
BizTalk RFID extended to Mobile Devices
Support for key industry standards
Enables using new readers with LLRP (Low Level Reader Protocol)
Machine readable tag data standards (TDT for EPC)
Web Services for device management and Discovery, Configuration, Initialization (DCI)
WS Discovery and partial EPCIS support
Enhanced support for EDI and AS2
BizTalk Server 2009 is the sixth formal release of the BizTalk Server product. This upcoming release has a heavy focus on platform modernization through new support for Windows Server 2008, Visual Studio.NET 2008, SQL Server 2008, and the .NET Framework 3.5. This will surely help developers who have already moved to these platforms in their day-to-day activities but have been forced to maintain separate environments solely for BizTalk development efforts.
The new WCF Sql Adapter
The BizTalk Adapter Pack 2.0 now contains five system and data adapters including SAP, Siebel, Oracle databases, Oracle applications, and SQL Server. What are these adapters and how are they different than the adapters available for previous version of BizTalk?
Up until recently, BizTalk adapters were built using a commonly defined BizTalk Adapter Framework. This framework prescribed interfaces and APIs for adapter developers in order to elicit a common look and feel for the users of the adapters. Moving forward, adapter developers are encouraged by Microsoft to use the new WCF LOB Adapter SDK. As you can guess from the name, this new adapter framework, which can be considered an evolution of the BizTalk Adapter Framework, is based on WCF technologies.
All of the adapters in the BizTalk Adapter Pack 2.0 are built upon the WCF LOB Adapter SDK. What this means is that all of the adapters are built as reusable, metadata-rich components that are surfaced to users as WCF bindings. So much like you have a wsHttp or netTcp binding, now you have a sqlBinding orsapBinding. As you would expect from a WCF binding, there is a rich set of configuration attributes for these adapters and they are no longer tightly coupled to BizTalk itself. Microsoft has made connection a commodity, and no longer do organizations have to spend tens of thousands of dollars to connect to line of business systems like SAP through expensive, BizTalk-only adapters.
This latest version of the BizTalk Adapter Pack now includes a SQL Server adapter, which replaces the legacy BizTalk-only SQL Server adapter. What do we get from this SQL Server adapter that makes it so much better than the old one?
Feature
Classic SQL Adapter
WCF SQL Adapter
Execute create-read-update-delete statements on tables and views; execute stored procedures and generic T-SQL statements
Partial (send operations only support stored procedures and updategrams)
Yes
Database polling via FOR XML
Yes
Yes
Database polling via traditional tabular results
No
Yes
Proactive database push via SQL Query Notification
No
Yes
Expansive adapter configuration which impacts connection management and transaction behavior
No
Yes
Support for composite transactions which allow aggregation of operations across tables or procedures into a single atomic transaction
No
Yes
Rich metadata browsing and retrieval for finding and selecting database operations
No
Yes
Support for the latest data types (e.g. XML) and SQL Server 2008 platform
No
Yes
Reusable outside of BizTalk applications by WCF or basic HTTP clients
No
Yes
Adapter extension and configuration through out of the box WCF components or custom WCF behaviors
No
Yes
Dynamic WSDL generation which always reflects current state of the system instead of fixed contract which always requires explicit updates
No
Yes
Video Tutorial
A good video tutorial that describes the changes is as follows :
This topic discusses features new to Windows Communication Foundation (WCF).
Configuration Based Activation
Normally when hosting a Windows Communication Foundation (WCF) service under Internet Information Services (IIS) or Windows Process Activation Service (WAS), you must provide a .svc file. The .svc file contains the name of the service and an optional custom service host factory. This additional file adds manageability overhead. The configuration-based activation feature removes the requirement to have a .svc file and therefore the associated overhead. For more information, see Configuration-Based Activation in IIS and WAS, Configuration-Based Activation.
System.Web.Routing Integration
When hosting a Windows Communication Foundation (WCF) service in IIS, you place a .svc file in the virtual directory. This .svc file specifies the service host factory to use as well as the class that implements the service. When making requests to the service you specify the .svc file in the URI, for example: http://contoso.com/EmployeeServce.svc. For programmers writing REST services, this type of URI is not optimal. URIs for REST services specify a specific resource and normally do not have any extensions. The System.Web.Routing integration feature allows you to host a WCF service that responds to URIs without an extension. For more information, see System.Web.Routing Integration, SystemWebRouting Integration Sample.
Multiple IIS Site Bindings Support
When hosting a Windows Communication Foundation (WCF) service under Internet Information Services (IIS) 7.0, you may want to provide multiple base addresses that use the same protocol on the same site. This allows the same service to respond to a number of different URIs. This is useful when you want to host a service that listens on http://www.contoso.com and http://contoso.com. It is also useful to create a service that has a base address for internal users and a separate base address for external users. For more information, see Supporting Multiple IIS Site Bindings,
Routing Service
The Routing Service is a generic SOAP intermediary that acts as a message router. The core functionality of the Routing Service is the ability to route messages based on the message content, which allows a message to be forwarded to a client endpoint based on a value within the message itself, in either the header or the message body. For more information, see Routing, Routing Services .
Support for WS-Discovery
The Service Discovery feature enables client applications to dynamically discover service addresses at runtime in an interoperable way using WS-Discovery. The WS-Discovery specification outlines the message exchange patterns (MEPs) required for performing light-weight discovery of services, both by multicast (ad hoc) and unicast (utilizing a network resource). For more information, see WCF Discovery, Discovery (Samples).
Support for HTTP Decompression
WCF clients now have built-in support for HTTP decompression. A client can decompress received messages that were compressed with the gzip/deflate format.
The following table contains links that instruct how to enable an IIS server for compression.
By default, a WCF client sends an Accept-Encoding header to the server to notify that it can decompress data. This default behavior can be turned off by creating a custom binding based on the HttpTransportBindingElementand setting the DecompressionEnabled property to false.
Standard Endpoints
Standard endpoints are pre-defined endpoints that have one or more of their properties (address, binding, contract) fixed. For example, all metadata exchange endpoints specify IMetadataExchange as their contract, so the developer does not have to specify the contract. The standard MEX endpoint therefore has a fixed IMetadataExchange contract. For more information, see Standard Endpoints, .
Workflow Services
With the introduction of a set of messaging activities, it is easier than ever to implement workflows that send and receive data. These messaging activities allow you to model complex message exchange patterns that go outside of the traditional send/receive or RPC-style method invocation. For more information, see Workflow Services, Services, Services.
Target Framework Attribute
The target framework attribute is used to specify the version of the .NET Framework an application hosted in IIS or WAS is targeting. It allows you to build applications that target .NET Framework 2.0, 3.5, or 4 using Visual Studio. It is an attribute set within a <compilation> tag in an application's Web.config file as shown in the following example.
When an application hosted in IIS or WAS targets a version of the .NET Framework that is not installed, an exception is thrown that indicates the problem. If the target framework moniker is not specified in the application's Web.config file, the value is inferred from the application pool version configured in IIS.
Because of this new feature, if you try to host a WCF service written with .NET Framework 3.5 on a machine running .NET Framework 4, you may get a ProtocolException with the following text:
Unhandled Exception: System.ServiceModel.ProtocolException: The content type text/html; charset=utf-8 of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 1024 bytes of the response were: ' ...
The .NET Framework 4 enables you to leverage the declarative caching mechanism already available in ASP.NET in your WCF REST services. This allows you to cache responses from your WCF REST service operations. When a user sends an HTTP GET to your service that is configured for caching, ASP.NET sends back the cached response and the service method is not called. When the cache expires, the next time a user sends an HTTP GET, your service method is called and the response is once again cached.
The .NET Framework 4 also allows you to implement conditional HTTP GET caching. In REST scenarios a conditional HTTP GET is often used by services to implement intelligent HTTP caching as described in the HTTP Specification. For more information, see Caching Support for WCF Web HTTP Services, Caching and Automatic Help Page.
Formats Support
The WCF web HTTP programming model allows you to dynamically determine the best format for a service operation to return its response in. Responses can be set automatically for XML and JSON based on the accept header. Helper APIs have been added to programmatically set the format of an operation. For more information, see WCF Web HTTP Formatting, Automatic Format Selection, Advanced Format Selection.
HTTP REST Error Handling
WCF web HTTP error handling enables you to return errors from WCF REST services that specify an HTTP status code and return error details using the same format as the operation (for example, XML or JSON). For more information, see WCF Web HTTP Error Handling, .
Deployment Features
The configuration needed to run a service has been simplified and new standard endpoints have been introduced to further simply service configuration. For more information about the new simplified configuration see, Simplified Configuration. For more information about standard endpoints see, Standard Endpoints.
When hosting a Windows Communication Foundation (WCF) service in IIS you place a .svc file in the virtual directory. This .svc file specifies the service host factory to use as well as the class that implements the service. When making requests to the service you specify the .svc file in the URI, for example: http://contoso.com/EmployeeServce.svc. For programmers writing REST services this type of URI is not optimal. URIs for REST services specify a specific resource and normally do not have any extensions. The System.Web.Routing integration feature allows you to host a WCF REST service that responds to URIs without an extension. For more information, see System.Web.Routing Integration.
Cross Domain JavaScript
JSON Padding (JSONP) is a mechanism that enables cross site scripting support in web browsers. JSONP is designed around the ability of web browsers to load scripts from a site different from the one the current loaded document was retrieved from. The mechanism works by padding the JSON payload with a user-defined callback function name, for example:
callback({ “a” = \“b\” });
In the above example the JSON payload, {“a” = \”b\”}, is wrapped in a function call, callback. The callback function must already be defined in the current web page. The content type of a JSONP response is “application/javascript”. For more information, see JSONP.
WCF REST Service Help Page
.NET Framework version 4 provides an automatic help page for WCF REST services. This help page lists a description of each operation, request and response formats, and schemas. For more information, see WCF Web HTTP Service Help Page, Caching and Automatic Help Page.
