Before I start with Windows Communication Foundation I would like to give a brief history tour of what I have encountered over the years the direction Microsoft is taking with regards to distributed systems/communication.
DCOM/MTS/COM+/MSMQ/JMS/.NET Remoting/BizTalk/Web Services ……
Microsoft introduced the DCOM architecture for distributed systems and it was its vision to use that as a standard within the Microsoft product suites for distributed communication. In the mean time the open source communities was trying to push for CORBA (Microsoft as well, although half-heartedly was supporting it, not that I blame Microsoft, if I invent something I would want the client to buy the item from my store, what’s wrong with that mind-set)
Java thought it should also do something different and hence came up with RMI. Everyone was trying to address the one big problem, how do we come up with a standard that will allow distributed communication but everyone was thinking for their own platforms (DCOM for Microsoft, RMI for Java). CORBA did start out as the first step towards accomplishing distributed communication across heterogeneous environments. It how ever lacked the support from the giants over a period of time (remember everyone wants to sell their own product mentality).
Microsoft and Java also came out with standards to provide asynchronous communication MSMQ/JMS (still trying to sell their own product).
Microsoft came out with a fancier distributed standard terminology called COM+ (The plus is just their way of saying we merged all our earlier standards like DCOM, MTS etc and added a few more features so that the developers will have to learn and learn for ever, and the recruiters now have something more to demand) and then finally .NET Remoting (their managed code saga, with all the leaks in C++ code written by clumsy developers, they learned from Java the mantra of managed code, although VB programmers were already in some areas benefiting from that, more specifically they did not have to worry about memory management related issues like C++ programmers had to).
Microsoft as well as Java had standards around transaction management (MTS and JTS), Microsoft got ride of the term MTS and now they have that built in to the COM+. JTS is Java’s specification which keeps evolving with releases as well.
BizTalk was used by Microsoft primarily as a Middleware Solution to provide collaboration between heterogeneous systems (Mainframe, Unix, Windows etc) by providing adapters that can talk with those specific environments and then doing some XML/XSLT to do some translation before forwarding the information to the other environment (think of BizTalk as a traffic police). There are many heavy weights in this middleware quadrant and really BizTalk falls more in the middleware technologies versus distributed systems/communication. But I thought of mentioning it just to give an idea.
Then came a beacon of light, Web Services and everyone was talking about how we can sell products from other stores as well as ours; in short, how do we have a distributed communication that is truly platform independent. Now wasn’t CORBA suppose to achieve that, in theory yes; however; it was a much more complicated implementation for the broader community to understand and adapt. Web services used the XML fever and used terms like SOAP, WSDL to provide some standards around distributed communication over the internet (wow I am already excited). Microsoft and Java both were fed up of fighting so they also accepted Web services with a caveat. Their earlier implementation specifications were not exposing Web services that can be easily consumed by each other; resulting in the existence of Basic Profile (BP) (I might have the facts wrong it could be BP and then the issue). Anyways, Web Services also lead to the concept called Service Oriented Architecture (SOA) and everyone was hooked up to SOA which brings me to my next section “What is SOA?”
What is SOA?
SOA stands for Service Oriented Architecture, as if that’s going to tell anything. Before I start describing the theory it’s important that we understand what the “Service” part of SOA means. First of all “Service” does not automatically means “Web Services”, Web Services can be considered as one possible implementation option for SOA applications; although not the only one, remember I still haven’t talked about Windows Communication Foundation (WCF). Think of service in the context of business and try to build SOA applications by putting the hat of a business analyst and ask yourself the question what part of my business could serve as a service to others. A simple example will be Stock Analysis Service (its purpose could be to provide you with some statistical analysis of a particular stock, Mutual Fund, ETF etc). The data within that service could be exposed as XML message (SOAP).
The theory
The four tenets of SOA are
• Tenet 1: Boundaries Are Explicit
• Tenet 2: Services Are Autonomous
• Tenet 3: Services Share the Schema and Contract, Not the Class
• Tenet 4: Service Compatibility Is Based on Policy
I am not going to describe everything about SOA, do some goggling and you will have tons and tons of articles talking about SOA as a concept. But, the long story short in all these articles is to remember what the “Service” in SOA stands for; and try to build SOA applications with that in mind. With that I finally move to WCF
What is WCF?
I keep thinking WCF stands for Windows Communication Framework, but it’s actually Windows Communication Foundation.
Microsoft finally decided it’s long since they have talked about change so they came up with WCF as the new buzz word for distributed communication. WCF provides a unified programming model for service oriented applications. If you have worked on .NET Remoting then some of the terms used to define WCF components (like channel) will help you understand where Microsoft is heading with WCF. However, the similarity stops there, WCF provides a much decoupled architecture than .NET Remoting and also provides the promise of supporting DCOM, MSMQ, COM+, Windows Services, .NET Remoting etc the earlier standards defined within the context of distributed architecture/communication. So what’s the difference now, let’s start by asking yourself a question, if you have a requirement where you do not want to change code and at the same time affect the behavior of the methods/functions exposed by your components how will you design your component interfaces. One possible answer will be to
o Define generic data types as arguments
o Send data as XML
o Make the methods refer to a configuration file so that changing the contents of the file will result in different behavior
I am pretty sure as an architect you might have designed your application component interfaces using some of the above mentioned techniques at some point of time.
Now WCF provides that as a standard unified programming model. When you work with WCF think of data as messages (SOAP, XML, REST) and think of WCF methods exposing data as messages (SOAP, XML, REST) versus thinking in the traditional terms like interface with .NET specific data types. In fact, think of messages and XSD schemas versus classes and objects when information is passed between WCF services and WCF clients. WCF service will expose data types that are never .NET specific but the data types will be defined in the context of XSD schema (once again think of schemas and not classes).
Basics building blocks of WCF Services
WCF was introduced as a part of .NET framework 3.0 and 3.5. The basic building blocks of WCF include
o Service – this is the exposed business interface (remember this is a concept – think as a business analyst)
o Service Contract – this defines the methods/functions exposed by the interface along with signature
o Data Contract – used to map complex .NET data types to corresponding XSD data types (remember messages should not contain any .NET specific data types)
o Endpoints – Applications define one or more endpoints for a WCF service and that’s how they make the WCF service available to the clients. Endpoints define the - Address of the service, the Binding supported by service, and the Service Contract implemented by Service. The term “ABC” is typically used to define how a WCF Endpoint is exposed. “A” stands for “Address, “B” stands for Binding and “C” stands for “Contract”
o Bindings - they identify how a service and client endpoints communicate with each other. You can define them declaratively in code or in a configuration file the later provides more decoupling from code. You can do both, but the code settings will override what’s in the configuration file (If you have worked on J2EE and JEE 5/6 then this should be familiar territory, remember Java annotation and all the configuration files of Java web.xml, ejb-jar.xml, application.xml etc.) Binding will provide information such as Transport (HTTP, TCP etc), Protocol (Security, Transaction etc), message encoding (text, binary etc) used for the WCF service at both ends (client as well as server hosting the WCF service). WCF provides tons of out of the box WCF bindings BasicHttpBinding, WSHttpBinding, NetTcpBinding etc.
WCF Hosting Options
WCF services need a hosting environment to expose the WCF services to the client. If you have done .NET Remoting then you know what I am talking about, .NET Remoting server component can be hosted in a console application, IIS or a windows service). WCF service also provides a variety of hosting options
o Stand-alone console application (also referred to as self-hosting)
o Windows Service
o IIS – this supports only HTTP protocol.
o Windows Process Activation Service (WAS) – only supported in Vista or Windows Server 2008 – this is my preference as it not only supports HTTP but also supports other protocols like TCP plus provides the benefit of application pooling and all the other things IIS provides minus the need for Web Server.
One difference between .NET Remoting and WCF hosting is that in WCF hosting you can use the configuration files to define and configure the service/hosting behaviors. .NET Remoting does not provide such granular standard (not that I am implying you cannot define your own configuration files to decouple some of the deployment related changes that you may have to do as you move from one application environment to another, WCF on the other hand however gives that to you, this is one more way of decoupling the various moving parts of WCF from each other providing better flexibility)
The beauty of WCF is that if you define a WCF service that is exposing some business functionality which needs to be accessed in an intranet environment, you will typically host the WCF service in WAS or Windows Service and use TCP as the transport channel. You can also decide not to use SOAP but rather REST just to avoid the verbose nature of the SOAP protocol. Down the road say you want to expose this WCF service via HTTP you can configure IIS to host the WCF Service and expose the information via HTTP(S); with no coding changes. That’s the beauty of decoupling WCF provides.
SOAP and its use in WCF
As I mentioned earlier, WCF uses messages to exchange data and since SOAP (Simple Object Access Protocol) is all about messages, its obvious that it is the accepted message format in most of the WCF implementations I have worked on. SOAP came into existence when the fever of Web Services was high and was used as a standard for exchanging data between web services and its clients. WCF does not restrict you to use SOAP you can also use REST or define your own format but I would suggest the use of SOAP as it’s an accepted standard. The only place where you should consider alternative is if you are worried about performance, but trust me 95% of the time SOAP is fine.
If you use SOAP then all the SOAP format standards that apply to SOAP like envelops, body, faults etc apply in WCF as well.
WCF Sessions, Transactions and Security
WCF allows Sessions and define bindings that support Sessions (e.g. NetTCPBinding, WsDualHttpBinding etc)
Now if you have worked with EJB or with .NET Remoting you will understand what Instancing means. In the context of WCF it refers to the lifetime of the WCF Service instance. Following three options are supported
o PerCall
o PerSession
o Single
Does it not ring a bell (.NET Remoting has something similar, EJB in Java have stateless, stateful beans)
WCF has tons of attributes (NOTE: Microsoft allows declarative configuration via attributes, Java does it via annotation – wow how innovative) that you can define within code as well as in configuration files to control the Session behavior for a service.
WCF also allows transactions and have attributes that can define transaction boundaries as well as API that can help you define the outcome of a transaction. If you have worked in COM+ or in EJB, the WCF transaction capabilities will be easier to understand.
WCF allows security to be defined at
o Transport level – the transport layer is used to encrypt the message as well as pass security information. Typically NetTcpBinding is used for this.
o Message level – the message is encrypted and is also used to pass security information (needs support of XML and WS-Security). Typically WsHttpBinding is used for this
The Authentication and Authorization options in WCF are much the same as you would have for a Web application or a COM+ component. WCF also supports declarative as well as code based authentication/authorization and there are tons of attributes/configuration XML elements defined for that.
Miscellaneous topics
WCF in my opinion provides a much decoupled architecture. Some areas where WCF can be used include
o SOA implementation (remember the WCF service protocol can be TCP it does not have to be a web service with HTTP(S) in order for it to be SOA)
o You can use Windows Workflow Foundation (WF) and make it consume a WCF Service.
o You can have BizTalk consume a WCF Service
o You can define RESTful WCF services and not use SOAP as the message protocol.
o You can expose WCF service information as a RSS / ATOM feed (Syndication) for blogs
o You can expose WCF Services and have Windows Presentation Foundation (WCF) consume the same.
The options are endless, but one thing is for sure WCF is the new baby for distributed communication and time will tell if that’s going to stay for the next couple of years or Microsoft will come out with another architecture and we will all get exited with that dumping WCF.
NOTE: Although I may sound a bit skeptical in my blog, I believe its not just Microsoft but others (Java included) who also keep changing their standards (remember EJB 2.1 nightmare and now its EJB 3 (thanks to hibernate)). That’s what I like about my industry and my job, it never gets boring.
No comments:
Post a Comment