Nate's Stuff

Service Oriented Architecture is a software design concept that packages small pieces of modular functionality into "services" through the software lifecycle.  SOA separates functionality into a set of self-contained, modular units that can be combine by a simple application to accomplish a task.  This blog post will focus on a few specifics of SOA but will mostly discuss the benefits of using SOA in the Enterprise.

Background

One of the main pieces of philosophy that SOA embraces is the KISS (Keep It Simple & Stupid) principle.  The fact is that big complex projects fail while small, simple projects succeed.  As a developer I see this every day.  For example, a few months ago me and my friend Phil wrote a web site.  In the early days and weeks (after getting some of the basic requirements ironed out) functionality was really easy to add.  Everything existed in a very simple state because it was a simple design with simple requirements.  We finish the original set of requirements pretty early in the project when they decided that we wanted to do some enhancements.  These enhancements greatly complicated the application.  Now, adding even a small amount of functionality takes substantially longer.  Over the weekend I wanted to add the ability to add category in as part of the search.  In the early days of the project it was actually work to leave it out (I had to disable the box when they changed the type of search).  It was pretty easy to add it into the stored proc but then the coding changes!  I had to add it to my data layer, data model, view, and controller.  Of course, these changes broke some other functionality that was added after this feature was originally included.  Because Unit Testing wasn't going to be part of the timeline we have to test a large portion of the site to be comfortable that this change didn't break anything else.  The two universal facts are that:

1. The larger and more complex an application becomes the longer it takes to add features.
2. Changing code is more expensive that writing new code.

In Juval Lowey book called Programming .NET Components he highlights that component-oriented programming can simplify and add flexibility to complex applications.  He also makes a good case for simple software and all of these concepts port directly into the SOA paradigm. 

What is a service?

When many people hear the term "service" they almost always either think of Web Service or Windows Service.  The truth is that a service can be almost anything that provides implementation to a consumer.  In this context a service can be a library that can be invoked (much like Win32 API), or it could be a piece of hardware that performs complex calculations (like a Graphics Card/GPU).  Believe it or not the World-Wide Web is just a bunch of different services.  Web services have been particularly popular as they meet the criteria for usability.  1) Universally accessible, 2) Simple and Stateless.  In addition web services are easy to deploy, change, and have an already extensive existing infrastructure.  Web Services are also very scalable and are easy to make redundant which provides high availability.

Figure 1: Enterprise SOA Diagram

Why SOA?

Besides the benefits from rapid software development there are many other benefits of SOA.  For those looking to make a business case of ROI consider that SOA helps to make your company easily and quickly change business processes to align with market conditions.  This is because the software is now modular and flexible and especially if you use some type of workflow for your complex business tasks these rules can be easily updated and changed.  Also, new functionality is quickly developed, integrated, and deployed.  Consider the difficulty involved in making a change in the order in which orders are filled.  With a Fat-Client approach you may have several different apps that depend on the order being predictable.

Testability

Testability is arguably one of the best benefits gained by the SOA approach.  Because we have a simple granular piece of functionality it makes testing of this functionality easy.  It is also easy to test as these smaller functions are designed to be exposed.  It can be difficult to test code that wasn't intended to be consumed.  In terms of change management, if we keep our business running in services then our unit tests can help guarantee confidence in a new release of an application that uses several different services.

Because the database is only touched by one layer of our enterprise application infrastructure and due to the fact that most services will exclusively deal with a small subset of tables -- changes to the database become greatly simplified in a true SOA environment.  This adds simplicity and allows the company to change more quickly to adapting demands on their business.  In addition different systems can be allowed to run on different databases which makes migration from one database to another significantly simpler.

Security

Security is a great reason to move toward SOA.  The biggest gain is that the Database servers can be safely tucked in a Back End Zone (BEZ) because our applications no longer need to connect directly to them.  This is also extremely helpful if you have each user connect to the database using Integrated Authentication or an account unique to each.  This will cause hundreds and thousands of connections on the database and reduce performance substantially!  Moving the database into a zone where it can only be accessed from the application servers limits the surface area for attack and greatly limits potential venerability.  For financial systems it is part of the infamous Sarbanes-Oxley (SOX) audit to prohibit access directly to the database (in addition to change logging requirements).  While this is not the only way to come into compliance with a SOX audit it is arguably one of the better ways. 

