Another List on SOA.....Ohh and SOA != OO

The term Service Oriented Architecture (e.g. SOA) is thrown around quite a bit these days and it always amazes me the speed in which people jump into them and the assumptions they make. There is no doubt that SOA adds a positive dimension to any application architecture. I have been building and deploying webservices for close to 2 years now. Before that I worked on a number of other service based architectures and there are things to consider before jumping into them.

  1. SOA is just one dimension of a good architectural scheme. It is not THE architecture. 
  2. In some respects (but not all) SOA and OO are orthoganal. OO is about keeping data and the methods and properties that act on the data in the same class. With an SOA architecture, client proxies are generated by the WSDL. Only public properties with getters and setters are created in the proxy. All methods and any business logic is NOT generated on the client nor included in the client proxy. This leads some to actually put the class that is being serialized onto the client as well (yes I have seen people do this/try to do this on a # of occassions) which can cause name collisions and really negates the positive aspects of SOA. If you want to put the class being serialized on the client, then you should take a serious look at Remoting.

    The fact that the client proxy only contains the class's getters/setters, leads many developing SOA architectures to seperate business logic classes from their business entity classes. The benefit of this seperation is a positive one but clashes with some OO principles because you are seperating data from the methods and Business Logic (BL) that act on the data. The BL that supports acting on the data is on the WebService machine and the class that gets serialized from the webservice is a seperate Business Entity object and the basis for the Client Proxy (via WSDL).

    This is not to say that you cannot follow a stricter OO model by keeping the two together but often times it causes confusion by users of your libraries who are unfamiliar with the way client proxies are generated on the client and expect the methods and business logic to show up on the client in the same proxy ...which does NOT occur. Personally, I recommend the seperation by keeping business entity classes and business logic classes seperate and knowing full well that I have broken the OO model to some degree...the benefit (IMHO) outweighs the costs.

  3. Remoting and SOA are not the same. Remoting follows the OO paradigm much more closely by providing a Marshal-By-Ref (or a MBV if you know what you are doing) proxy to the actual objects and its methods and properties. This means you can actually call the methods on the object itself via a client proxy and the business logic remains in tact. This follows the OO paradigm much more closely then a WebMethod because the client proxy is aware of the business methods and the business logic encapsulated in the object itself which isn't available with a WebMethod implementation. Furthermore, remoting assumes a .Net implementation which enables you to keep (and often requires) the class being proxied to exist on the client.
  4. Exception handling with an SOA architecture is different. You can still use the try/catch metaphor but all exceptions are of type SoapException (there is also SoapHeaderException but this means no detail block). This means that their is no differentiation in error typing. In other words, all exceptions emanating from a web service are of type SoapException. There is no way to distinguish between exception types without looking at the DetailBlock in the SoapException and developing your own "contract" between server and clients. I wrote a blog that provides some insight into how to use this detail block to your advantage http://weblogs.asp.net/mnolton/archive/2003/09/17/28015.aspx; however, there are some shortcomings of this approach. The client must know to look at the detail block correctly in order to act on the information it contains. The only alternative is to just show your client whatever error information comes back from the service...but this prevents your client application from acting on the exception in a meaningful manner (which I personally think is a bit of a hack because you cannot really control what a server is going to tell you).

    It would be nice feature to provide a "Throws" construct similar to what Java does that would enable someone to decorate a method with a custom attribute(s) that details the exceptions that can emanate from the client. Then in the client proxy, generate an exception proxy (I think this is already supported) but then also generate proxy code that evaluates error conditions and throws the correct exception from within the client (not supported with WSDL.exe).  Hmmm, it would be a nice feature for Christian Weyer's WsContractFirst tool :)

  5. Just because you can create a WebService doesn't mean you should. The cost of traversing the SOA boundary is high. For example, I have seen a number of people try to put a WebService interface over their database. What's the point? If you want to talk to a database, use native libraries in your language of choice. It is much more efficient. Also, a WebMethod should expose a business contract...not a data contract. If you provide just data to your client then you are now tying your client to your data implementation. If that should change then your client is screwed. Instead, create a business contract and make data access a concern of your BL that is called by your WebService. Don't tie your client to it. Often times when I see this it is by a developer who just want to create a WebService.

As always comments and feedback are encouraged.

-Mathew C. Nolton

No Comments