Background Knowledge

1. SEN 972Java EE ProgrammingCourse IntroductionApplication Server Technology and the Java 2 Enterprise Edition

2. Background Knowledge What you need to know: • JavaIt’s not necessary to understand all the different packages - just knowing how to program in it. • Relational DatabasesBasic understanding, including how tables are related and how to execute transactions using SQL. • How is your Java Background? Do we need to review some basics?

3. Java EE Programming Why You’re Here: • This is some of the hottest technology in the classifieds. • Experience in Java 2EE (and more importantly, a working understanding of a distributed architecture) will keep you extremely marketable.

4. Application Servers • What is it? • A server, similar to a web server, that provides middle tier logic to Enterprise applications. • They do more then just serve web pages and provide middle layer support for web applications.

5. Application Servers - Example • A web page with a <submit> button that invokes a Perl script or a Java class could be served by a web server. • If that Java class used data from an Enterprise database (such as Oracle) and was shared by other applications, this class may be better implemented in an application server, rather then just a web server.

6. Application Server “Technology” • Various levels of technology exist within an application server. • Usually N-Tier, meaning there a many transparent client/server relationships working together, to form what appears to the user as a single application. • HTTP Server • EJB Server

7. Application Server “Technology” • JDBCProvides connectivity to databases from Java classes. • JNDIEnables components to “find” other components within an enterprise system. • ServletsJava’s answer to traditional CGI, with the advanced ability to stay connected (and persist) in the server between calls. • JSPJava Server Pages, which allows for embedded Java calls (similar to PHP/C). Used for presentation layer.

8. Application Server “Technology” • EJBEnterprise Java Beans provide business logic and database connectivity and allow sharing of resources between many different applications. • RMIAllows separate java applications/layers to communicate with each other. It’s a level above sockets. • JMSJava messaging is a newer technology in J2EE, providing a publish/subscribe & point-to-point framework.

9. Why Use Java?There are others: VB, C++, Pascal, Prolog, etc... • Portability (especially for web applications) • One standard (not like various flavors of C) • Deployable on all leading web/app servers, with minimal modifications needed when you change servers (java has defined standard API’s/Protocols for server communication)

10. Why Use Java? • Java provides a single technology for an entire enterprise system(compared to combining for other applications: CGI/Perl/C,ASP/VBScript,DCOM/C++,etc…)

11. Tech Review • Clients: • HTML • Applets • Java Applications • VB • C++ • Delphi • VBScript • JavaScript • PHP • Cold Fusion • Flash

12. Tech Review • Web Servers • HTML • JSP • ASP • Servlets • PHP • Cold Fusion • Perl • C • CGI

13. Tech Review • Databases • Relational Tables • Primary Keys • Foreign Keys • Schemas • Operations (SELECT, INSERT, UPDATE, DELETE) • Transaction Blocks

14. Client/ServerandDistributed SystemsAn Overview

15. Distributed Systems Overview • What is a distributed system? • “one in which components located at networked computers communicate and coordinate their actions by passing messages” • Most enterprise and web applications fall under the umbrella of distributed systems

16. Distributed Systems Consequences • Concurrency • work is happening at the same time on different computers and share resources • No global clock • all computers on the network do NOT share the same clock or time – no notion of correcttime • Independent failures • faults in a network result in isolation of the computers that are connected to it • each component can fail independently • Motivation to construct a distributed system • desire to share resources

17. Examples of Distributed Systems • Internet – WWW, email, file transfer • Intranet – firewalls, routers, servers • Mobile and ubiquitous computing • Laptops • Handheld devices (PDAs, mobile phones, smart watches, smart appliances)

18. intranet % % ISP % % backbone satellite link desktop computer: server: network link: A Typical Portion of the Internet

19. A Typical Intranet

20. Portable and Handheld Devices in a Distributed System

21. http://www.google.comlsearch?q=kindberg www.google.com Browsers Web servers Internet www.cdk3.net http://www.cdk3.net/ www.w3c.org http://www.w3c.org/Protocols/Activity.html File system of Protocols www.w3c.org Activity.html Web Servers and Web Browsers

22. Challenges of Distributed Systems • Heterogeneity • Variety and difference as applied to: • networks, computer hardware, operating systems, programming languages, implementations by different developers • Middleware • Software layer that provides a programming abstraction as well as masking the heterogeneity of the underlying networks, hardware, operating systems, and programming languages • CORBA (Common Object Request Broker) (www.omg.org) • RMI (Java Remote Invocation) – covered later in the course – only supports single programming language • Mobile code • Code sent from one computer to another to run at the destination (Java applets)

23. Challenges of Distributed Systems • Openness • Determines whether the system can be extended and re-implemented in various ways • Degree to which a new resource-sharing service can be added and be made available for use by a variety of client programs • Open distributed systems: • have key interfaces published • have a uniform communication mechanism and published interfaces to shared resources • are constructed from heterogeneous hardware and software probably from different vendors but all vendors conform to a published standard

24. Challenges of Distributed Systems • Security • Information resources are of high intrinsic value to users – security is vitally important! • Must have: • confidentiality – protection against disclosure to unauthorized individuals • integrity – protection against alteration or corruption • availability – protection against interference with the means to access the resources • Denial of service attack, Trojan horse attachment

25. Challenges of Distributed Systems • Scalability • System is scalable if it will remain effective when there is a significant increase in the number of resources and the number of users • i.e. The Internet • Challenges • Controlling the cost of physical resources • Controlling the performance loss • Preventing software resources from running out • Avoiding performance bottlenecks

