Given by Geoffrey C. Fox at Gateway Workshop Aberdeen Maryland on 24-25 May 99. Foils prepared May 26 99
Outside Index
Summary of Material
We make some general remarks on construction of object web distributed computing systems stressing the role of XML and multiple object models |
We give some simple examples of XML definitions for machines and programs |
We describe relationship to Enterprise Information Portals |
We describe collaboration -- both synchronous and asynchronous -- in terms of event propagation |
We go through a NPAC research program -- Shared Places -- illustrating role of XML and shared web objects |
Outside Index Summary of Material
NPAC |
111 College Place |
Syracuse NY 13244 4100 |
Phone: 3154432163 |
May 24 1999 |
Aberdeen Md. |
Geoffrey Fox |
Syracuse University |
We make some general remarks on construction of object web distributed computing systems stressing the role of XML and multiple object models |
We give some simple examples of XML definitions for machines and programs |
We describe relationship to Enterprise Information Portals |
We describe collaboration -- both synchronous and asynchronous -- in terms of event propagation |
We go through a NPAC research program -- Shared Places -- illustrating role of XML and shared web objects |
A server accepts input and produces output
|
IIOP and HTTP are two common protocols (formats of control data) for inter program messages |
A Web browser (Netscape or Microsoft) can access any server at "the click of a button" with data from user refining action |
Basic Vision: The current incoherent but highly creative Web will merge with distributed object technology in a multi-tier client-server-service architecture with Java based combined Web-ORB's |
Need to abstract entities (Web Pages, database entries, simulations) and services as objects with methods(interfaces)
|
COM(Microsoft) and CORBA(world) are competing cross platform and language object technologies
|
Javabeans plus RMI and JINI is 100% pure Java distributed object technology |
W3C says you should use XML which provides a uniform way of serializing any object into an ASCII file |
W3C also defines an object model for all documents and essentially EVERY object is rendered to user with this W3C DOM |
How do we do this while technology is still changing rapidly! |
Similar to invoking a web page |
Java CORBA or WIDL (pure XML CGI specification) |
Object Broker |
Fortran Simulation Code on Sequential or |
Parallel Machine |
Convert Generic Run Request into Specific Request on Chosen Computer |
Fortran Program |
is an Important |
Type of Object |
It can be built up from |
smaller objects |
e.g. Matrix |
library could be an |
object |
W3C Web Page |
(XML/XHTML) Rendering of Backend Object |
Need to use mix of approaches -- choosing what is good and what will last |
For example develop Web-based databases with Java objects using standard JDBC (Java Database Connectivity) interfaces
|
Use XML to record small databases in flat files |
Use CORBA to wrap existing applications |
Use COM to access components of major PC applications such as Microsoft Excel and Word |
Use Jini and Java to implement dynamic registration of objects |
Use HTML to render everything |
Objects (at "logical backend") can be on client of course |
Front end can define a generic (proxy for a) object. The middle control tier brokers a particular instantiation |
Broker or Server |
XML |
Result |
XML Query |
Rendering Engine |
Browser |
Rendering Engine |
HTML |
Universal Interfaces |
IDL or Templates |
XML Request for service |
followed by return of XML result |
The Proxies and actual instantiation are linked by messages whose semantic content is defined (best) in XML |
The lower system level format can be HTTP RMI IIOP or ... |
The client proxy is for rendering input and output including specification of object |
The middle tier proxy allows choice of backend provider and functional integration (the user can specify integration at client proxy level) |
Real Capability |
XML |
XML |
Between XML/HTML document and backend Fortran, MPP, Database, Scientific Instrument defined by XML Resource definition is a bunch of servers linked by XML Messages |
Servers can either be commercial Web Servers (Apache with servlets), CORBA brokers or custom Servers and can if necessary support multiple object models simultaneously (JWORB) |
Java/CORBA/WIDL Wrapper with IDL in XML |
XSL Style Sheets and |
XML/HTML Page Design |
Need version 5 browsers with good XML support to properly implement front end |
We draw three tier as minimum architecture but as previous diagram suggests, one is likely to build a more structured system with middle tier having more layers |
Network computer breaks client tier into two with simple HTML at user and Java servlets providing heavier weight capability on a different machine
|
The front end is some document consisting of a mix of HTML or XML
|
We supply suitable XML widgets which PSE designer puts together in different ways for different PSE's |
We can copy a much reviled model -- Microsoft Word or PowerPoint -- Problem Solving Environments for document preparation -- to get PSE for Computing |
XML Widgets are organized into Toolbars .... |
Computing abstracted as a set of hierarchical Toolbars Toolbars are defined in XML and rendered in HTML for user interface. XML interpreted on middle tier as some suitable service. |
Computing Toolbars include user profile, results, visualization (where "command" could be AVS), collaboration, programming model, HPF, Dataflow, resource specification, resource status, code (application specific) |
The backend software can be parallel or sequential and simulation or information based
|
We need to define in XML its interface needed to
|
This backend program interface is defined as an XML file e.g. <program name="physicssimulation1"> <run domain="npac" machine="maryland" type="pc" os="nt" >c:\myprogs\a.out</run> <input type="htmlform" > <name>userinput</name> <field default="10" >iterations</field> .......... </input> <output> ...</output> </program> |
Becomes HTML form with name |
userinput and text field iterations |
with default value 10 on client |
For this example (running a physics program), we could use a specific machine as defined on previous foil (the Windows NT PC maryland) or a generic machine <run domain="any" machine="any" type="pc" os="nt" > |
In this case, middle tier broker, would look in a database (XML file) to find what machines were available and either automatically or with user input choose one. |
Both Software and Hardware are defined in XML |
Note databases and an XML files are logically equivalent |
JDBC can access either Oracle (Microsoft) database or XML ASCII file |
More generally XML can be thought of as general object serialization
|
The XML File <machines domain="npac" type="pc" > <machine os="nt" cpu="pentium2" memory="128" >maryland</machine> <machine os="nt" cpu="pentium3" memory="256" >georgia</machine> <machine os="95" cpu="mmx" memory="128" >foxport1</machine> ..... </machines> <machines domain="cis" > <machine os="solaris" cpu="sparcXX" >top</machine> ..... </machines> |
is equivalent to database tables such as |
If Gateway is a Portal to Computing and Intranet is a Portal to Enterprise Information, then how how are they linked |
They share features in the "Information Toolbar"
|
Area 1998 2002 CAGR |
Content Management $1.2B $4.7B 40% |
Business Intelligence $2B $7.3B 38% |
Data Warehouse/Marts $.99B $2.6B 27% |
Data Management $0.18B $0.36B 18% |
Totals $4.4B $14.9B 36% |
We noted that Gateway should support input and output files with certain characteristics including |
Native: internal format known to a particular application -- no checking of format matching if link output of one module to input of another |
parameterinput: special file constructed in XML defining basic parameters needed by a batch job
|
Third file format is
|
Gateway modules need to specify nature of their input and output files and what type of linkage of modules is allowed or even required.
|
This we define as a group of defined formats that support scientific data, note taking and sketches |
XSIL (Scientific data Interchange) defines metadata needed to specify scientific data files including high level parameters and methods needed to read data
|
VML is Vector Graphics Mark up Language |
DrawML is designed to support simple technical drawings (easier than VML but VML should be able to do this?) |
VRML (3D scenes) reimplemented in XML as X3D |
MathML Mathematical Expressions |
ChemML Support Chemistry |
Presumably this allows Scientists to make notes and record thoughts in a way that it supports important scientific constructs |
At its simplest this is an authoring tool like Microsoft Word, PowerPoint or Framemaker
|
One useful utility would be a whiteboard that supported scientific notes using ScienceML |
Such a collaborative whiteboard (implemented in Tango for instance) would be useful in research and teaching
|
Collaboration implies sharing of electronic objects and is needed in asynchronous and synchronous modes |
Asynchronous mode is
|
Notification and linkage service
|
Notification mechanism enhances collaboration as enables dynamic federation of relevant objects to be automatically maintained
|
Notification can be used for people so their presence on-line can be made known to those in particular collaborative users |
Users decide if notification causes an active signal (send electronic mail, ring a buzzer) or passively alters a list on a web page. |
Event Model unifies synchronous and asynchronous models of collaboration
|
Shared Objects need to accept data from Gateway compliant applications
|
Gateway Events need to be integrated into SPDL |
Gateway federates different "event domains" |
Local Event/Message Bus |
Collaboration == Sharing Event |
in "Tango" Server |
Local Event/Message Bus |
Local Event/Message Bus |
Gateway Events |
Whiteboard and Shared Browser can be loaded with files and data from Gateway compliant systems |
More generally consider any client side rendering of a gateway system -- either data input or (visualization/data) output
|
Examples from Tango
|
In this example we define a simple shared place where the results of some scientific computations are available. |
The place can be used also for discussion among collaborating scientists. The discussion is supported by two shared objects: chat and data viewer. |
The chat can be used for the text based discussion about presented results. |
The data viewer can be used for the graphical presentation of the results. The authors of the results (`creators') have access to the advanced functionality of the data viewer. (e.g. support of ScienceML) They can use this functionality to present their findings visually to the `observers'. |
The shared place is defined by two documents. The presentation layer is described by the HTML document and the collaboration functionality is defined by the SPDL XML/XSL document. |
The SPDL document defines several collaboration aspects of the shared place. |
The header defines the communication protocol used for contact with collaboration server. (could be CORBA or what have you) |
Next, all the shared objects embedded in the shared place are enumerated. |
The following fragments define the user groups that have access to the shared place, specific user roles, and types of the collaborative sessions that are established in the shared place. |
Other fragments describe how the data visible by different users are synchronized and specify the sources of the content presented by the shared objects. |
Note how some Shared Place properties (e.g. users and files) are needed outside collaboration and others support both synchronous and asynchronous collaboration |
<?xml version="1.0"?> |
<placedef> |
<head> |
<title>Result Presentation</title> |
<protocol type="plain"> |
<server>kopernik.npac.syr.edu</server> |
<port</port> |
</protocol> |
</head> |
The Header contains the title of the place. |
It also declares how the shared place communicates with the collaboration framework. (I.e. server in Tango language) |
The plain client/server protocol is chosen here with the collaboration server running on the machine: kopernik.npac.syr.edu on the port: 5555. |
Other protocols such as IIOP can be used as well. |
Initialize shared place definition |
<sharedobject name="viewer"/> |
<sharedobject name="chat"/> |
This fragment describes shared objects that are used in the shared place.
|
<groups> |
<group name="syracuse"> |
<user>morgan</user> |
<user>cheng</user> |
</group> |
<group name="boston"> |
<user>smith</user> |
<user>johnson</user> |
</group> |
<group name="washington"> |
<user>anderson</user> |
<user>brown</user> |
</group> |
</groups> |
This fragment of the SPDL document defines user groups. Those groups are used in further sections of the SPDL document to define other properties of the shared place. Three user groups, each with two users, are defined: syracuse, boston and washington. |
<users> |
<place> |
<usergroup>syracuse</usergroup> |
<usergroup>boston</usergroup> |
<usergroup>washington</usergroup> |
</place> |
<users> |
This fragment declares that only members of the groups: syracuse, boston, and washington can access the shared place. |
The declaration uses the `place' tag, therefore the access restriction applies to the whole place (chat and viewer objects). However, it is possible to define separate settings for the specific objects. |
<roles> |
<object name="viewer">
|
</object> |
</roles> |
The fragment of the SPDL document on previous page defines two roles: creator and observer. |
We suppose that the data were produced by scientists from Syracuse therefore the role of the creator is assigned to them. Two other groups have the observer roles. |
The shared object `viewer' behaves in different way depending on the role of the user. The user that has the role of the creator (must belong to `syracuse' group) obtains access to the viewer interface with more functionality. This extended functionality enables presenting the gathered material to the observers. |
On the other hand, observers obtain access to the simpler interface suitable only for viewing the content presented by the creators. |
The shared object `chat' does not have this distinction. All users (that belong to the previously declared groups) can access it in the same way without any limitations. |
<sessions> |
<place> |
<entermode>automatic</entermode> <usergroup>syracuse</usergroup> |
<usergroup>boston</usergroup> |
<usergroup>washington</usergroup> |
</place> |
</sessions> |
This fragment defines how the collaboration sessions are created in the shared place. |
The members of all three groups automatically enter the collaboration session when they access the result analysis page. |
This means that when a user opens the page with the shared place defined by this document, she immediately starts the collaboration with other users without executing any special actions. |
<synchronization> |
<place> |
<mode>instant</mode> |
<usergroup>syracuse</usergroup> |
<usergroup>boston</usergroup> |
<usergroup>washington</usergroup> |
</place> |
</synchronization> |
This fragment of the SPDL document specifies that whenever one of the users will change the state of its shared object, this change will be immediately propagated to the shared objects of the other users. |
Such a mode is declared for all shared objects present in the shared place. |
<content> |
<object name="viewer"> |
<mode>read</mode> |
<location>http://www.npac.syr.edu/experiments/results/ |
</location> |
</object> |
</content> |
</placedef> |
This fragment of the SPDL document states that the shared object that implements the result viewer have access to the data from the location: http://www.npac.syr.edu/experiments/results/ in "read-only" mode. |
This place should be used for storing the data that can be displayed by the viewer. |
<HTML> |
<head><title>Page with the computation results</title></head> |
<body> |
<xml id="placeDocument" src="results.xml"></xml> |
<xml id="chatDef"> |
<embedobject name="chat"> |
<location>http://www.npac.syr.edu/experiments/apps/chat.jar |
</location ></embedobject></xml> |
<xml id="viewerDef"> |
<embedobject name="viewer"> |
<location>http://www.npac.syr.edu/experiments/apps/viewer.jar |
</location ></embedobject></xml> |
<xml id="style" src="spdl.xsl"></xml> |
SPDL Definitions Page |
Style Sheet |
Shared Objects |
Interpret 3 XML islands in style sheet and instantiate them in three (other) regions of document. ( Previously we loaded XML islands but they were not instantiated by browser) |
<SCRIPT FOR="window" EVENT="onload"> |
docTarget.innerHTML = |
placeDocument.transformNode(style.XMLDocument); |
chatTarget.innerHTML = |
chatDef.transformNode(style.XMLDocument); |
viewerTarget.innerHTML = |
viewerDef.transformNode(style.XMLDocument); |
</SCRIPT> |
<div id="docTarget"></div> |
<p>This page contains the results of our latest computations. |
The most interesting fragments are presented below. |
<p>results here ..... ANY OLD HTML |
<p>The authors of those computations will come here to discuss latest results on Monday at 3:00pm. |
Please join them in the discussion: |
<p>Visualization of some results presented by the authors is |
available here: |
<div id="viewerTarget"></div> |
<p>Talk with others about the results here: ANY OLD HTML |
<div id="chatTarget"></div> </body></HTML> |
The display of two shared objects |
Control Display |