1. CS 772: Global Knowledge Networks V. “Juggy” Jagannathan CSEE, West Virginia University Feb 4, 2002

2. Evaluating Candidate Technologies for Boundary Classes Chapter 7 Based on the book: “Enterprise Java with UML” OMG Press, John Wiley and Sons, 2001.

3. Technology template Name and description: what is this technology Details: How does it work Strengths: What works best Weaknesses: It’s failings Compatible technologies Cost of adoption: expertise, product costs Suitability

4. Evaluating Swing Sun’s GUI Platform

5. Swing SUN’s GUI development framework Runs on all platform that JVM runs Clear separation of model/view Mature and stable now…

6. Gory Details Separation of Model and View – E.g. DefaultTreeModel – methods to add nodes to tree, traverse tree, remove nodes etc. – Pg 156: ComboBoxModel Implementation

7. Gory Details Event Model – Problematic event notification e.g. Pg 157 (figure 7.2) – Implementation of observer model. Pg 158 (figure 7.3) – Object interactions for the Observer pattern pg 159, figure 7.4

8. Gory Details Combining User Interface Components – Composite Pattern – pg 159, Figure 7.5 Layout managers – pg 161, figure 7.6 Putting it together – pg 162, figure 7.7 – Every association is to an interface or base class

9. Sample GUI program Pg 164, 164 Strengths – Flexibility – Cross platform support – Separation of model from view Weaknesses – Not a low-end solution – complex – Takes time to be proficient with Swing

10. Other factors Compatible Technologies – Integrates well with server-side Java technologies – RMI, JDBC, EJB Cost of adoption – Need: UI Designer, Architect, Developer

11. Suitability User interface complexity – Swing supports the entire level of UI complexity from simple data input to dynamic views of data to interactive graphics Deployment Constraints – Swing does not work with handheld devices and any web browser. Works with late model browsers – thru swing applets.

12. Other factors Number and type of users – Appropriate for small # of users – May be ok for general use within an organization or for large audience if the complexity of the interface warrants it – costs associated with install and support. – Not appropriate for a huge audience with low interest. Available bandwidth – Suitable for all bandwidth scenarios

13. Evaluating Java Servlets Sun’s web platform

14. Java Servlets HyperText Transfer Protocol (HTTP) – Communication protocol between web servers and web browsers – Connectionless protocol HTTP request – Name of the requested page, info about the browser, acceptable data types for the response, relevant cookies, and data entered by the user HTTP response – Formatted data sent by the web server, expiration date for the response, info about the server

15. Java Servlets Form data – list of name-value strings collected from the user in a form sent to the server in a HTTP request. Cookie – information about a particular site that the server sends and is stored on the client machine. HTTP servlet – a Java class that accepts an HTTP request and generates appropriate response. Servlets extend: javax.servlet.http.HTTPServlet Servlet engine – Allows a web server to redirect incoming requests to a deployed servlet.

16. Gory Details – Retrieving Form data The servlet engine creates a “HttpServletRequest” object that encapsulates the raw request and adds the form data to it. The doPost and doGet can access form data by using: getParameterNames and getParameter methods of HttpServletRequest – Sessions Tracked using cookies. Pg 171 – HTML production Producing clean and reusable HTML pages is a very difficult endeavor. Need to create a collection of reusable set of HTML production classes. – Concurrent Access

17. Evaluation Strengths – easy to learn. Weaknesses – easy to write spaghetti code and difficult to maintain and extend. Compatible technologies – HTML, DHTML, XML and JDBC, RMI, EJB. Cost of adoption – Need UI Designer, Architect, Servlet Developer

18. Suitability – UI Complexity Simple data input and static views of data – easy Customizable views – difficult – need to use javascripts Dynamic views – more difficult – can use kludges such as reloading data periodically using javascripts. Interactive graphics – not possible without resorting to other plug- ins – Deployment constraints – can support all environments. – Number and type of users – appropriate for all user communities. – Available bandwidth – generally can work with all bandwidth options with some caveats

19. XML

20. XML Basics Element Document Type Definition Parser Authoring tool

21. Gory Details Self-describing documents Parsers – Validating or non-validating – Simple API for XML (SAX) – Document Object Model (DOM)

