Distributed Object Computing and Java

1. Distributed Object Computing and Java Wei Lin, Xu Ma Walter McClure, Chengzhong Wang Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 {weilin,xma,czwang}@engr.uconn.edu bmp@neca.com

2. Motivation • Distributed Object Computing • Interaction Among Various Components • Large-scale Software Systems Over Heterogeneous Platforms and Networks • Java is an Excellent Candidate to Implement Distributed Systems • Java Features Support DOC • Middleware and Distributed Architectures • Enterprise JavaBeans • Database Support • Java and XML • and more...

3. Objectives • Investigate the Current State of the Art of Java in Support of DOC • Focus on Java Support of Enterprise Computing • Interoperability of Servers, databases, COTs, and Legacy Applications • Commercial Products • Explore and Predict the future with Respect to emerging and potential tools and technologies

4. Overview of Presentation • Distributed Computing • Middleware and Distributed Architectures • Survey of Distributed Architectures • CORBA • IIOP • RMI • JavaSpaces • XML and Java • Java Database Support • JDBC • SQLJ embedded SQL • Object-relational Mapping (ODMG Java Binding) • Enterprise JavaBeans • Conclusions and Future Research

5. Why Distributed Applications • Evolution of Current Systems • First there were Mainframes • Hierarchical Databases and Dumb Terminals • All software was monolithic • User Interface, Business Logic, and Data access were all combined together into single application. • Client/Server Architecture(Two-tier) • GUI would reside on client, Database on server, and business logic on client, server, or both. • Client/Server(Multi-tier) • Further separates application layers into components. • Shields client from changes to other parts of system

6. Next Step: Distributed Systems • Brings Concept of Multi-Tier Client/Server Systems to Natural Conclusion: • Business Logic and Data Access are no longer differentiated. • Functionality of application is exposed as objects. • Can interact with other objects in that system as well as other systems. • Furnishes Utmost Flexibility • Communication is constrained by component interface definitions. • Specify functionality and implementations of that functionality. • Implementations can be altered significantly without affecting other components throughout the system.

7. Why Distributed Computing • Continues evolution of computer systems from multi-tier client/server architectures. • Improves concurrency through connectivity and internetworking. • Replication of systems will produce more reliable and available applications. • Scalability and portability will be amplified by modularity. • Dynamic configuration and reconfiguration of the applications will help extend them throughout the enterprise. • System itself becomes more effective by availability of open systems and shared resources.

8. Why Distributed Computing • Continues evolution of computer systems from multi-tier client/server architectures. • Distribute related processing among multiple resources. • Decentralizes nature of the enterprise. • Processing power is no longer central, but spread over the network. • Heterogeneous environments pose challenge to software components of system to exploit their power. • Distributed computing offers software to use full potential of the enterprise.

9. Java and Distributed Object Computing • Java’s extensibility and affinity for the Internet and networking technologies makes it ideal to develop distributed applications. • Programming models offered by Java technology offer platforms to develop simpler and more powerful applications. • Java can be used to develop applications in heterogeneous and homogeneous environments. • Extensions can be built on top of current Java architectures to leverage the technology with current systems in place. • New systems built on top of Java technologies offer robust, dynamic, and scalable solutions.

10. Distributed Object Computing and Java Middleware and Architectures for Distributed Systems

11. CORBA • Common Object Request Broker Architecture • Facilitates communication of application components and objects across a distributed, heterogeneous environment. • Language and platform independent. • Interfaces are defined for objects across the network. • Provide interoperability for other objects communicating with them. • Objects across the network are passed by reference. • Underlying functionality of architecture provided through the Object Request Broker.

12. Object Request Broker(ORB) • Facilitates the client/server relationship between components and their objects. • All communication among distributed components handled by ORB. • Comprises all mechanisms needed to: • Find and identify objects across the system. • Manage connections of various components across the network. • Monitor the delivery of data. • Provides transparency to the users of objects in the application. • Translate all parameters into format for transportation. • -Process of marshaling and unmarshaling.

