1 / 41

Exploring N-Tier Architectures and Pooling Patterns

This informative guide delves into N-tier application architectures, covering layered structures, business logic layers, data access, pooling patterns, and architectural design decisions. It discusses stateful vs. stateless sessions, server object pooling, entity patterns, messaging, and scalability considerations.

nataliev
Download Presentation

Exploring N-Tier Architectures and Pooling Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Application Architectures Ian Gorton, Paul Greenfield

  2. Aim • Cover some typical N-tier application architectures • Look at their strengths and weaknesses • Look at a sample complex application

  3. N-Tier Applications • Layered Architectures • Client layer taking care of user interfaces • Some number of business logic layers implementing business processes and rules • Data layer for accessing data and implementing data integrity rules

  4. N-tier Architectures • Client layer • Static Web pages • Web-based through CGI programs • Active client-side Web pages • Scripting and applets • Active server-side Web pages • Traditional client applications • Background/batch processes

  5. N-tier Architectures • Business logic • Multiple layers possible • Web scripts, server components • Distribute and replicate as necessary • Re-use of logic a primary goal • Data access • Components enforce data integrity • Isolate business logic from database • Can be partitioned and replicated

  6. Order component Scripted Web pages Customer component Payment component Order component Goods component Stock component Print invoices Delivery component Print ship requests Background processes N-tier Example Business Logic Layer Client Access Layer Data Access Layer Web server DCOM/COM * MTS * User interface app * Or other transactional ORB of your choice

  7. Pooling • Keep a shared pool of expensive or scarce resources • Database connections (ODBC, …) • Objects (COM+, EJB, …) • Allocate from pool only when needed • Release as soon as not needed • Makes stateless transactional object designs really feasible

  8. DB Connection Pooling • Database connections are… • Expensive to allocate (performance) • Limited in number (scalability)

  9. Object Pooling • Client keeps reference to object • Allocate new object on every method call • Stateless, transactional objects • Discard objects at commit time • Objects recycled to reduce costs • May only help with expensive objects

  10. Object Pooling

  11. Architectural Patterns • Common models for building systems • Stateless or stateful? • Synchronous or asynchronous? • Data layer access • Complexity and correctness • Recovery after failure • Scalability and parallelism • Simple, working and obviously correct is a good goal

  12. Stateful Session Clients Server object Server object Server object Server object Factory New Client

  13. Characteristics • One server object dedicated for each client • Server object can hold client-specific information (state) • New clients request a Factory object to create them a server object. Can be distributed. • Transactions can span multiple calls

  14. Issues • How long do server objects live? • Life of client? • Forever? reusable • What happens if a server object/node dies unexpectedly? • How do clients find a factory? • How does load balancing work if load becomes uneven?

  15. Stateless Session Server object pool Clients

  16. Characteristics • Any client can use any server • Server object pool can be distributed • Server objects maintain no state on behalf of client, and pool DB connections • Each client-server interaction is a single transaction

  17. Design Issues • How big is server object pool? • Static • Dynamic • How do clients decide which server object to connect to? • Finding servers? • Length of time they use a server • Closely related to load balancing...

  18. Stateful v Stateless • Stateless scales better in practice • Stateful may be faster • Stateless is easier to build • Stateful can be very useful in some applications: • greatly benefit from data caching • load balancing is not too much of an issue

  19. Entity Pattern Customer Server object Customer table Customer Server object Factory Customer Server object 1 2 Clients

  20. Characteristics • Server objects represent specific ‘rows’ in the database • Client use a factory to create a server object • Server objects have a get/set style interface for each attribute of the database row

  21. Issues • How is concurrency control handled? • 2 clients access same row at same time • Scalability - many remote accesses to get/set individual attributes • Plus all issues of stateful servers

  22. State(ful/less) + Entity Server object Customer Server object Customer table Server object Customer Server object

  23. Characteristics • Combines service-based patterns with entity pattern • Clients access state(ful/less) server objects (see previous slides) • Server objects create entity objects as needed • Server objects isolated from DBMS - a good thing...

  24. Issues • All of the previous ones… • Need to rely on DBMS locking to handle concurrency • Need to be careful with DBMS deadlocks • Scales only if server object and entity object in same process/node

  25. Synchronous Messaging Request Queue Server object Client Reply Queue

  26. Characteristics • Client writes a service request to a queue in a transaction, and indicates where to write the results • Server object removes request, performs service, and writes results to a reply queue (all in a transaction) • Client removes results from reply queue in a transaction

  27. Issues • Emulating synchronous behaviour with asynchronous technology • Breaking 1 transaction up in to 3 • client has to remember state for recovery purposes • How do we scale up to many clients? • many request and reply queues • many server objects • many queues per server object

  28. Asynchronous Messaging Request Queue Queue Server object State(ful/less) Server object Client

  29. Characteristics • Client makes synchronous call to server object • Server object updates DBMS, places request on queue and returns results to client in a transaction • Queue server object takes request from queue and updates DBMS in a transaction

  30. Issues • Used for delayed processing • when part of a synchronous transaction is slow • write slow part to queue transactionally • no need to delay client, process request some time later (but will get processed) • Very commonly deployed architecture, one of the strengths of messaging

  31. Example

  32. Web-based Clients Paul Greenfield

  33. The Web • A single standard user interface technology • Web browsers • A common client platform • Using HTML to get to a Web server • A common protocol • Except for …. • Many variations and standards to choose from….

  34. Static Web Pages • Static HTML • Simple forms • No complex logic • Simple HTML is very portable across browsers • Very limited as a tool for building user interfaces • No way to include user logic • Presentation/forms only

  35. CGI Scripts • Running logic on the server • The traditional UNIX way • URL references a CGI program rather than a web page • Web server runs a program or script (C, Perl, …) when the page is requested • Program/script runs and returns HTML • Complex to write and scales poorly

  36. ISAPI and NSAPI • Call a library rather than starting a program • Microsoft and Netscape APIs • Much faster than CGI (no startup time) • Call returns HTML • code has to write HTML strings • Still hard to write and complex • Java servlets are a later equivalent

  37. Client-side Scripting • Add logic to the HTML • Logic in Jscript, VBscript, … • Script sees Web page as an object • Manipulate the page being displayed • Change text, check values, hide fields,… • Portability? • MS, Netscape; v3, v4, v5, … • Useful for building dynamic, responsive Web-based user interfaces

  38. Applets • Downloadable code run inside the Web page • Java applets, ActiveX controls • Severe security restrictions? • Java sandbox (no files, little networking, …) • Code signing (ActiveX and Java) • Relegated to niche usage • Graphics, expanding indexes, viewers

  39. Server-side Scripting • Scripted Web pages with the Web server running the script • Easier programming than CGI • Script running within a Web page • Script can call on business components • Fits in with n-tier model • Script does UI/presentation functions • Can produce portable HTML • ASP (Microsoft) and JSP (SUN)

  40. N-tier Clients • Simple browsers on desktops • Good chance of portability • Simple HTML • Server-side scripted Web pages • ASP or JSP • Calling on transactional components for business processes (COM, EJB)

  41. Next Week… • CORBA

More Related