22. Other aspects Strengths – Greatly improves data interchange between peer systems and between people and systems – Well worth the hype Weaknesses – Verbose – Good for tree structure and not so for other relationships Compatible technologies – Can be used by any Java application. Can be used to store data in the client or server. Can be used to communicate within the same system or with external systems.

23. Cost of adoption DTD author Document author Developer

24. Suitability Data transfer Services through a protocol Direct access to system services

25. Technology selection for the time card system

26. Timecard application User interface complexity: Simple data input and static view of data Deployment constraints: Late-model web browser on the internet Number and type of users: General use within an organization Available bandwidth: Dial-up internet connection Types of system interfaces: Data transfer Performance and scalability: Concurrent updates

27. Technology Selection For GUI – Could be implemented by Swing or Servlets. There is no additional advantage of using Swing. The choice is for Servlets. For system interface – XML

28. The next step UML provides package dependency diagrams. Pg 182 Figure 7.9

29. Evaluating Candidate Technologies for Control and Entity Classes Chapter 8 Based on the book: “Enterprise Java with UML” OMG Press, John Wiley and Sons, 2001.

30. Evaluating RMI

31. RMI basics Client objects communicate with server objects Stubs and skeletons Pg 184 figure 8.1

32. Gory details Classes and interfaces – Pg 185, figure 8.2 Remote object registration – E.g. code pg 186 Parameter passing – Three types: primitive data, serializable objects, remote references Thread safety

33. Development and deployment Write remote interfaces and implementation for the server Use rmic command to generate stub classes Write client applications Distribute stub classes and any common domain classes to the client Start the RMI registry Run the main application to register the remote objects with the registry Start the clients

34. Common uses of RMI Remote object that hides entity objects (Strict layering) – Pg 189, figure 8.3 – As long as the interface remains the same, the underlying entity objects can be changed without impacting the clients Direct access to entity objects (relaxed layering) – Pg 190, figure 8.4 Direct access with event notification – Pg 191, figure 8.5

35. Other factors Strengths – great starting point for developing distributed applications. Weakness – leaves scalability, fault tolerance, load balancing, data integrity to developers Compatible technologies – servlets, applications, applets Cost of adoption – Architect, RMI developer

36. Evaluating JDBC

37. JDBC gory details Java DataBase Connectivity (JDBC) Drivers, Connections, and Statements – Pg 195, figure 8.6 => sample sequence diagram on the use of drivers – Pg 196, figure 8.7 => JDBC classes New and improved result sets – Pg 197, figure 8.8

38. Other factors Strengths – good starting point for writing database independent code Weaknesses – large datasets and more complex transactions require caching, transaction management, and connection pooling. Compatible technologies – any java code. Cost of adoption – Architect, JDBC developer

39. Suitability of RMI and JDBC Evaluation parameters: – Number and type of users – Performance and scalability RMI and JDBC is good for all user categories except for large to huge audiences. Does not support load balancing. Good for read-only systems with isolated updates – not good for concurrent updates

40. EJB 1.1 evaluation

41. EJB Basics – Entity bean  entity objects in analysis model – Home interface  lifecycle objects in analysis model – Session bean  control objects in analysis model – Remote interface – Implementation – Deployment descriptor – Bean-managed persistence – Container-managed persistence – Transaction boundaries – Container – Persistence

42. Gory Details Classes and interfaces – Must provide a remote interface, home interface and an implementation class – Remote interface extends EJBObject interface – Home interface extends EJBHome interface – Each implementation must realize EntityBean interface – Figure 8.9, pg 203

43. Session beans Stateful and stateless Stateful – Need to manage state – Memory management trickier – Container needs to garbage collect Stateless – Efficient – Can be managed by a pool of session beans

44. Development Workflow Container managed persistence – Allocation of business data, business logic, and control logic to entity and session beans – Mapping entity data to persistent data store – Determining transaction boundaries and security

45. Strengths & Weaknesses Strengths – Object lifecycle management – Transaction management – Security – Persistence – Vendor neutrality – Portability and reuse Weakness – Complexity – Price tag

46. Other factors Compatible technologies Cost of adoption – Architect, Bean Developer, Deployer Suitability – Number and type of users – Performance and scalability

47. Technology selection for Timecard application Number and type of users: general use Performance and scalability: concurrent updates Conclusion: EJB has a slight edge over RMI/JDBC solution.