13. Object Requests to other Objects Client Server Object Reference to Server Network ORB ORB Orb finds server ORB finds object being referenced. The client has no knowledge of where the object resides. Reference to that object is passed back to the client where the method is invoked. Client Server Method Invocation Method Invocation Network ORB ORB Unmarshall Parameters Marshall Parameters Client invokes method on that reference which in turn invokes it on the server. The ORB marshals and unmarshals the parameters as shown. Client Server Object Reference to Server Network ORB ORB Unmarshall Return Value Marshall Return Value ORB returns value in marshaled form which is then unmarshaled for by the client’s ORB

14. Interface Definition Language(IDL) • When a client makes a request on an object methods supported by that object must be known. • IDL defines interfaces; thus interactions between application components. • Provides basic framework for outlining the objects handled by the ORB. • Interface determines types of requests that can be made on the object. • Compiled IDL code generates client stubs and server skeletons. • Stubs and skeletons map IDL interface specifications to language specific implementations of those interfaces.

15. Object Adapters • Object adapters interface a component’s implementation with its ORB. • Common set of operations for accessing ORB. • Connect CORBA objects and ORB itself. • Maps interface of a called object to the expected interface of the client. • Register CORBA objects and create object references to those objects. • Object Adapters sanction the diversity of objects and implementations that can be developed throughout the CORBA architecture. • Ensures to keep ORB as simple as possible. • Without OAs, variety of objects that could interface with ORB would be very limited.

16. Internet Inter-Orb Protocol(IIOP) • The different ORBs in use need a standard protocol to communicate over. • The General Inter-Orb Protocol(GIOP) is a collection of message requests ORBs can make over a network. • Adherence to this standard ensures ORBs from different vendors will be able to interoperate. • The GIOP was mapped to TCP/IP to create the Internet Inter-Orb Protocol. • Maps GIOP connections to TCP/IP sockets. • Allows ORBs to use Internet as backbone. • Transport protocol which allows other architectures to interface with CORBA applications, i.e. Java RMI

17. Extending CORBA’s Functionality • Additional functionality is needed to build upon the ORB and object adapters to create enterprise-class-distributed applications. • The OMG provides interfaces through which the additional functionality is offered. • Implementations of these services is up to the vendors. • CORBAservices and CORBAfacilities provide additional horizontal and vertical functionality to the CORBA architecture. • CORBAservices are useful to all applications. • CORBAfacilities provides general facilities and specialized facilities.

18. CORBA and Java • Creating CORBA applications with Java will require a Java enabled ORB as well as an IDL compiler. • Java IDL is an ORB available by SUN for CORBA applications • idl2java compiler will map an IDL interface to generate client stubs and server skeletons in Java. • Java fits well with CORBA due to architectural similarities. • CORBA’s module construct is analogous to Java’s package construct. • CORBA use of interfaces directly corresponds with that of Java

19. CORBA and Java • Creating CORBA applications with Java will require a Java enabled ORB as well as an IDL compiler. • Java IDL is an ORB available by SUN for CORBA applications • idl2java compiler will map an IDL interface to generate client stubs and server skeletons in Java. • Java fits well with CORBA due to architectural similarities. • CORBA’s module construct is analogous to Java’s package construct. • CORBA use of interfaces directly corresponds with that of Java

20. Java RMI • Simple and direct model for distributed computing. • Java-to-Java distributed solution. • Three layer architecture. • Stubs/Skeletons: Client side stubs and server side skeletons • Remote reference layer: Reference/invocation behavior. • Transport: Connection set up and management and remote object tracking. • Boundary at each layer is defined by a specific interface and protocol. • Each layer can be replaced by an alternate implementation without affecting other layers in the system.

21. Java RMI • RMI can pass full objects as arguments and return values. • RMI can move class implementations from client to server and server to client. • Ability to pass behavior. • Building distributed applications is • a four step process. • Define interfaces to remote objects. • Implement remote objects. • Run rmic on remote implementation classes. • Make code network accessible.

