With or without SOA?

I recently got a question - "While developing applications in ASP.Net what is the difference with or without SOA architecture?". i thought - it is quite an interesting question and something I should write a post on.

First things first - what is SOA? why do we need SOA? what are the advantages of SOA?

Service Oriented Architecture - it is an architectural paradigm that advocates building enterprise systems (usually distributed but not necessarily) from and based on web services (although it is allowed and possible to build a SOA system using alternatives like COM/CORBA). Why web services? One - webservices can be developed using any language and hosted on any platform. Two - web services can function over most protocols including HTTP, which makes it easier to access them from anywhere. Three - web services interact with each other by exchanging messages in a mutually agreed format called "contract" defined in a service description.

In a services based system (i am deliberately not using the word architecture here) - there is a requestor (another service, system or application) that sends a message to a provider (a service) and gets a response with the required information - processing it as appropriate. Most important differences between a service and any other modularised code entity is that a service is:

- usually Atomic

- granular (chatty)

- always confirms to a contract

- responds only to a valid message

- is asynchronous to account for the network latency and handle concurrency

- always has a way to handle error conditions (esp rollback partial errors)

With these properties in mind, architects designing services usually keep in mind the following:

- The requestor can be any other system, running on any platform

- The requestor should be able to discover the service, find out the way to communicate with the service, send a message to the service, get a response and be able to process the response.

Now, why do we need SOA? - till now nowhere have i mentioned that the provider needs to have any knowledge about the requestor (other that the information that it needs to process the request from it - if any), the requestor can be any thing - another web service, a client desktop application, a web application. Web services can be created to address needs at any of the layers of a n-tier application. So - you may have a set of web services that are responsible for accessing and fetching the data from the database server, another set of web services that provides the business logic, a set of web services to create a presentation layer. You can knit them together to construct your application - adding the necessary glues be it the UI, validation or other things that are not available as services - or implement these functionalities as services if it makes architectural sense in a given scenario.

This leads us to the benefits of using SOA - in scenarios where you predict extensive interaction/integration between various applications (be it multiple application within the same organization or different applications running on different platforms in different organizations), or where you may need to scale in the future to address the growing customer needs, or when you want to have a choice of different types of clients (web, desktop, mobile) using the same back end services, or when you plan to keep the option of migrating to services provided by different vendor without having to change your whole application or being able to change/enhance a service without disturbing existing applications - SOA offers a huge set of benefits by providing loose coupling, platform neutrality, standards based implementation, rigid contracts for version independence etc.

Now - coming to the actual question - what is the difference in developing an ASP.NET application with or without SOA? So if you are looking forward to gain from any of the advantages of SOA mentioned above, if you are planning to integrate multiple applications, provide access to multiple clients, reuse and manage functionality/services across multiple departments in the same organization, provide an easy interface for your customers/vendors to integrate with your systems - SOA definitely is the way to go. One important thing to remember here is - SOA is independent of ASP.NET. You can build a complete services facade comprising of all the functionality that you need and then weave them together by using ASP.NET as a glue and provide the web UI in it. At the same time - the same web services can be accessed by other clients (internal or external customers/vendors) be it web, desktop, mobile or just another service. In most cases - if you are planning a new system and do not have to carry forward legacy code/systems, SOA is a safe bet unless you have a small simple system which would not be need to integrate with other systems, in which case SOA might be an over kill.

All in all - SOA does have to offer a huge set of advantages especially for Enterprise Applications - given that they can have multiple systems from multiple vendors and may have the need to integrate with legacy systems - to provide a seamless unified experience to the users.