Geeks With Blogs
David Douglass .NET on My Mind

Having worked on a real SOA project for over 3 year I think it's time to examine the reality SOA on .NET.

Introduction

SOA is standards based late bound distributed systems.  In traditional programming, when function A call function B, the compiler and/or linker binds the functions together.  In SOA you embed a logical address for the function to call and assume the binding will take place at run time.  This isn't the formal definition of SOA but it is the key enabling technique.  Distributed late binding has a lot of implications, both good and bad.  On the good side, the service is accessible throughout the network, theoretically increasing reusability significantly.  On the bad side, are a set of problems and complexities not found in early bound systems.

Reuse

A couple of practical issues limit reuse in SOA.  When somebody asks to be one of your clients, it's because there is some overlap between your capabilities and their requirements.  But the overlap is very unlikely to be complete.  Before you realize any reuse you'll have to go down the road of requirements analysis through software deployment.

Once you're ready for deployment you face the delicate task of potentially impacting existing clients for the benefit of a new client.  There are several ways to deal with this:

  1. assume the changes won't impact the existing clients
  2. all clients test and accept the new version of the service
  3. per version deployment of the service
  4. each client has a private deployment of the service
  5. each client has a private virtualized environment
  6. each client has a private physical environment

Solution 1 is dangerous and unlikely to be accepted.

Solution 2 will create expense and scheduling problems for your clients.

Solution 3 is good when there are many clients.  Existing clients won't be affected by a new version since they'll remain on the older version.  But, since in place upgrades aren't being done, a client who wants to move to the new version will need a data migration program and then need to reference the new version once the data is migrated.  Also, this doesn't cover the case of changing a machine wide component such as a queuing system.

Solution 4 is a good solution if the number of clients is small.  Like solution 3, this doesn't cover the case of changing a machine wide component.

Solution 5 covers the machine wide component case, but will almost certainly increase your hardware requirements and could cause a large increase in software licensing costs.  Like solution 4, it works only when the number of clients is small

Solution 6 is the most expensive and only makes sense with a small number of clients with the highest reliability requirements.

Late Binding Issues

Late binding creates several issues:

  1. development is completed by the administrators
  2. binding information is denormalized
  3. security vulnerabilities are far more extensive

Development releases a collection of unconnected parts; somebody then needs to decide exactly how to connect the parts.  For example, what port should a web service listen on?  There are a lot of administrative issues in this question regarding the ports already in use, shop standards, firewall settings, etc.  Development typically doesn't communicate what all the connection points are and how to configure them.  Deployment quickly becomes a lot of trial and error to get all the connections defined correctly.

Many of these connections are defined in .NET config files.  The XML is dense and usually edited with Notepad.  Administrators typically find this sort of editing far more difficult than the developers of the system, resulting in little, difficult to find typos causing large failures.

Administrators should take a stand early in the project that they must have complete deployment documentation and should refuse to accept incomplete work.

I say that  binding information is denormalized because the same fact is stored in multiple places.  For example, consider a web service port.  If you're using load balanced front end servers, then IIS has to be configured identically across all the servers.  Then, all the clients need to know the port number.  .NET config files encourage copying and pasting, but often the configuration doesn't get updated correctly after the paste.

Anybody starting a .NET SOA project should consider how to normalize the configuration.  On the service side, abandoning .NET config files would be a good start, but what should take their place?  You could use a file on shared storage, a relational database, or a network service such as Active Directory, ADAM, or even DNS.  Since the configuration information tends to be hierarchical, an XML file on shared storage strikes me as a better choice than a relational database.  As for the network services, the amount of development effort necessary to interface with these seems to make them a poor choice.  Regardless of where the configuration information is stored, only the address of the information store needs to be represented in multiple places.

On the client side, there is UDDI.  But this hasn't been well accepted and is excessively complicated for simple scenarios.  Also, it doesn't support non web service information such as message queuing.  One simple solution is a web page that clearly describes how to interface with a service: service description and version, web service URL, queuing addresses, links to XML schemas used by queued messages, etc.

Distributed late binding creates a whole new set of security issues.  With early binding a systems has an external surface that needs to be secured but all the internal connections are inherently secure (for all practical purposes).  With services, all the late bindings are entry points for hackers.  Authentication of every service invocation is crucial; there isn't way to secure a service if you don't know who invoked it.  A firewall won't protect you from hackers inside the organization.

Production Issues

At some point your clients will have difficulty using your service.  You need to prepare for this inevitability before it happens.  The areas to focus on are error processing and tracing.

Developers need to recognize the points where a service can fail.  Whenever a late bound call is made or an external service, such as a database, is accessed, exceptions need to be caught and dealt with.  The best way to deal with exceptions is try to hide them.  If you can't connect to the database, then sleep for a second and try again.  If you get the connection the second time, then continue without throwing an exception.  Only throw an exception after certain number of failures.

If it becomes necessary to throw an exception, this must be logged.  You'll hear about problems after the fact and you'll need as much evidence as possible to troubleshoot the problem.  Once logged, there needs to be a thought out response.  What exactly should be done when the database isn't available?  Don't leave these questions to chance.

Tracing allows you to know what your service is doing.  This needs to take place at two levels, the request level and the internal level.

