OMG Internet SIG -- Minutes of Meeting #16 (original) (raw)
OMG Internet Platform Special Interest Group
February 9, 1998
Salt Lake City, Utah
OMG document internet/98-02-01
OMG Internet Platform SIG homepage: http://www.objs.com/isig/home.htm
Agenda
- OMG-DARPA Workshop on Compositional Software Architectures, Craig Thompson, OBJS
- Brainstorming on OMG-Java Relationship Craig Thompson, OBJS
- Brainstorming on Web-ORB Integration Architectures and Data Models Craig Thompson, OBJS
- Working Session on OTAM Facility, Mike Bigrigg, CMU
- Collaboration Working Group, Henry Rothkopf, MITRE
Participants
- Craig Thompson - Object Services and Consulting, Inc - thompson@objs.com
- Henry Rothkopf - MITRE/Open Systems Center - henryr@mitre.org
- Andrew Eisenberg - 16474
- Jeff Sutherland - IDX Systems - jeff.sutherland@idx.com
- Mike Bigrigg - Carnegie Mellon University - bigrigg@cs.cmu.edu
- Jonathan Legh-Smith - 944
- Brian Breton - 31874
- Nick Brachet - 42687
- Pranab Baruah - 25243
- Tim Frommeyer - AT&T - frommeyer@att.com
- Dan Klawitter - 25970
- Roger Burkhart - 1530
- Bapa Rao - Trusted Information Systems - brao@tis.com
- Rudolf M. Riess - Digital Equipment - rudolf.riess@digital.com
- David Gamble - Micro Focus - davg@microfocus.co.uk
- Krystian Wirski - Department of National Defence - ab130@issc.debbs.ndhq.dnd.ca
- Dave Chizmadia -25488
- Roger Finger - Intel - roger_finger@mail.intel.com
- Debbie Jenkins - Cognitive Communications - debbiejk@aol.com
- Terry Ellis - Fretwell-Downing Data Systems - tellis@fdgroup.co.uk
- Ravi Condamoor - Oracle - rcondamo@us.oracle.com
- Sailesh Chutani - Oracle - schutani@us.oracle.com
- David S. Dobrotka - Air Intelligence Agency - dobrotka@sprynet.com
- Silas Larry Smith - IBM - larrysmith@ibm.net
- David C. Smith - Deere & Company - ds60162@deere.com
- Elizabeth Ungar - Boeing - liz.ungar@boeing.com
- Michael Chonoles - Lockheed Martin Advanced Concepts - michael.j.chonoles@lmco.com
- Jan R. Schultz - IDX Systems - jan_schultz@idx.com
- Gene Jarboe - 10590
- James Stegeman - 43533
- Russ Clans - 43654
- Martin Chapman - IONA - mchapman@iona.com
- Narizumi Shindo - 43674
- Simon Nash - T17
- Jim Trezzo - T112
- Leo Uzxategui - 25607
- William Janssen, Jr. - Xerox - janssen@parc.xerox.com
- Frank Olken - Lawrence Berkeley Lab
- Lorraine Cash - Raytheon - waldbuss@ed.ray.com
- Milo Chan - J.P. Morgan - chan_milo@jpmorgan.com
- Junji Fukuzawa - Hitachi - j-fukuza@sdl.hitachi.co.jp
- David Harkcom - Trusted Information Systems - dharkcom@tis.com
- Olaf Kaestner - Siemens Nixdorf Informationssysteme - olaf@sni-svy.com
- John Robinson,Department of National Defense - john@mars.dgrc.doc.ca
- Ron Zahavi - Concept 5 Technologies - rzahavi@concept5.com
- Jan Peter van der Bijl - KPN Research - j.p.vanderbijl@research.kpn.com
OMG-DARPA Workshop on Compositional Software Architectures, Craig Thompson, OBJS
The OMG-DARPA Workshop on Compositional Software Architectures was held in Monterey, California, on 6-8 January, 1998. The homepage for the workshop is http://www.objs.com/workshops/ws9801/index.html. The list of 100+ participants, 90+ workshop position papers, and the workshop report are available from the workshop homepage. The workshop focused on
- component models,
- inserting ilities (non-functional properties like scalability, security, survivability, evolution, and adaptation) into componentware, and
- web-ORB integration architectures and web object models. Thompson presented a summary of the workshop (.ppt). He mentioned that many of the ideas in the workshop have been forwarded to the ORMSC.
Brainstorming on OMG Relationship to Java
We continued a discussion started at the OMG Internet SIG meeting in East Brunswick (see past discussion) on whether and how to make OMG more Java-friendly. Our motivations were that OMG and Java will increasingly overlap in turf as Java is used for enterprise, middleware, server, and distributed applications, and that it seems in both groups' interests, and definitely in the interests of customers if the two camps tend toward convergence and not divergence.
Near the beginning of the discussion, we also noted that there may be a need to make OMG more web/XML friendly but then limited discussion to Java friendliness. From the last meeting's discussion, we listed these thoughts:
- wholesale replacement of IDL with Java - nobody is suggesting this, are they? IDL's purpose in life is to be language-neutral to permit interoperability so we still need it
- encourage OMG specs to contain appendices that contain a Java mapping. Martin Chapman argued that this is unnecessary since many tools with Java-IDL and IDL-Java mappings will exist that allow mapping of all existing OMG specs to Java and that everyone should use the automatic mapping, which is designed as much as possible to be Java programmer friendly. [Does everyone feel this is the case?]
- have OMG involved in some way in the Sun Java PAS, but this would require JavaSoft as well as OMG to agree. Someone noted that, while OMG and JavaSoft are both PAS submitters, the JavaSoft status is limited in some ways, to the language but not all the way to any class libraries. [Anyone know the actual status?] Many felt that a good thing to do would be to sponsor some sort of workshop or summit that gathered together OMG and JavaSoft technical management to share tentative plans to try to see how they might be converged. The output would be paired roadmaps that attempted to align the two communities. Going in assumptions would involve the realization that both communities have different processes, scopes, timelines; both have technology strengths and gaps; both have similar business motivations and should both be interested in what customers want. Bifurcating the community with incompatible choices seems not to be in the best interests of the OMG or JavaSoft communities though it might benefit the DCOM community. Some pointed out OMG is lite on semantics, a programming model, a binary standard, garbage collection, versioning; others that Java enterprise solutions won't meet customer needs; there are areas of common interest like messaging; controversial areas like RMI; and areas where both camps need work like federation of components and services. Some very tentative names were listed as possibly helpful in a summit: Richard Soley, Andrew Watson, Dave Curtis, Jon Siegel (all OMG technical management); Pranab Baruah (Boeing) representing customers, maybe also DARPA; Jim Trezzo (Oracle), Simon Nash (IBM) (or Leo Uzcategui (IBM) and Ian Brackenberg (IBM)), and Andrew Eisenberg (Sybase) with some idea of how the roadmaps might fit; Jim Mitchell (JavaSoft), Rick Cattell (JavaSoft), other technical management TBD. The action item is for Craig to make initial inquiries of OMG staff to see what they think there might be willingness for a joint meeting (workshop or summit), then to approach others. Timeframe: nothing visible will have happened by OMG Manchester, maybe something will be brewing by Orlando. It is likely any meeting would not happen on any one's turf, e.g., not at an OMG meeting.
Brainstorming on Web-ORB Integration Architectures and Data Models
Thompson started the brainstorming by asking if there is an ideal integration of ORB technology and Web technology so we can "have our cake and eat it too" and avoid having both communities re-invent each other's wheels as the Web increasingly adds enterprise middleware services to its list of architectural standards. He then broke the general problem into two subproblems:
- Web-ORB integration architectures - these are interesting because they should provide us routes for combining CORBA and HTTP
- Web object models - these are interesting because much of the world's data will soon be in either a web format like XML or to a lesser extent in an object format so can the two interoperate seamlessly? We listed Web-ORB integration architectures.
- ORBs in the back-end -- web client accesses web server, CGI is then used to access ORB client that accesses ORB server.
- ORBs in the client -- download Java ORB client into Web client, then let ORB client access ORB servers. Visigenics approach.
- intermediary architecture -- insert ORB services between Web client and Web server via graph of active web proxies and/or an ORB that can access ORB services.
- replace HTTP server with HTTP* server that accepts HTTP and also ORB type models. W3C HTTP-NG approach. Bill Janssen drew a diagram of how HTTP-NG is structured (where TCWA = The Classic Web Application)
Browser
DOM/XML, HTML, PS, �
TCWA
HTTP*
|
HTTP*
TCWA
DOM
Server
Bill mentioned that a feasibility study will be complete in June and that W3C members can critique the work in progress.
- use of DOM which is an API and a type system, just different than most OO-ers are used to Variations including ORB client built into Web client. And downloading an application via IIOP instead of HTTP. Someone mentioned Microsoft has associated dynamic events with DOM objects.
We discussed some places where web and ORB architectures overlap beyond the basic architecture and object model listed above. One of these was RDF versus MOF, which uses UML. In addition, Bill Janssen mentioned some projects he'd like to see someone in Internet SIG take on:
- IETF character sets
- IPv6 security vs. OMG Security
- ONC RPF profile for CORBA (did I get this right?) If someone is interested, we'd welcome a presentation on your thoughts on any of these.
Work Session on OTAM, Mike Bigrigg, CMU
OTAM is a proposed information access facility (composed of services) based loosely on ISO FTAM. It consists of a virtual file system that provides an interface to a collection of physical file stores and database records. A Trader stores the file and database schemas plus potentially more (e.g., data conversions). This is an attempt to objectify file systems so CORBA can operate on them. FTAM can be viewed as a file system adapter.
Mike Bigrigg (CMU) led this discussion. He said the initial goal is an OTAM White Paper (initial draft by Shel Sutton at the East Brunswick meeting) followed by an OTAM RFP.
As envisioned, OTAM sits in front of plug-in file systems Unix, NFS, AFS, Win NT, others. It provides a standard interface across all these.
Internally, OTAM seems like it would depend on a number of CORBAservices and capabilities:
- persistence
- security
- naming
- trader
- compound document
- agents
- objects by value
- serialization
- collections
- queries
- URL - IOR mapping
- caching (which we do not have yet)
- replication (which we do not have yet)
- versioning (which we do not have yet) There are more issues than answers about OTAM at this time. We need a careful analysis and an OTAM architecture. Open issues are:
- how far down the path should OTAM go in presenting a standard file system interface if some file systems do more than others. Should file system differences be mirrored in OTAM? Should OTAM "hug" file systems and provide exactly and only their capabilities (via an OO API) or should it provide additional capability?
- since OTAM is oo-based, does it know about different file types, including various data interchange formats? If it does, can it add behavior (methods) to file types? can it access objects within files or just the files?
- should OTAM allow mounting FTP, relational DBMS, and OODBMS under its hood? If some of these systems have extra capabilities, will they shine through the OTAM API?
- which of the above listed services does the OTAM Facility depend on? This question is interesting because one can envision an OTAM service with or without trading, with or without collections and queries, and so this is a really interesting test of what we at OMG mean by a facility and how similar facilities with different capabilities might interoperate.
Collaboration Working Group, Henry Rothkopf, MITRE
Henry Rothkoph (MITRE) is interested in building support for an Internet SIG Working Group on Collaboration. He is generally interested in a variety of application domains like healthcare and C4I where people perform a variety of tasks accessing a variety of data sources, with changes over time to both the task mix and data sources needed. We discussed the need for
- flexible binding glue to connect together services,
- models or configurations of services that a user might have in her profile and might send to other users so they might share parts of a configuration,
- primitives for auto-downloading services as needed,
- controls over data dissemination,
- dynamic security policies, and
- integration of the whole using OMG componentry as a challenge problem. We also talked about subsetting the problem so one only looked at the subarchitecture for accessing multiple data sources (see OTAM discussion above). We looked for examples of people doing this kind of work-one noted was the NIIIP Consortium's puzzle of configuring virtual enterprising them, then provisioning roles. We ended up talking about the MITRE Collaborative Virtual Workspace (CVW) tool, which will be demoed on Wednesday.
Next steps are to continue to build interest in a Collaboration Working Group at OMG Manchester then to invite several speakers to OMG Orlando to talk about aspects of collaborative workspaces. Action item: Henry to invite to Orlando 4-6 speakers at 20-30 minutes each, plus a one hour discussion, 2-3 hours in all.