22. Passing Behavior • Ability to move behavior(class implementations) across the network provides maximum flexibility. • Changing server policies would only require one new Java class to be installed on on server. • Example: Server Defined Policy • Suppose a current application enforces specific policies. • Client could upload behavior from the server with a simple method call. • Client receives implementation and offloads processing to client. • Ability to pass objects by value optimizes distributed architecture. Much of the processing for applications can occur locally.

23. Transport Protocols • Original protocol which RMI operated over was the Java Remote Method Protocol(JRMP). • Addition of IIOP to RMI transport protocols enabled architecture to interface with CORBA objects.

24. Extensions on top of Java RMI • New interfaces that sit on top of Java RMI • Leasing • Allows Java objects to negotiate and establish contracts with each other for the use of its resources. • Enhances reliability and fault tolerance by providing a means for Java objects to react to failures in the system. • Transactions • Support consistency over a set of operations between participating objects. • Operations can be grouped to guarantee completion of all or none.

25. Extensions on top of Java RMI • Distributed Events • Provide a system for objects to register to be notified when state changes of objects occur. • Enables reliable event-based programming in distributed applications.

26. JavaSpaces • Unified mechanism for dynamic communication, coordination, and sharing of objects between Java-based network resources such as clients and servers. • No need to track client, server, or intermediate associations of objects by requester or provider. • Full objects can be stored as entries into the space. • Simplifies creating distributed applications. • Can be used with existing software infra-structures. • Decouples the providers and requestors of network services by delivering a unified space for sharing, communication, and coordination.

27. JavaSpaces • JavaSpaces acts like dynamic networked marketplace for distributed objects. • A JavaSpaces server holds entries. • An entry is a typed group of objects.

28. Goals of JavaSpaces Technology • Simple programming interface. • Easier development using less code. • One simple interface can be used for sharing, cooperation, and communication of objects. • Legacy interoperability. • Objects can be stored as data and behavior. • Network resources can communicate asynchronously. • Multiple implementations are possible, including database connectivity. • Service implementations will be transparent. All entries will operate in the same manner.

29. JavaSpaces: Stock Trading Example • Stock trading system would exchange entries containing stocks, owners, bids, quantities, portfolio, and live feed and graphic applets. • Seller places entry in the space and requests to be notified when there is an interested buyer. • Anonymous buyers read for stocks that are attractive to them. • Buyer determines to buy a stock and places a bid entry. • Seller is notified that bid entry has been placed. • Seller could send code to buyer to complete the purchase. • This example could be extended greatly using leases, transactions, and distributed events.

30. Distributed Persistence and Distributed Algorithms • JavaSpaces is to help address these two issues. • Distributed Persistence • Provides ability to store related objects and retrieve them based on value-matching lookup for specific fields. • Distributed Algorithms • Can be modeled as a flow of objects between participants. • Different from traditional distributed architectures which is to create method-call-like protocols . • JavaSpaces implements “flow of objects” • Protocols are based on the movement of objects in and out of JavaSpaces implementation

31. JavaSpaces • JavaSpaces is a way of building distributed systems. • The requestor and provider of network services can be decoupled by using objects exchanged in one or more spaces. • Technology provides reliable distributed storage for the objects in the system.

32. What is XML? • XML stands for Extensible Markup Language, which is a subset of SGML • Different between XML and HTML • HTML is a markup language; XML is a meta language, which can be used to define markup language. • HTML defines presentation structure; XML defines data structure

33. XML 1.0 • W3C Recommendation 2/10/98 • XML Documents • Logical structure: properly nested elements • Physical structure: properly nested entities • Well-formed XML Documents • Valid XML Documents • BNF document ::= prolog element Misc* prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? doctypedecl ::= ‘<!DOCTYPE’ S Name (S ExternalID)? S? (‘[‘ (markupdecl | PEReference | S)* ‘]’ S?)? ‘>’ markupdecl ::= elementdecl | AttlistDecl | EntityDecl | NOtationDecl | PI | Comment element ::=EmptyElemTag | Stag content Etag

34. DTD - Document Type Definition • document type definition contains markup declarations that provide a grammar for a class of documents. This grammar is known as a document type definition, or DTD. • Element type declaration • Attribute-list declaration • Entity declaration • Notation declaration