Simplicity

Again, the best benefit of SOA is the simplicity each service can have which results in less bugs, more developer productivity, modular reusable code, and flexibility.  Services should be broken up into a lot of different chunks to make them easier to manage and they should typically include only one concern (a single aspect of the business).  Other services can consume existing services to expose more complex business sceneries. 

"It breaks down the complexity of software systems by isolating services.  This simplifies configuration management for each piece, and whole applications can be made compliant with new ordinances and business requirements without updating any of them." -- Phil Gilmore

Another benefit SOA gives us is that every call needs to have an interface that is carefully and purposefully designed.  Using Interfaces is a great way to promote loose-cohesion and makes changing different parts of the code much easier to accomplish.  So long as any changes you make can still be supported by the interface already defined most changes are inconsequential.  If you must make a change to the interface of a service you will typically be doing this to add new features and usually the existing interface can be left alone and a new version of the interface can be supported for that service. 

"SOA has a downside in version control.  Services must usually be able to run side-by-side versions to support applications whose requirements don't change synchronously." -- Phil Gilmore

Performance

Performance is an important consideration when talking about services (especially web services) and potential impact to application performance.  Network round-trips are expensive -- even in a LAN environment.  Also the serialization and de-serialization of objects adds extra time for each call -- time that is not necessary when using a framework-style call.  While all of this is true, consider that any data retrieval is expensive.  If your application connects to a central database you still incur the overhead of connection to the database over the network, your data is still serialized as it goes over the wire and you will usually still hydrate objects with this data once you get it back.  At that point the only layer that a web service has that is extra is that of IIS.  When you factor in the connection pooling that can be accomplished on a service with the cost of having many (and perhaps even thousands) of concurrent connections to the database when thick clients connect directly it's easy to see that your probably not going to see any significant performance loss by moving to this type of architecture.  It may take some getting used to when creating calls with a ton of parameters but it will perform well.

Another thing to consider when looking at performance aspects of SOA is that a web service written with WCF is fast!  How fast? I haven't benchmarked web services in .NET for quite a while (since Framework 1.1), but I know there were significant performance gains for the 2.0 Framework and even more gains for 3.0 & 3.5 Frameworks.  Additionally, the newer frameworks have much lighter formatters and endpoints than we did back then.  Keeping this in mind, back when I benchmarked a simple web service that would reverse a string that was sent to it as input that service was ran at a rate of 2,200 calls per second sustained!  This is a testament both to IIS as a middleware server and .NET Web services for sheer speed!  Our other web service was coded in Delphi 7 as an ISAPI DLL and struggled to sustain 10 calls per second.  The Delphi service also intermittently failed whereas the .NET web service did not.  In short, the web is a great way to expose a service and there is little need to look for anything "faster" or "more robust". 

Configuration Management / Distribution

When looking to other positive aspects of SOA, without a doubt one of the best arguments is distribution.  The race to "web enable" everything possible is a landmark of the difficulties of distribution.  These so-called thin clients relegate any deployment and configuration to the server that runs the service.  This concept of "configure once" is embraced by SOA.  If you plan on deploying a smart client (a cross between a thick client and a thin client) significantly reduces the amount of configuration required for users to execute your software.  They don't have to worry about database providers, connection strings, loggers, DSN's, or anything else your app might use.  SOA can even be used for web sites (thin clients) that require these services.  SOA is a principal without a fixed style of client so it will work as well with a web app as it will with a windows app. 

"This saves configuration management by avoiding redeployment of existing applications, it saves software engineering by not modifying the applications, it tends to save time in testing if testing can be isolated to that service rather than testing all applications that consume it." -- Phil Gilmore

Summary

Service Oriented Architecture is a best-practice for today's Enterprise.  It's use can substantially reduce the manpower required to maintain applications and has major improvements to maintenance, scalability, change management, code reuse, and distribution of applications. SOA will make your life easier and make your employer happy and isn't that the most important argument of all?