SOA via WCF - Part 1-
Service Oriented Architecture via Windows Communications Foundation
I should have blogged this very much earlier, because this was my presentation in SilverKey Demo Day II last July 7th, so it took me more than a month, I hope I still rememebr :)
You will find the presentation attached with this blog post
So today, I will be talking about Service Oriented Architecture (SOA) in general also I will give an introduction to Windows Communications Foundation (WCF) and how to apply SOA concepts in real life.
Let's see the Agenda
- Part 1- Service Oriented Architecture
- Background
- Motivations
- What is a service ?
- Message Exchange Patterns (MEP's)
- Industry Standards
- Web Standards
- Part 2- Introducing WCF
- What is WCF
- WCF Architecture Overview
- Demos
In today's blog post I will be only discussing Part-1 in the coming days, I will be writing Part 2 in a separate blog post.
Let's start with First part Service Oriented Architecture (SOA).
Service Oriented Architecture is a buzz word in the world for many years, architects have been talking, writing, blogging and also building applications using SOA, but before we go with the wave, why don't we stop for a while and go back with time to see the software evolution since its early days.
Since the early days of software industry, just when people started to use general purpose programming languages such as C, the concept of reuse was in mind, but the reusable unit couldn't me more than a function or a procedure, or may be some unstructured and unorganized pieces of codes, that used to get copied and pasted whenever needed,
However, this was developed by time, till the days of Object Oriented, when a bigger unit of code was defined, this unit was called Class, the Class which consists of data and Logic, became the major unit of organized reusable code for the past couple of decades, but there was a major problem, that class objects are not exchangeable outside the technology, in other words an object built with C++ can't be used as is in another class written with Java, so the reuse was limited by the technology,
Component Oriented came to the rescue with technologies such as COM, DCOM, COM+ for windows and other technologies were developed for other platforms, so different technologies can exchange objects between each others, for example, in windows environment you can use the UI elements such as Buttons, TextBoxes from any technology even though those UI elements are not developed using the same technology you are using for your application, this was great but what about exchanging objects and data between technologies running on different platforms, like a C# application developed on Windows want to send an object for a Java application running on a Unix platform, here is when Service Oriented came to rescue.
Why do we need to exchange objects through different platforms?
The answer is one word Integration, when you are building an applications that needs to integrate with another Existing application, which happened to be developed using a different technology and runs on different platform, what will you do ? you have to find a way to integrate with this application.
For example, if you want to add Maps support in your application, are you going to build a GIS system to view some maps in your application, surely no, but you are going to integrate with something like Google Maps or Microsoft Virtual Earth to send the coordinates and receive the map.
In our example we will find ourselves calling Google Maps or MS Virtual Earch a Service, which leads us to the next question
What is a Service ?
A Service is a reusable piece of software, but the main difference that this piece is as large as a full application, this application might be built using any technology and deployed on any platform, these details are not important as long as the Service provides a Structured Messaging Scheme, this structured messaging scheme in most cases is XML document(s) or any other text-based structure, that can be exchanged on Http, but the fact is it is not only XML nor HTTP, it can be any other format on any transport as long as it is well defined.
This model of separation comes with some other benefits, like Versioning independence, which means that as long as the Service doesn't change its messaging structure, it can change any inner implementation details and add more features without the need for all other applications that use this service to be aware of these changes.
Also the nature of the separation between the Service and other clients or even other Services, introduced some concepts like Message Exchange Patterns which is how the structured messages are exchanged between Service and Clients.
The message exchange patterns used are either
- One Way
- Request/Reply
- Duplex
The One Way is when the sender sends a message to the receiver but the sender doesn't expect the receiver to reply to this message, it is something like Fire & Forget.
The Request / Reply is when the sender sends a message to the receiver and expects ONLY one reply from the receiver, as an example any web page you request for it in your browser you expect a reply (Response) which is the Page you requested.
The Duplex is when both Sender & Receiver construct a channel between them and everyone of them can send messages to the other at well, it is just like a Phone Call.
Every MEP has its best use, depends on the Scenario, in Part 2, I will be doing samples with WCF that show how to use different MEP's with WCF.
From the previous talk about Integration you might have imagined if everything gets standardized so no matter what system you want to integrate with, you know that there is a standard way of doing this.
Actually this is somehow true, there are some initiatives by Software Industry leaders such as Microsoft, IBM, Oracle, Sun ... etc, to standardize the Service Structure Exchange Scheme thing into something real, which results in what we call SOAP (Simple Object Access Protocol) which is a XML based protocol that defines the message that is going to be exchanged between different Services & Clients, also there are some standard protocols that were built on top of SOAP which all of them starts with WS-, so they were all called WS-* Protocols like WS-Addressing, WS-AtomicTransaction, WS-Security ... etc, everyone of them is defining a standard way of handling a specific scenario in terms of the Exchanged Message structure and parties involved, like WS-AtomicTransaction it defines a protocol for performing distributed transactions between Services.
These standards are being used in different technologies under several names, that most common technology is Web Services & WSE
The SOAP & WS-* are NOT the ONLY method available but there is another ways which are most commonly used over the web, and so called Web Standard, or Webby Standard.
These methods can be grouped under REST.
REST (Representational State Transfer) which relies on HTTP verbs such as GET, which most of the time uses the URI as a function call, so you request a URI with a specific parameters and gets the result in any format such as XML, text, or JSON.
This method is used because it is very simple and especially for listing data
Give SOAP a REST
You will find a lot of debates online about which is better SOAP & WS-* or REST, which I think is not the right question, because you will always find situations where you find REST better and vise versa.
As a summarization of this part of the presentation, Here is a list of online services that most of them are free and available using either SOAP, REST or both.
Summary
Service Oriented Architecture is one of most important techniques that introduces new way of thinking and designing systems in order to provide better integration options.
Comments
- Anonymous
June 28, 2008
This is the second part of my presentation in SilverKey Demo Day 2 (SKDD 2) last July, for the first