locked
SOA decoupling: Recommended practices? RRS feed

  • Question

  • Hi,

    I have read this page from Udi, the author of nServiceBus. In particular the recording about "SOA in the E-VAN" is very intersting. In there, it's suggested that a decoupled service delivers all UI. From a general point of view how do you guys see this, does that make sense to you? For example consider a product service that delivers a list of products. It does so with a complete UI interpretation (e.g. returns a table in Html).

    I have my concerns (and see some potential problems) but before I write them I would like to hear your thoughts about this approach...pros/cons etc. Is it a usable approach as a general SOA how-to guideline?

    Tuesday, November 17, 2009 9:42 AM

Answers

  • hi
    No i didnt watch the video, but i dont see any reason to do it the way it is mentioned unless the applications focus is to deliver UI as service than business logic.

    In business process the business logic, business rules are complicated enough to mix them with presentation logic. The above scenario may be valid if the UI is delivered as xml to mobile or other form factor devices.

    Otherwise it defeats SOA principles like Services should be autonomous, must have boundary.

    hope helps.
    Suds
    • Marked as answer by Werner Clausen Tuesday, November 17, 2009 9:18 PM
    Tuesday, November 17, 2009 2:25 PM
  • Hi Werner,

    What i meant here is that for last some years, SOA has become a buzzword due to which sometime people fell into this trap before understanding its consequenses.

    I have seen 2-3 projects of large clients which were envisaged as SOA projects but later ran up into trouble because of the complexity,performance lapse,governance issues and money involved in SOA implementation.

    What i meant to convey in my previous post is that if you are envisaging/architecting a system where you have identified more than 100 services in your application, then it  makes sense to go for SOA based approach. Otherwise true SOA(as mentioned in UDI presentation with seperation of sevices at each layer upto database) will add many more undesired layers of indirections,which will lead to all types of disadvantages.

    Hope i am able to make sense.

    Cheers
    Bhaskar
    -----------------

    Please mark this as answer if this post helps you

    • Marked as answer by Werner Clausen Thursday, November 19, 2009 7:14 AM
    Thursday, November 19, 2009 4:35 AM

All replies

  • hi
    Usually the services should return the business functionality and not the presentation logic/html, etc.
    e.g. In above example it should just return the list of products. Bundling UI interpretation logic with services is NOT at all a good practice unless there are specific valid reasons to implement it.

    Then the services can be consumed by any medium/device and render it as per the UI formats defined for that device.
    This is the whole idea behind seperating presentation logic from business and database so that it can be independently hosted for scalability, can be used to do plug and play.

    hope this helps.
    Regards
    Suds
    Tuesday, November 17, 2009 2:04 PM
  • hi
    Usually the services should return the business functionality and not the presentation logic/html, etc.
    e.g. In above example it should just return the list of products. Bundling UI interpretation logic with services is NOT at all a good practice unless there are specific valid reasons to implement it.

    Then the services can be consumed by any medium/device and render it as per the UI formats defined for that device.
    This is the whole idea behind seperating presentation logic from business and database so that it can be independently hosted for scalability, can be used to do plug and play.

    hope this helps.
    Regards
    Suds

    Well I'm 'glad' you see it this way actually - because (not surprisingly) this was also my guidline(s) until I saw this guide from Udi. Did you watch the video? Apparantly having the service supplying UI is done on both Ebay and Amazon (at least this is how I interpret it). And I have the higest respect for the author, Udi, so I need to study this more... 

    Anyone else have a comment?
    Tuesday, November 17, 2009 2:16 PM
  • hi
    No i didnt watch the video, but i dont see any reason to do it the way it is mentioned unless the applications focus is to deliver UI as service than business logic.

    In business process the business logic, business rules are complicated enough to mix them with presentation logic. The above scenario may be valid if the UI is delivered as xml to mobile or other form factor devices.

    Otherwise it defeats SOA principles like Services should be autonomous, must have boundary.

    hope helps.
    Suds
    • Marked as answer by Werner Clausen Tuesday, November 17, 2009 9:18 PM
    Tuesday, November 17, 2009 2:25 PM
  • Thanks for your thoughts Sudhanshu.
    Tuesday, November 17, 2009 9:18 PM
  • Hi,

    The presentation mentioned by you has all the correct content. The only things to be taken care while implementing and deciding on this, is that
    SOA should only be implemented when services count should be more than 100 (Ballpark figure). Otherwise you will land in trouble while implementing seperation of boundaries at every layer,lapse in performance while sharing the essential data at database layer through publish/subscribe and while implementing SOA governance and ESB(though it is not always required).

    Cheers
    Bhaskar
    -----------------

    Please mark this as answer if this post helps you

    Wednesday, November 18, 2009 9:03 AM
  • Hi,

    The presentation mentioned by you has all the correct content. The only things to be taken care while implementing and deciding on this, is that
    SOA should only be implemented when services count should be more than 100 (Ballpark figure). Otherwise you will land in trouble while implementing seperation of boundaries at every layer,lapse in performance while sharing the essential data at database layer through publish/subscribe and while implementing SOA governance and ESB(though it is not always required).

    Cheers
    Bhaskar
    -----------------

    Please mark this as answer if this post helps you


    Hi Bhaskar,

    I'm not sure I understand exactly what you mean here. Are you saying that the service structure (from Udi) is only 'valid' for large SOA's?

    (depending on your answer I have some more questions :) )




    Wednesday, November 18, 2009 12:54 PM
  • Hi Werner,

    What i meant here is that for last some years, SOA has become a buzzword due to which sometime people fell into this trap before understanding its consequenses.

    I have seen 2-3 projects of large clients which were envisaged as SOA projects but later ran up into trouble because of the complexity,performance lapse,governance issues and money involved in SOA implementation.

    What i meant to convey in my previous post is that if you are envisaging/architecting a system where you have identified more than 100 services in your application, then it  makes sense to go for SOA based approach. Otherwise true SOA(as mentioned in UDI presentation with seperation of sevices at each layer upto database) will add many more undesired layers of indirections,which will lead to all types of disadvantages.

    Hope i am able to make sense.

    Cheers
    Bhaskar
    -----------------

    Please mark this as answer if this post helps you

    • Marked as answer by Werner Clausen Thursday, November 19, 2009 7:14 AM
    Thursday, November 19, 2009 4:35 AM
  • Hi Werner,

    What i meant here is that for last some years, SOA has become a buzzword due to which sometime people fell into this trap before understanding its consequenses.

    I have seen 2-3 projects of large clients which were envisaged as SOA projects but later ran up into trouble because of the complexity,performance lapse,governance issues and money involved in SOA implementation.

    What i meant to convey in my previous post is that if you are envisaging/architecting a system where you have identified more than 100 services in your application, then it  makes sense to go for SOA based approach. Otherwise true SOA(as mentioned in UDI presentation with seperation of sevices at each layer upto database) will add many more undesired layers of indirections,which will lead to all types of disadvantages.

    Hope i am able to make sense.

    Cheers
    Bhaskar
    -----------------

    Please mark this as answer if this post helps you


    Indeed, and I cant argue with that since I have no experience of really large scale SOA's - but it explains the guide on Udi's website. Also I feel strongly that for my organization (small-midsize company) a full scale SOA (including UI) will, as you say, result in more disadvantages than advantages.

    This also means that I dont have any more questions - Thanks :)


    Thursday, November 19, 2009 7:13 AM