none
design A or design B RRS feed

  • General discussion

  • I'm hoping to drag you you all into a (very short) debate about SOA standard / best practices.  I think I can boil it down to a simple example.  Even if you don't have time for a detailed post, I would really appreciate a short reply with just "A" or "B", your preferred language / platform / environment, and how many years of experience you have.  Any additional insight you would like to provide is gravy.

    In this example, we have a client that will need to be able to:
    - update multiple fields of a user (ie- name, email, password, status, etc)
    - update the password of a user
    - update the status of a user (to any valid status)
    - change status of user to "unlocked"

    We have two suggestions for the web service implementation:

    (A) Four specific services, one for each client need:
    - UpdateUser with all fields required that updates all changeable fields of the user
    - UpdatePassword, UpdateStatus each change only that one field of the client
    - UnlockUser only allows the status to change to the "unlocked" value

    (B) A single general service to handle all four client needs:

    UpdateUser service with appropriate optional fields that updates only the fields provided in the request.

    I don't think any of this is relevant to the issue, but a few insights into the context...
    - client is .NET, server is Java/JBoss
    - applications are long-lived (we'll have to live with our decision for years and through many software revisions)

    Please speak up!  Your opinion counts!  Software development really is (not) a democratic process!  We want you!  Your exclamation here!

    Many, many thanks,
    Gridlocked


    Sunday, January 24, 2010 1:37 AM

All replies

  • Personally I'd write a single service but rather than having a single operation and optional parameters, I'd have 4 operations and no optional parameters.  I personally favor C# so I'd go with a WCF service with 4 operations and I'd write it in C#.  I've been writing code professionally for about 18 years.
    Tim
    Sunday, January 24, 2010 4:10 PM
  • I am by no means a SOA expert, but I have substantial web services experience (7ish years) in multiple organizations.  I think one of the ideas behind SOA is to create services that organize related functionality into a single service that can facilitate the need across the domain.  In your example in your case some sort of a "UserService" that will have many operations on it including UnlockUser, ChangePassword etc.  I would also suggest create request/response DTO objects as a contract for the request and response messages.
    Monday, January 25, 2010 2:07 PM
  • Option A) reads correct to me.
    It provides sufficient granularity and autonomity to control each business function which is inline with key SOA tenet "Services should be autonomous".

    option B) is a variation of Option A) and is called Composite Service. Based on the inputs provide, it will invoke independent service in option A).

    To me option B) doesnt provide any value add here, one would go for option B) kind of service modeling when one would like to invoke services in batch and not make chatty calls. However in this application context, the services mentioned in A) are modeled at right granualarity as they would be directly required by business users/actors.

    The option A) will also help you control security of services in more fluent manner.

    hope this helps.
    Regards
    Suds...
    p.s - kindly mark helpful, if helps.
    Thursday, January 28, 2010 6:37 AM

  • I'd never think of approach A. It will be overkill of design/patterns by having different services to update different attributes of an entity.

    I'd not directly support the approach B either. From your description it seems that all the attributes are kind of a User entity. I'd start by having a single update method which will update all the attributes of User, something like this-

    class UserService

        {

     

            public void Update(User user)

            {

                //... update user fields.

            }

        }

    It'll make code simple. I'll not go behind the fields that are changed and only update them in database. Above method will update everything. I'd try to keep it simple

    However, if there some policy decision then you might need to create other methods.  e.g. above method has one drawback - update method can be called by normal user and administrator as well. But you want to restrict (which you probably want) that only Administrator should be able to unlock the user then it be advisable to have separate method to Unlock user, which can only be called by Administrator. Similarly you can decide the fate of other methods (UpdatePassword, UpdateStatus). It might also turn out (I'm not sure about your situation) that you club all the three methods (UnlockUser, UpdatePassword and UpdateStatus) in one method "UpdateUserCredentials(User, UserCredentital)".

    Thanks,
    Gurmit 

    Friday, January 29, 2010 8:00 AM