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.


Comments (12)
  1. Nagaraj says:

    What about the performance?

    Could you name few largest implementations of SOA?

    Thanks,

    Nagaraj

  2. efactor says:

    "Service Oriented Architecture – it is an architectural paradigm that advocates building enterprise systems (usually distributed but not necessarily) from and based on web services"

    This is not entirely correct statement. Its not only about web services.

    Here are some quick references on SOA

    http://msdn.microsoft.com/en-us/library/aa480021.aspx

    http://en.wikipedia.org/wiki/Service-oriented_architecture

  3. BijoySinghal says:

    @Nagaraj – performance would depend on the quality of architecture and implementation. SOA necessarily does is not a performance bottleneck by itself. It is a architecture paradigm. Other paradigms that solve the same issue in a different way (e.g. CORBA) etc too can have a performance bottle neck if not implemented correctly.

    Regarding examples – not sure if i can name any particular of the top of my head – but there are a number of enterprises who have implemented whole or partial systems on the SOA paradigm.

    @efactor – agree with you. It is not only about webservices. The statement in brackets just after what you snipped intented to stress on the same. Webservices form an important component of a SOA based system. They weave together the disparate resources and components of the over all system.

  4. Vijay Jain says:

    A very good implementation on SOA at National Level is already in place and named as "National e-Governance Service Delivery Gateway" for Govt. of India.It is a middleware project developed under Department of IT and performs routing of messages in an interoperable fashion.It is one of the largest implementation on open source tools which complies to all interoperability standards.

    Thanks

    Vijay Jain

    Interoperability Expert,NSDG Team

  5. BijoySinghal says:

    @Vijay Jain – Thanks for sharing that. I looked at the website and it looks very interesting. Would you be able to share more details on the implementation? you can mail me at bsinghalatmicrosoftdotcom.

  6. Ajay Ashish says:

    great stuff,thanks for sharing it.

    keep posting.

    thanks

    ajay ashish

    Reached @:ajay_ashish@hotmail.com

  7. Opentube says:

    Great post and clears says why SOA is used.

  8. bindesh agrawal says:

    i am working on a H.R.M.S(human resource management system)

    system in .net,is it feasible to go for S.O.A ?

  9. Sanjeev says:

    Good Information ! Very interesting !

  10. Zeeshan says:

    Thanks for sharing really good stuff….

    keep posting.

    Thanks,

    zeeshan.aazmi@gmail.com

  11. Manish says:

    What is difference bet SOA and REST

  12. Pradeep says:

    You mentioned that service should be granular(chatty). Is that right? Before JSON and REST thing became popular, services were supposed to be non-chatty. They were supposed to do heavy lifting. I guess now with REST/JSON in picture services need to be flexible enough to be chatty.

Comments are closed.

Skip to main content