26. Challenges of Distributed Systems • Failure Handling • More failure types can occur in processes and networks • Failures are partial – some components fail while others continue to function • Techniques for handling failures: • Detecting failures (checksums) • Masking failures (retransmit dropped messages) • Tolerating failures (user keeps trying) • Recovery from failures (rollback state of component) • Redundancy (hardware)

27. Challenges of Distributed Systems • Concurrency • Several clients attempt to access a shared resource at the same time • Program threads • Distributed software must be responsible for ensuring that servers and applications operate correctly in a concurrent environment

28. Challenges of Distributed Systems • Transparency • Concealment from the user and the application programmer of the separation of components in a distributed system • System is perceived as a “whole” rather than a collection of independent components • Programmer only concerned with the design of their particular applications

29. Transparency Forms • Access transparency: enables local and remote resources to be accessed using identical operations. • Location transparency: enables resources to be accessed without knowledge of their physical or network location (for example, which building or IP address). • Concurrency transparency: enables several processes to operate concurrently using shared resources without interference between them. • Replication transparency: enables multiple instances of resources to be used to increase reliability and performance without knowledge of the replicas by users or application programmers.

30. Transparency Forms • Failure transparency: enables the concealment of faults, allowing users and application programs to complete their tasks despite the failure of hardware or software components. • Mobility transparency: allows the movement of resources and clients within a system without affecting the operation of users or programs. • Performance transparency: allows the system to be reconfigured to improve performance as loads vary. • Scaling transparency: allows the system and applications to expand in scale without change to the system structure or the application algorithms.

31. The Enterprise

32. Enterprise Framework • Schema for classifying and organizing the topics related to managing the enterprise • Assists the organization to become more accountable and responsive • Shows how enterprise architecture considers the design and operation of an organization from many aspects, perspectives, and disciplines

33. Distributed System Architectures • Architecture Model – what is it? • Defines the way in which the components of systems interact with one another • Defines the way in which components are mapped onto the underlying network of computers • Decompose architecture of a distributed system into both vertical and horizontal tiers

34. Layers • Application, operating system, and hardware layers

35. Tiers – Internet Example • Three tiers – client, web server, and persistence • Each tier consists of one or more components that collectively fulfill a common purpose

36. Logical and Physical Tiers • Physical tiers • Based on the assumption that application software components found in the different tiers reside on different computers • Or, on different processors • Logical tiers • If system deployed on a single computer but has the separate software tiers

37. Physical Tiers (3) Logical Tiers (3)

38. Single Tier Architecture – Student Services Application The simplicity of single-tier architectures provides a convenient initial framework for subsequently examining more sophisticated multi-tier architectures. Tiers based on common functionality

39. Two-Tier Physical Architecture The simplified design given in the previous figure can be transformed into a two-tier physical architecture by deploying the classes related to the client aspects of the design on a different host computer from the classes related to the server aspects of the design.

40. Three-Tier Physical Architecture The simplified two tier architecture presented in the previous figure can be transformed into a three-tier physical architecture by separating the handling of persistence in the server tier into its own tier. Database replaces file I/O

41. Multi-Tier Physical Architecture Large Telecommunication’s Company The key feature of this architecture concerns the fact that any client can communicate with any web server, but these clients cannot directly communicate with other tiers.

42. Middleware • Software layer that provides an abstract programming interface that hides, via encapsulation, the details associated with heterogeneity in both the layers and tiers of distributed architecture

43. Example – Student Services – EJB as Middleware • While contemplating the design of the new student services application, you realize that using a middleware platform will result in a more robust application that can be developed in a shorter time. • A web survey identifies three major middleware contenders: • W3’s Web Services (http://www.w3.org/) • Microsoft’s .Net (http://www.microsoft.com) • Sun’s EJB Application Server (http://java.sun.com)

44. Example Architecture A multi-tier architecture for the student services application utilizing a Java 2 Enterprise Edition (J2EE), Java Enterprise Bean (EJB) & corresponding EJB application server middleware technologies Student uses XP uses MySQL

45. Component Transaction Monitor (CTM) • Component Transaction Monitor (CTM) • Server-side application that combines the features of a traditional Transaction Processing Monitors (TPMs) and more recent distributed Object Request Brokers (ORBs) • TPM – emerged in 1960s at IBM to handle large online transaction processing associated with large systems (i.e., airline reservation system) • ORB – emerged to support the deployment of objects across a network (i.e, RMI, will study in this class)

46. Object Life Cycle • Life cycle of an object is the “life” of an object from creation, modification, and deletion • Object instance – not domain data associated with the application (saved data) • Factory Design Pattern • Often used to encapsulate the functionality associated with the life cycle maintenance of an object • This pattern separates the business logic of the domain being modeled from the object’s life cycle

47. Example: Student Factory in a Distributed System • Student Factory contains methods for creating, finding, and removing a Student object Student object contains operations associated with the domain application (i.e., addCourse (course))

48. Example: Student Factory in aDistributed System using Singleton • Factory can be conveniently implemented using a Singleton design pattern as shown in this example • Hides the actual location of the business object from the user (i.e., two Student objects located on different servers) Given this singleton design, a new Student object can be created using Java: Student aStudent = StudentFactory.getSingleton().create();

49. Persistence Tier • In multi-tier enterprise architectures, the persistence tier encapsulates the logic for saving data to, and loading data from, persistent storage • Within a CTM (application) server, enterprise information in the business-logic tier is represented using remote objects. • As with all objects, a remote object captures state by encapsulating local data as a set of attributes. Consequently, the long-term persistence of an object requires saving its attribute values to non-volatile storage.

50. Persistence Tier • Examples • Java serialized objects • Local files using XML • Databases • Design patterns developed to capture the saving of data to files or database • Data Access Object (DAO pattern)