Layered Architecture across Boundaries

Layered Architecture across Boundaries

• adisingh

  I think, the client probably wants to build a webservice interface to the business layer objects so that the business layer is callable by not only by the applications presentation tier but also by other business layer components (in the future: SOA types ).
  
  If we look closer, webservices is a deployment wrapper for the business layer objects.
  
  So if we can design the business layer so that it can be wrapped using CORBA & Webservices deployment wrappers, the presentation layer can invoke BO's using remoting (aiding performance) and the future business components can invoke BO's using webservices (aiding re-usability).
  
  To extrapolate, if the business objects are built so that they are independent of the deployment wrapper, we can keep on adding deployment wrappers to invoke the Business objects. for ex: invoke business process using MQ message wrapper.
  
  ( I think, the only hiccup in separation is how to pass on transaction semantics to the business layer objects.)
  
  
  
  

• Sean Cromwell

  If the Web Service layer causes a performance hit in the UI this can usually be sucked up with some creative UI design such as multithreading or load on demand.
  
  We have an application with an advanced search option. There are a bunch of drop down lists that need to be populated. It would take a long time and frustrate users to wait for the all the lists to load. We send the screen with all the lists empty and then if the user wants something from a list they click a little button next to the list and just that one list gets populated on demand. This prevents long delays in UI response.
  
  

• johncmiller

  If the client insists on keeping the UI and Biz logic is seperate tiers, doesn't look like you got much of a choice, do you

  Your best bet, lure them with the topic of performance and ask them to give up their demand...

  This thread contains enough info on what are your choices...

  Cheers!

  
  
  

• Boricwa

  I hope I'm not too late on responding to this post, I managed to miss this amongst some of the other posts I was following. This is a topic near and dear to my heart.

  First off let me just say this, for all of you that are recommending remoting ... why How can you recommend using a communication style that has such a small performance benefit for such a huge compexity disadvantage. Everyone needs to read the guidance whitepaper from Rich Turner (http://msdn.microsoft.com/webservices/default.aspx pull=/library/en-us/dnwebsrv/html/asmxremotesperf.asp). I think you'll find that moving to web services will not introduce much of a performance penalty at all and if you look to host your remoted objects in IIS to get some security benefit then you actually end up paying a penalty to use remoting over WS. You'll also find that using WS today will position you better to migrate to WCF. Mainly because the programming models are more closely aligned with the WS stack.

  That however is not what got me fired up about this posting. I think Arnon says it best so far ..... LAYERS != TIERS (or LAYERS <> TIERS). I will bet that someone in your company feels like they have to be seperated because of some deep rooted understanding of distributed applications brought on by some app server/web server configuration in the Java world. Building layers in your application is a great idea, it's sort of like finding the exact right mix of chocolate, vanilla, and fruit filling. You want everything to have a unique flavor and you want it all to work together nicely.

  The idea that throwing web services in between your UI and your business is also something I would like to address here. What I want to make sure is stated is that this will NOT give you a reusable service without some careful thought and planning. The problem is typically based on how the application was envisioned. Very few projects have the benefit of defining a domain model and a set of business service interfaces before they are being saddled with some type of user interface. That user interface typically will not align directly with discrete chunks of data.

  What that means is a UI will need to sacrifice performance to focus in on how the cohesive the data is that is returned from the varying business service interfaces. This is very tricky so be sure to keep it in mind when you start to look at simply "wrapping" your business objects. I know that all sounds a bit confusing but if you've been in this situation you'll understand what I mean.

  
  
  

• brenmartin

  It's all about where you want to draw the line and make the trade off. Yes, using WS for business rule abstraction/wrapping helps you reuse across application systems amd external parties and gives additional advantages too but not great when it comes to performance. I would recommend remoting if yours is totally an internal system. Again, performance from the end-users perspective cannot be taken as the right scale.

  Assuming your BLL is in the form of assemblies, having UI & BLL on the same box obviously makes difference compared to the above-discussed case. However, if you are still implementing WS for BLL on the same web server, then you are not gaining much.

  My 2 cents...

  
  

• pixelpajas

  When it comes to distribution, performance is seldom the top reason for why you would want to distribute. In many cases performance will be hurting.
  
  Although, my top three reasons why performance could be improved ( or rather 2 of them is a big profit if the db is a bootleneck, which it often is) by distribution is
    1) The ability to use a shared cache for all clients on the bussiness server, which could lower the hit impacts on the databaseserver.
   2) Connection pooling, the business server will be able to use a single pool of connections instead of one pool per client.
   3) Client hardware. If you have complex processing, the client hardware might not be sufficent but a massive server hardware might do the trick for you.
  
  But theese three are just "nice-to-haves" in a distributed scenario. The real benefits come from things like maintainability, where you can update your bussiness layer at your server instead of all your clients. Scalability where you can loadbalance and partion the bussiness layer. Also things like security where clients can be blocked out of functionality or data from the server side.
  
  When it comes to web services, you're totally correct in that that will hurt performance, bad. Remoting is IMO a better choice for internal application distribution. In this case it might be that while today your application is the only one using the bussiness layer, tomorrow another application might want to borrow parts of it. Then a service would help you.
  
  
  

• SuperHornet

  Mr. SOAPitStop wrote:

  What that means is a UI will need to sacrifice performance to focus in on how the cohesive the data is that is returned from the varying business service interfaces. This is very tricky so be sure to keep it in mind when you start to look at simply "wrapping" your business objects. I know that all sounds a bit confusing but if you've been in this situation you'll understand what I mean.

  Hi Tom,

  That is a very sentence as you said. and even though i know you are correct, i still wanna know your view on it as well.

  "UI needs to sacrifice performance" this is somehting that I believe users are not gonna live with and there is bound to be a lot of hoo ha regarding this.

  But this gives something in return -> a service layer between UI and BL...

  But users dont care about this... Right

  At this point, could I request you to elaborate your last mentioned point with regards to my above mentioned points

  Would love to hear your thoughts..

  Thanks

  
  
  

• Andreas Asterlund

  Hi,

  First off, you have to understand that the fact that an architecture has layers does not mean it can be distributed - for example 2 layers have a very chatty interface it probably means it will be hard to have them separated into several tiers.

  You can gain performance by adding hardware (assuming you architecture is designed for than) - if you have a lot of load (e.g. connections, computations that can be parallel etc.) on a single server - but again you'd have to pre-design it to scale by the added hardware. For example a stateful server will be relatively harder to duplicate unto more than one server (compared with a stateless one)

  Also I think it is important to emphasis to you client that layer != tiers and that they are not necessarily have 1-1 mapping between them. Tiers are a hardware architecture style that can help with security , upgrades and possibly security. Layers are software architecture style which can help with easier coding, testing, security and yes sometimes performance

  HTH,

  Arnon

  
  
  
• Layered Architecture across Boundaries