This post originated from an RSS feed registered with .NET Buzz by James Avery. Original Post: Adventures in SOA, Part 4 Feed Title: .Avery Blog Feed URL: /blog/Install/BlogNotConfiguredError.aspx Feed Description: .NET and everything nice Latest .NET Buzz Posts Latest .NET Buzz Posts by James Avery Latest Posts From .Avery Blog

Brian Vargas and Steve Maine have both weighed in on some of my thoughts on SOA, and their feedback made some very good points.

I think the main thing that their feedback points out is that SOA is about insulating various sections of your application from other portions of the application, through the use of services. This part I understood, the part that was tripping me up was how to implement the actual services and I am not sure the conclusion that I came to in my last post is completely correct. It is best to look at this through an example, in my current application one of the main groups of services will be authentication and user management... here are a couple example services:

AuthenticateUser(username, password, application)
AddUser(name, address, etc)
UpdateUser(userId, name, address, etc)

These services will be used by a number of different applications, and in different parts of those applications.  Since I want to be able to revise and modify these services and the various application using them in different development cycles it makes perfect sense to use services. Now, the question is how should I implement these services and build the internals of these services. I do not expect to modify individual aspects of this group of services, so it would make sense to build the internals of these three services using OOP. This would give me the benefits of OOP for the internals of these services, but the benefits of SOA for the interface between these services and the other applications that will be using them. This is the opposite of the conclusion I came to in my last post.

Using an OOP design the internals of my services would end up looking something like this:

AddUser() Web Service would call a Service Interface layer which would:
 1) Verify user has permissions to add a user
 2) Create an instance of the User object
 3) Populate the object with the parameters from the service
 4) Call the Save() method on the User object. (Any business rules/validation applied here)

Using an SOA design the internals of my services would end up close to something like this:

AddUser() Web Service calls the Service Interface layer which would act as a Process Service and would:
 1) Call an activity service called ValidateUser() which would confirm that the user can perform this action
   1.1) The ValidateUser() service would call an Entity Service which would retrieve the data from the database
 2) Call an activity service called  AddUser() which would:
   2.1) Check any business rules using some sort of business rule engine
   2.2) Call an Entity Service which would add the user to the database.

If I know that the internals of these services will always be modified as a whole, then is it worth the trouble to use a SOA design for the internals? This is an almost trivial decision, considering the main benefits I am looking for will all be accomplished by implementing these functions as services.. whether those services are built using OOP or the SOA method in my last post... is not really that important to the entire application. I might even try implementing these services using an OOP internal design, and then implemented some of the other services using a SOA internal design... then see how each of them works out.

But I think the main lesson is that the part of SOA that is important is that these services are implemented as services, not how the internals of these services are built.

-James