410 likes | 567 Views
Application Architectures. Ian Gorton, Paul Greenfield. Aim. Cover some typical N-tier application architectures Look at their strengths and weaknesses Look at a sample complex application. N-Tier Applications. Layered Architectures Client layer taking care of user interfaces
E N D
Application Architectures Ian Gorton, Paul Greenfield
Aim • Cover some typical N-tier application architectures • Look at their strengths and weaknesses • Look at a sample complex application
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
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
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
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
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
DB Connection Pooling • Database connections are… • Expensive to allocate (performance) • Limited in number (scalability)
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
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
Stateful Session Clients Server object Server object Server object Server object Factory New Client
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
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?
Stateless Session Server object pool Clients
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
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...
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
Entity Pattern Customer Server object Customer table Customer Server object Factory Customer Server object 1 2 Clients
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
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
State(ful/less) + Entity Server object Customer Server object Customer table Server object Customer Server object
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...
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
Synchronous Messaging Request Queue Server object Client Reply Queue
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
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
Asynchronous Messaging Request Queue Queue Server object State(ful/less) Server object Client
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
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
Web-based Clients Paul Greenfield
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….
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
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
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
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
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
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)
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)
Next Week… • CORBA