Interoperability Using Windows Communication Foundation (WCF)


The Windows Communication Foundation (WCF), formerly known as Indigo, is the long-term solution from Microsoft for connected systems. It provides APIs that subsume Web services, remoting, messaging and all other connectivities. It is built around Web services architecture and is designed to provide secure, reliable, and transacted messaging along with interoperabilitybased on open standards. It is intended to span across multiple transports, security systems, messaging patterns, encodings, network topologies, and hosting models. It will be at the core of the upcoming Windows Vista (formerly Longhorn) series as well as have backward support for Windows XP and Windows Server 2003. Due for release in 2006, WCF is intended to interoperate cleanly with all systems (including Java EE systems), but as it evolves it is worth monitoring over time to prove out its adherence to standards before the decision is made to use or deploy it in a diverse system.

WCF is Microsoft's next generation "unified" programming platform as well as runtime environment that supersedes various technologies including ASP.NET Web services (ASMX) with WSE extensions, Microsoft Message Queue (MSMQ), the Enterprise Services / COM+ runtime environment and .NET Remoting. It addresses the limitation of RPC-based or synchronous Web services, where RPC-based Web services are invoked over HTTP/S (with limited support of transport protocol bindings) and is limited to the request-reply communication model (limited invocation mechanism).

To build a service in WCF, developers need to know the service address (for example, where the service is), the service binding (the data transport protocol such as SOAP over HTTP), and the service contract (for example, what kind of data should be passed). Developers can use an IDE (such as Visual Studio 2005) to build and test their application codes. In addition, they need to define the services (for example, type of services or service endpoints), behaviors (for example, how the service should interact under particular circumstances) and bindings (and binding types) in the file called web.config before the service can be created and deployed. Developers can also use svcutil.exe, an import and export tool for converting between service meta-data and application codes, to create proxy codes for the client.

WCF does not just add new programming APIs or new functionality. It provides different programming approaches to build services, but not necessarily Web services. (Refer to [PALLMANN] for details.)

  • Declarative Programming In declarative programming, developers define specific attributes and interfaces, which are the key "data contract" between service requesters and service providers. In WCF, "service contracts" are used to specify session requirements and service operation direction using parameters.

  • Imperative Programming Using data object models derived from the application programming interfaces provided by WCF, developers can use object-oriented programming to create and access services or extend existing services easily. In WCF, developers can also define "channels" to support a different transport or protocol. WCF channels connect the service model layer with the actual data on the wire. There are two different types of WCF channels: transport channels (responsible for sending and receiving data) and protocol channels (that implement specific message exchange protocols). This provides flexibility and extensibility for WCF applications to integrate and interoperate with different platforms (such as Java EE applications) that use different messaging protocols.

  • Configuration-Based Programming Developers can specify part of an application's behavior (such as addresses, bindings, security details, or service behavior) in configuration files. This allows the runtime to make deploy-time decisions about services without rewriting the application codes.

WCF is fairly complex and is still evolving before the final release. It is much more powerful in its interoperability features than WSE or other .NET technologies. For example, WCF supports MTOM, Metadata Exchange or MEX (refer to Chapter 13, "Java EE .NET Security Interoperability," for details), and SAML 1.1. These are fairly significant interoperability features. From an interoperability perspective, it is important to understand that it provides flexible programming approaches to build services and interacts (and interoperates) with Web services implemented in different protocols and technologies. Table 2-1 summarizes the .NET interoperability capabilities of ASMX, WSE, and WCF (refer to [Chappell2005] and [msdn2005]).

Table 2-1. Interoperability Capabilities by .NET Technologies

Category

Protocol/Technology

ASMX 1.x

ASMX 2.0

WSE 2.0

WSE 3.0

WCF

Core

WSI Basic Profile 1.1

Yes

Yes

Yes

Yes

Yes

 

SOAP 1.1

Yes

Yes

Yes

Yes

Yes

 

SOAP 1.2

 

Yes

 

Yes

Yes

Opaque

WS-Addressing

  

Yes

Yes

Yes

Data

DIME

  

Yes

 

Transfer

MTOM

   

Yes

Yes

Other

TCP

  

Yes

Yes

Yes

Transports

UDP

    

and

HTTP

Yes

Yes

Yes

Yes

Yes

Encodings

MSMQ

    

Yes

 

Named pipes

    

Yes

 

Text-XML

Yes

Yes

Yes

Yes

Yes

 

Binary-encoded XML

    

Yes

 

Binary serialization

  

Yes[*]

Yes[*]

 

Security

WS-Security 1.0

  

Yes

Yes

Yes

 

WS-Security 1.1

   

Yes

Yes

 

WS-SecureConversation

  

Yes

Yes

Yes

 

WS-Trust

  

Yes

Yes

Yes

 

WSI Basic Security Profile 1.0

  

Yes

Yes

Yes

 

SAML1.1

    

Yes

Reliability

WS-ReliableMessaging

    

Yes

Transactions

WS-Coordination

    

Yes

 

WS-AtomicTransaction

    

Yes

Metadata,

WS-MetadataExchange

    

Yes

Policy and

or MEX

     
 

WSDL 1.1

Yes

Yes

Yes

Yes

Yes

 

WS-Policy

    

Yes

 

WS-PolicyAttachment

    

Yes

 

WS-SecurityPolicy

    

Yes

 

WS-ReliabilityPolicy

    

Yes


[*] Custom WSE-specific serialization, not compatible with WCF.




Java EE and. Net Interoperability(c) Integration Strategies, Patterns, and Best Practices
Java EE and .NET Interoperability: Integration Strategies, Patterns, and Best Practices
ISBN: 0131472232
EAN: 2147483647
Year: N/A
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net