35. XML Document Example - DTD <!-- DTD for Shakespeare J. Bosak 1994.03.01, 1997.01.02 --> <!-- Revised for case sensitivity 1997.09.10 --> <!-- Revised for XML 1.0 conformity 1998.01.27 (thanks to Eve Maler) --> <!-- <!ENTITY amp "&#38;#38;"> --> <!ELEMENT PLAY (TITLE, FM, PERSONAE, SCNDESCR, PLAYSUBT, INDUCT?, PROLOGUE?, ACT+, EPILOGUE?)> <!ELEMENT TITLE (#PCDATA)> <!ELEMENT FM (P+)> <!ELEMENT P (#PCDATA)> <!ELEMENT PERSONAE (TITLE, (PERSONA | PGROUP)+)> <!ELEMENT PGROUP (PERSONA+, GRPDESCR)> <!ELEMENT PERSONA (#PCDATA)> <!ELEMENT GRPDESCR (#PCDATA)> <!ELEMENT SCNDESCR (#PCDATA)> <!ELEMENT PLAYSUBT (#PCDATA)> <!ELEMENT INDUCT (TITLE, SUBTITLE*, (SCENE+|(SPEECH|STAGEDIR|SUBHEAD)+))> <!ELEMENT ACT (TITLE, SUBTITLE*, PROLOGUE?, SCENE+, EPILOGUE?)> <!ELEMENT SCENE (TITLE, SUBTITLE*, (SPEECH | STAGEDIR | SUBHEAD)+)> <!ELEMENT PROLOGUE (TITLE, SUBTITLE*, (STAGEDIR | SPEECH)+)> <!ELEMENT EPILOGUE (TITLE, SUBTITLE*, (STAGEDIR | SPEECH)+)> <!ELEMENT SPEECH (SPEAKER+, (LINE | STAGEDIR | SUBHEAD)+)> <!ELEMENT SPEAKER (#PCDATA)> <!ELEMENT LINE (#PCDATA | STAGEDIR)*> <!ELEMENT STAGEDIR (#PCDATA)> <!ELEMENT SUBTITLE (#PCDATA)> <!ELEMENT SUBHEAD (#PCDATA)>

36. XML Document Example - Data <?xml version="1.0"?> <!DOCTYPE PLAY SYSTEM "play.dtd"> <PLAY> <TITLE>The Tragedy of Richard the Third</TITLE> <FM> <P>Text placed in the public domain by Moby Lexical Tools, 1992.</P> <P>SGML markup by Jon Bosak, 1992-1994.</P> <P>XML version by Jon Bosak, 1996-1998.</P> <P>This work may be freely copied and distributed worldwide.</P> </FM> <PERSONAE> ... </PERSONAE> <SCNDESCR>SCENE England.</SCNDESCR> <PLAYSUBT>KING RICHARD III</PLAYSUBT> <ACT><TITLE>ACT I</TITLE> ... </ACT> ...... </PLAY>

37. DOM - Document Object Model • An application programming interface for HTML and XML documents • Language-independent specification: defined in OMG IDL • Language bindings for Java and ECMAScript • HTML or XML document <-> object tree • DOM (Core) Level1 and DOM (HTML) Leve1

38. The DOM Structure Model • Interface Node and NodeList • Derived interfaces • Document • DocumentFragment • DocumentType -- no children • EntityReference • Element • Attr • ProcessingInstruction --no children • Comment -- no children • CDATASection -- no children • Entity • Notation • Others

39. Portable Data/Portable Code • Sun Microsystem’s vision of XML technology • Project X • Java Platform Standard Extension for XML • Provide basic XML functionality to read, manipulate, and generate text. • Conform to the XML1.0 specification and (DOM) Level 1 Core Recommendation • Conversion between Java Class/Bean and XML document • IBM’s BeanML • Bluestone’s XwingML

40. Conclusions - XML and Java, the Natural Companions • XML’s markup and charater data are encode in Unicode and Java intrinsically supports the Unicode standard • XML structures map easily to Java object structures • Both Java and XML are portable across platforms • Many XML components are already available for Java, from parsers to XSL and Xlink engines • Many of the core standards for processing XML are developed with Java in mind, I.e. DOM, SAX, etc. • Risks: security

41. Java Database SupportA call-level interface:JDBC • Low Level, Invoke SQL Commands Directly • A Base Upon Which to Build Higher-level Interfaces and Tools, such as • SQLJ • Java Blend • What does JDBC do? • Establish a Connection with a Database • Send SQL Statements • Process the Results • Latest Update: JDBC 2.0 API • Core API • Standard Extensions

42. Java Database SupportJDBC 2.0 API • New Features of JDBC Core API • Scrollable Result Sets • Result Sets that can be Updated • Batch Updates • SQL3 Data Type Support (SQL types ARRAY, BLOB, CLOB, STRUCT, DISTINCT and REF) • Custom Mapping of SQL3 User-Defined Types to Java Classes • Storing Java Objects in an Object-Relational Database

43. Java Database SupportJDBC 2.0 API • JDBC 2.0 API Standard Extension • Rowset • Establishing Database Connections Using DataSource Objects and the Java Naming and Directory InterfaceTM (JNDI) • Connection Pooling • Distributed Transactions

44. Java Database SupportJDBC Product A Distributed Object JDBC Architecture OPENjdbc, the JDBC Driver for DataBroker CORBA-based JDBC solution provides a complete technology bridge from current to future IT solutions

45. Java Database SupportEmbedded SQL Statements:SQLJ • A Language that Embeds Static SQL in Java Program • Specified by Oracle, IBM and Compaq's Tandem Jointly, Accepted as ANSI Standard in December 1998 • How Does SQLJ work?

46. Java Database SupportSQLJ Features • Preceded by: #sql • #sql { UPDATE TAB SET COL1=:x WHERE COL2>:y AND COL3<:z }; • Provides Application Developers with a Higher-level Programming Interface for Static SQL • SQLJ translator performs type-checking and schema-checking of SQL statements at program development time • SQLJ Runtime, a Thin Layer of Pure Java Code above a JDBC Driver • Comprehensive Facilities • Database Independence

47. Java Database SupportSQLJ and Oracle8i • Oracle Database Server -- Oracle8i • Java virtual machine internal to the database • Oracle Extends Support for Standards Based SQLJ • Implemented SQLJ into Oracle8i • Supports Access to BLOB and CLOB Data • Supports SQL Object Types in SQLJ Programs through JPulisher tool • Java Stored Procedures and Triggers • Provides Access to Oracle Proprietary Language PL/SQL • Using SQLJ in Oracle8i EJB Server • Oracel Java IDE -- JDeveloper

48. Java Database Support SQLJ Example import java.sql.*; import sqlj.runtime.ref.DefaultContext; import oracle.sqlj.runtime.Oracle; public class JDBCInterop {#sql public static iterator Employees ( String ename, double sal ) ;public static void main(String[] args) throws SQLException { if (args.length != 1) { System.out.println("usage: JDBCInterop "); System.exit(1); } Oracle.connect(JDBCInterop.class, "connect.properties"); Connection conn = DefaultContext.getDefaultContext().getConnection();

49. Java Database Support SQLJ Example // create a JDBCStatement object to execute a dynamic query Statement stmt = conn.createStatement(); String query = "SELECT ename, sal FROM emp WHERE "; query += args[0]; // use the result set returned by executing the query to create // a new strongly-typed SQLJ iterator ResultSet rs = stmt.executeQuery(query); Employees emps; #sql emps = { CAST :rs }; while (emps.next()) { System.out.println(emps.ename() + " earns " + emps.sal()); } emps.close(); stmt.close(); } }

50. Java Database SupportODMG Java Binding • Impedance Mismatch • Object Data Management Group (ODMG) • Java Binding was Added to ODMG 2.0 • Applies to both ODBMS and RDBMS • Persistence by Reachability • Database Transparency • Automatically Mapping between Database and a Cache in the Application Memory • Java Objects are Mapped into the Cache When Application Navigates through them • Database Tracks Java Objects in the Cache and Write them back to Database at Transaction Commit Time