Tracing at the request level means logging the details of every invocation of your service and the result of the invocation.  People will call you with vague problem descriptions and hazy recollections of what they did.  If the request doesn't show up in log at all it's a good indicator that the problem is probably outside of your service.

Tracing at the internal level tells you what your software is doing.  It's a substitute for a debugger.  While it's possible to attach a debugger to a production service, stepping through the code brings the service to a halt as far as the user's concerned.  Tracing needs to be very configurable so that you can turn it on and off in various places and control the amount of detail.

Conclusion

You can build SOA services using .NET; I know because I've done it.  But, Microsoft with their "developers, developers, developers" focus didn't put much thought into deploying and running the services.  You need to cover that base yourself.

Posted on Sunday, June 24, 2007 4:15 PM | Back to top


Comments on this post: SOA on .NET

# Links (6/24/2007)
Requesting Gravatar...
.NET Looking for Study Group Leader Volunteers - for the Cincinnati .NET User Group SubSonic 2.02 Released
Left by Member Blogs on Jun 24, 2007 8:52 PM

# re: SOA on .NET
Requesting Gravatar...
.NET Looking for Study Group Leader Volunteers - for the Cincinnati .NET User Group SubSonic 2.02 Released
Left by sz on Mar 31, 2009 5:04 AM

# re: SOA on .NET
Requesting Gravatar...
Tracing at the request level means logging the details of every invocation of your service and the result of the invocation. People will call you with vague problem descriptions and hazy recollections of what they did. If the request doesn't show up in log at all it's a good indicator that the problem is probably outside of your service.

Tracing at the internal level tells you what your software is doing. It's a substitute for a debugger. While it's possible to attach a debugger to a production service, stepping through the code brings the service to a halt as far as the user's concerned. Tracing needs to be very configurable so that you can turn it on and off in various places and control the amount of detail.
Conclusion

You can build SOA services using .NET; I know because I've done it. But, Microsoft with their "developers, developers, developers" focus didn't put much thought into deploying and running the services. You need to cover that base yourself.
Left by teri maa ki on Mar 31, 2009 5:04 AM

# re: SOA on .NET
Requesting Gravatar...
Having worked on a real SOA project for over 3 year I think it's time to examine the reality SOA on .NET.
Introduction

SOA is standards based late bound distributed systems. In traditional programming, when function A call function B, the compiler and/or linker binds the functions together. In SOA you embed a logical address for the function to call and assume the binding will take place at run time. This isn't the formal definition of SOA but it is the key enabling technique. Distributed late binding has a lot of implications, both good and bad. On the good side, the service is accessible throughout the network, theoretically increasing reusability significantly. On the bad side, are a set of problems and complexities not found in early bound systems.
Reuse

A couple of practical issues limit reuse in SOA. When somebody asks to be one of your clients, it's because there is some overlap between your capabilities and their requirements. But the overlap is very unlikely to be complete. Before you realize any reuse you'll have to go down the road of requirements analysis through software deployment.

Once you're ready for deployment you face the delicate task of potentially impacting existing clients for the benefit of a new client. There are several ways to deal with this:

1. assume the changes won't impact the existing clients
2. all clients test and accept the new version of the service
3. per version deployment of the service
4. each client has a private deployment of the service
5. each client has a private virtualized environment
6. each client has a private physical environment

Solution 1 is dangerous and unlikely to be accepted.

Solution 2 will create expense and scheduling problems for your clients.

Solution 3 is good when there are many clients. Existing clients won't be affected by a new version since they'll remain on the older version. But, since in place upgrades aren't being done, a client who wants to move to the new version will need a data migration program and then need to reference the new version once the data is migrated. Also, this doesn't cover the case of changing a machine wide component such as a queuing system.

Solution 4 is a good solution if the number of clients is small. Like solution 3, this doesn't cover the case of changing a machine wide component.

Solution 5 covers the machine wide component case, but will almost certainly increase your hardware requirements and could cause a large increase in software licensing costs. Like solution 4, it works only when the number of clients is small

Solution 6 is the most expensive and only makes sense with a small number of clients with the highest reliability requirements.
Late Binding Issues

Late binding creates several issues:

1. development is completed by the administrators
2. binding information is denormalized
3. security vulnerabilities are far more extensive

Development releases a collection of unconnected parts; somebody then needs to decide exactly how to connect the parts. For example, what port should a web service listen on? There are a lot of administrative issues in this question regarding the ports already in use, shop standards, firewall settings, etc. Development typically doesn't communicate what all the connection points are and how to configure them. Deployment quickly becomes a lot of trial and error to get all the connections defined correctly.

Many of these connections are defined in .NET config files. The XML is dense and usually edited with Notepad. Administrators typically find this sort of editing far more difficult than the developers of the system, resulting in little, difficult to find typos causing large failures.

Administrators should take a stand early in the project that they must have complete deployment documentation and should refuse to accept incomplete work.

I say that binding inforand control the amount of detail.
Conclusion

Y
Left by Comment on Mar 31, 2009 5:05 AM

# re: SOA on .NET
Requesting Gravatar...
Nice to see such a good articles, but i think u publish articles which exact show the architecture used for such SOA based solution . pls publish arcticle which show flow fron one end to other which all covering your topic.
Left by Rajesh Kushwaha on Aug 19, 2009 1:53 AM

Your comment:
 (will show your gravatar)


Copyright © David Douglass | Powered by: GeeksWithBlogs.net