Recipes for Use With Thin Clients Dave Ensor BMC Software

Agenda Introduction Issues Conclusions Key Choices for Web Deployment Remember Client/Server? Current Best Practice 300% Java examined Planning Server Distribution Conclusions

Introduction Application Architecture? It’s the web Three easy pieces “Run anywhere” Ease of use Three easy pieces Browser Web Server Data Server Now the problems begin Data Management Presentation Management Application Logic

Architectural Issues I Intranet or Extranet or Internet? Has fundamental impact on other choices Browser Make & Version Independence Security Firewall? DMZ?

Net Worlds The Internet An Extranet An Intranet Fire Wall Customers Local Users Stock Suppliers Orders

Architectural Issues II Web Server Oracle Instance Oracle Application Server Other Programming Language At the interface (D)HTML, JavaScript In the middle Java Servlets In the database Java, PL/SQL

Deployment Choices Web servers How many? Data Servers Distributed? Distribution algorithm Functional Geographic Data Servers Distributed? Clustered? Fail-safe?

Remember Client/Server? Two drivers Desire to leverage cheap desktop devices Desire for Graphical User Interfaces (GUI’s) Apparently a winning combination Desktop manages the pixels Server manages the data Where to run application logic? Stock

Expectations for Distribution Lower Cost Faster Response Greater Availability Greater Control Greater Throughput The reality was different

Network Limits The major problems Bandwidth Packet rates Web more so than Client/Server Packet rates Message round trip times The solutions Hardware & Software Improvements Encapsulation Architectural Improvements

Bandwidth Typical screen entry < 100 Typical screen data ~ 2K ? Typical server messages ~ 10k ? Typical Java Applet ~ 200k ? >= 0.0096 MHz 10 MHz 100 Mhz

Packet Rates Per card Perhaps 1,500/second

Message Round Trip Times 500 msec ~2 msec ~1 msec

* plus network load for message transfer Load Distribution Load Presentation Management High* in short bursts Application Logic Low* can be increased through design High* and typically continuous Data Management * plus network load for message transfer

Presentation Management Load Distribution Presentation Management Message Passing Message Passing Application Logic Message Passing Message Passing Data Management Not to scale

Current Best Practice Interface Layout (& Logic?) Three tier architecture Interface Layout (& Logic?) Conventional App, Applet (D)HTML + JavaScript Application Logic within Dedicated Web Server Transaction Manager DBMS Packaged Procedures Data Management Logic Triggers Declarative Constraints Interface Application Data Management Browser Web Server Data Server

Current Best Practice Interface Layout (& Logic?) Application Logic Encapsulate & Separate Interface Layout (& Logic?) Application Logic Data Management Logic Minimize Network Traffic Limit Process Counts Connection Counts Interface Application Data Management

Three tier architectures Markedly superior at handling heterogeneity Across the interfaces No longer an issue! Across the data servers Sybase Windows Windows CE Oracle Motif IMS/DB Embedded

300% Java Examined Java on the client Should be the exception rather than the rule Java on the App Server Potentially a good choice Java on the Data Server PL/SQL still the language of choice for embedded SQL? Total 100% ~10% 100% ~75% 100% ~10% 300% <100%

Applet Avoidance HTML Capable of presenting most data clearly XML Overcomes most of the issues with HTML Only operable in the latest browser releases DHTML and JavaScript Not as pure as an applet But much less to download Allows local validation

Client-side Logic How far can you get with just HTML? Anywhere with an airport! So when do you need Java at the client?

Using win32 calls Necessary? Desirable? More is possible But is it Interactive design may have to be re-learnt to completely avoid it …

… much the same is possible in Java

Key questions OK, Mr Architect. You’re a smart guy. Tell me some advantages of complex client-side validation Then tell me some advantages of other client-side application logic

Planning Server Distribution Between Browsers and App Servers Only two cases LAN High bandwidth, fast round trips WAN Distance is not a problem Round trip times & bandwidth are major issues Between App Servers and Data Servers Normal rules apply Minimize network traffic Place high volumes on “short” network paths

Planning Server Distribution Navigation between App Servers via HTML Links Multiple Databases can work well Single Physical Site may be an advantage

Failure Resilience App Servers scale well The paradox The answer cookies can ease failover issues The paradox The web is absolutely 365*24*7 Database outages are still required e.g. logical schema changes The answer The application must cope Pended transactions? Allowable failure rate?

Conclusions Use web technology Put application rules on servers A middle tier is inevitable But it can share hardware KISS Keep the client thin e.g. HTML Control the message traffic Between client & server Between cooperating servers Leverage the paradigm shift in the interface Web Server Data Server Browsers