Wednesday, March 31, 2010

WCF Binding Features

 

Supported features for each binding

WCF Communication Bindings

 

Binding Name Description .NET

basicHttpBinding

Binding for WS-I Basic Profile 1.1 Web Services including ASMX Web Services

3.0/3.5

wsHttpBinding

Binding for advanced WS-* based Web Services such as WS-Security, WS-Transactions, and the like

3.0/3.5

wsDualHttpBinding

Binding to support bidirectional communication using duplex contracts.

3.0/3.5

webHttpBinding

Binding that supports REST/POX-based services using XML and JSON Serialization.

3.0/3.5

netTcpBinding

Binding for communication between two .NET-based systems.

3.0/3.5

netNamedPipeBinding

Binding for on-machine communication between one or more .NET-based systems.

3.0/3.5

netMsmqBinding

Binding for asynchronous communication using Microsoft Message Queue (MSMQ).

3.0/3.5

msmqIntegrationBinding

Binding for sending and receiving messages to applications through the use of queues using MSMQ.

3.0/3.5

wsFederationHttpBinding

Binding for advanced WS-* based Web services using federated identity.

3.0/3.5

ws2007HttpBinding

Binding derived from the wsHttpBinding with additional support for the latest WS-* specifications based on standards available in 2007.

3.5

ws2007FederationHttpBinding

Binding derived from the wsFederationHttpBinding with additional support for the latest WS-* specifications based on standards available in 2007.

3.5

Sunday, March 28, 2010

SOA != Web services


A lot of folks think a service oriented architecture is “Web services on steroids.”

In order for business to free itself from technology, the business logic must be separated from the plumbing, Web services technology is what allows us to make this separation, creating business service components from business applications. The business logic sits above
the plumbing in the business services layer. These business service components bring to the business the same efficiencies of reuse, ease of change, and consistency of results as Web services do on the programming level.

The creation of a SOA involves identifying the key business services and working top-down, versus bottom-up. Making key business services into black boxes means that business can reorganize itself as needed. Once you have several key business services, you string business services together to create a business process. In an insurance company, “claims handling” is a business process. In a hospital, “admitting a patient” is a business process.

Note that a business process is not by definition automated. It may indeed require manual participation or intervention. Great gains in efficiency come when a process is automated “from end to end,” but this is not always possible.

Saturday, March 27, 2010

What is SOA?


When business increases and becomes complicated, we need IT to sort out things. It enables us to create custom solutions which increases our productivity. Now with IT in place, when the business needs to change/do M&A/etc. the applications developed by IT dept is a roadblock, as it cannot magically start working as per new requirements, and changing the applications takes long time and of course lots of money. Thus, IT becomes a constraint for business to grow.

SOA (Service Oriented Architecture) is a new approach to building IT systems, It uses existing assets and enables change. SOA is suppose to liberate business from the constrains of technology. It lets the business focus more on business and less on technology.

Current IT systems suffer from the following complications:

  1. Business logic and plumbing
    One of the biggest problems in programming is that it is very difficult to keep the business logic separate from the plumbing because you need to control both at the same time. Though the tasks are related, they can be separated. It’s work, and it requires both the use of appropriate software tools and programmer discipline to ensure that the business logic is kept separate from the technology that makes it happen.
    For example, if you want to change the order in which particular business functions happen, and you’ve kept your business logic separate from your plumbing, making these changes is no big deal in a SOA. But if your business logic and your plumbing are one giant application, changes are costly and complicated, take time, require extensive testing, and are a very big deal indeed.
  2. Legacy Systems
    Business in many cases will depend on legacy systems which are in place and operational, and business does not have time or budget to start from scratch.
    With SOA, you can use almost all your existing business applications. True, you may need to change them a little in order to include them in a SOA, but it is possible, and it is not all that hard. For example, you can treat an entire application as a service, or you can take some code out of an application and make just that code into a service.
    A SOA uses very specific, industry-agreed upon standards to create interfaces that make it possible for various components of the SOA to talk to each other.
  3. Application archaeology
    It may not be possible to separate out business logic and plumbing as many of
    the business layer components come from existing applications, and existing business applications were likely built in very different ways, at different times, by different people, and for different reasons, maybe even using different computers. Unlike hardware, software hangs around for decades.
    Intelligent black-boxing is an important aspect of SOA. With a SOA, you can build a whole new computing environment by using all the resources that you already have by treating many components as black boxes. Particularly, you need to treat existing application components as black boxes, making them accessible by adding adapters. For example, you should use a black box to include older plumbing components that still work. The black box prevents you from spending money to replace something that works just fine. Or, as the sages say, “If it ain’t broke, don’t fix it.
  4. Who’s in charge
    If the plumbing for one component doesn’t work with the plumbing for several other components, how will an end-to-end process work? If it fails, how will you know?
    Any and all problems associated with the end-to-end processing of components are dealt with by a little something called the SOA supervisor. So, no need to worry, because the SOA supervisor will take care of things. The SOA supervisor acts something like a traffic cop and helps prevent SOA accidents.

So, technically, a service oriented architecture is an architecture for building business applications as a set of loosely coupled black-box components orchestrated to deliver a well-defined level of service by linking together business processes.

Monday, March 01, 2010

Extension methods on Interfaces

 

class Program
{
[STAThread]
public static void Main()
{
IFoo myFoo = new Foo();
myFoo.DoFoo(); //Class Foo does DoFoo()
myFoo.DoBar(); //Class FooExtensions does DoBar()
}
}
internal interface IFoo
{
void DoFoo();
}
internal class Foo : IFoo
{
public void DoFoo()
{
Console.WriteLine("Class Foo does DoFoo()");
}
}
internal static class FooExtensions
{
public static void DoBar(this IFoo obj)
{
Console.WriteLine("Class FooExtensions does DoBar()");
}
}