Craig Thompson (OBJS) led the day's discussion. Shel Sutton (MITRE) recorded minutes at the meeting and Thompson revised the minutes.
http://www.objs.com/isig/home.htm is the OMG ISIG homepage. It is referenced from OMG's description of the Internet SIG. Documents on this homepage also appear in the OMG document log. The homepage includes the outstanding Internet Services RFI, with a due date of 14 October 1996. It also includes papers and workshop reports for the recent OMG-W3C Workshop on Distributed Objects and Mobile Code and the forthcoming OOPSLA Workshop on OO + Web Integration.
IETF IRTF IIA. Thompson received a phone call from Ron Daniels (Los Alamos) regarding an apparently new Internet Engineering Task Force (IETF) Internet Research Task Force (IRTF) called Internet Information Architecture (IIA). The group is interested in URN-CORBA naming and also somehow extending MIME to become a more complete type model for the Internet. They do not want to select any one type system.
W3C. No one has news on W3C activities. Larry Smith (IBM) volunteered to provide future liaison reports on W3C activities.
Thompson reminded attendees that responses to the outstanding Internet SIG RFI are due in just under a month. He requested responses from both CORBA and services vendors and also users of OMG technology. He reminded attendees that responses do not need to be books and can be as simple as letters or short position statements listing missing ingredients in the current OMA that would allow OMA to scale to the Internet or World Wide Web. He mentioned that so far we have received one RFI response but expect at least 4-5 and maybe more.
Thompson stated that this ISIG meeting is interim, and the next one in Nice will fall after 14 October and will consist of presentations by RFI respondents and analysis of responses.
Today's meeting consists of two parts, a series of five presentations relevant to the forthcoming RFI as well as a discussion over potential RFI topics.
Martin Chapman (mchapmann@iona.com, http://www.iona.com/) began his presentation (see viewgraphs at Internet/96-09-02 coming soon) by volunteering to help folks find the best pubs in Dublin at next year's OMG meeting there.
He pointed out that more will be happening on the client than currently due to Java, which allows more sophisticated distributed applications (including GUIs and sessions) than pre-Java web forms and CGI/add-ins. But Java alone is not enough. We still need underlying infrastructure at the server for multi-user applications, dynamic updates, etc. as well as services, systems management, and exception management.
The IIOP competition is: ActiveX, RMI, IETF (MBONE, Session Control, Sockets) but IIOP should be the lingua franca wire protocol of the Internet because it can interoperate with DCE, ActiveX, etc. Java applets can be IIOP enabled on the fly. A limitation due to client Java applets (not Java itself) is that communication from an applet must go back to the server that created it. So access to other servers has an indirection. This is a safety feature of the current applet architecture.
OrbixWeb v1.x is on 2000 sites, is interoperable with COM/ActiveX, provides full Orbix client (filters, smart proxies, Dynamic Interface Invocation), but no server capability, and is available now on the Orbix site.
OrbixWeb v2.x (beta in September) will have applet call-back capability which downloads parts of the ORB as necessary (e.g. DII if needed), keeping the footprint reasonable. It's the basis for the Java Server and Middle-tier. Full integration with other services to follow - OrbixNames, OrbixTalk.
OrbixWeb has been chosen by Hong Kong Telecom for interactive multimedia services since it satisfies their requirements: rapid time-to-market (mid 1997), standards-based service provision, adaptable, evolvable, robust communications with 7/24 operation and thousands of clients. OrbixWeb is used in the set top box and to download programming, not to transfer MPEG where native formats are used.
In the future, IIOP should be the primary protocol on the Internet. Vendors need to iron out differences.
Q from Steven McConnell: security? Response: Secure sockets, Firewalls
Discussion of the RFP for Java/IDL mapping. Sun .NE. Visigenics .NE. Orbix with first responses due in December 1996. But a standard mapping is needed ASAP!
Q from Craig: Is IIOP enough? Response: Yes.
Jeff, who has been at Visigenic for two weeks, spoke informally.
IIOP will become the primary way to communicate over the web; it may sit alongside HTTP or be incorporated in. It will be bundled into all web clients and servers via VisiBroker. What was PostModern's Blackwidow is now Visigenics' Visibroker client, licensed to Netscape and they bundle. The Java runtime ORB is part of the browser.
Visigenic' focus is Enterprise computing, smoothly extending intranets to the Internet. How to get through firewalls: wrap IIOP in HTTP, which can get through firewalls. Visigenic' Gatekeeper can talk HTTP and IIOP. Might be bundled and not a separate process. Piggybacks IIOP into firewalls. OMG security using SSL. See AB meeting this afternoon and OMG Document Security/96-08-02.
If you think the whole world is Java (homogeneous environment), then use RMI. Else use IIOP. Call by Value RFP is the way to do this. Issues remain with respect to web of objects and how much to move at once.
Idea: wrap net protocols today with IDL. Browsers contain separate similar protocol stacks for mail, news, other clients today. Much footprint would collapse if OO protocols were used instead. Wrap as octets though not typesafe.
Idea in discussion: Get IIOP a standard port number: Wouldn't such an address increase out-of-the-box interoperability? If standard port, then that limits one ORB per machine. Standard default port but can use other ports. Might legitimize IIOP for firewall administrators. If you tunnel IIOP through HTTP, then firewall people will nix IIOP/HTTP. This is not just a technical issue but as much a social issue. Certification authorities assuage fears due to a "trusted" vendor.
What does Netscape ONE client talk to w/o a server for next many months?
Sankar asserts that mobile agents will fundamentally change the OMA? He cites these issues:
Sankar believes CORBA as currently defined is fundamentally not scalable - it needs to become asynchronous and use richer distribution patterns than just brokering contained in today's ORBs or IIOP. He points out that brokering is not the design pattern for mobile code. What happens if you download Flyweight design pattern, that uses adapters to pass from producer to consumer. Download Iona proxies. This leads to application-specific adapters. Today's ORB is too specific, so people do all sorts of things above or below to provide a richer way to do this. Internet comm. line is slow so you must optimize. So we need richer Design pattern ORBs.
Henry described deficiencies of today's security systems and provided handouts on a large (preliminary) study done with a lot of MITRE and other inputs. He pointed out that the DoD realizes that most security issues are generic to industry as well as Government and DoD needs such schemes to be in widespread use, and then wants to be able to add-on GOTS (e.g., Government off the shelf) requirements. Henry advocates coming up with a single threat model for commercial and Government use. There will always be some GOTS requirements but threats for both are similar.
He requested inputs from OMG on the draft report (handout). He stated that today, in the DoD we have some working "system high" systems (enforces need to know) and very few, very expensive multi-level systems, expensive because they require assurance on the development side. But in the next generation, we need more modular security that supports multiple communicating domains with generic security available at several levels in protocol stacks. At a course grain, this includes wrapping whole collection of items with one label like "imaging". At a finer grain level there might be multiple CORBAs talking to each other using access privileges. He indicated that scalability requires that we must communicate policy across domain boundaries. Also we need to be able to change security policies in running systems. We don't know how many such systems we are talking to at any given time. Each domain is mutually suspicious but we must communicate until we are done. This is a big step beyond today's firewalls. It requires an inter-domain import/export policy; a label-based scheme appears doable but depends on additional management that we don't do today. It is also a step away from C1, B2, etc. levels of security aiming at a richer scheme for insuring safeguards in federated systems with mixed security levels.
Q from Craig: This is very different from firewall technology - much more robust (and complex). How will the transition take place. Have firewall vendors been contacted? Response from Pat Mallet: as industry sees the similarities, migration should happen. Response from Neil Wagoner: First step is to develop a combined threat model. Second step is to determine what can be done in the CORBA environment and what cannot.
Q from Craig: What about Virtual Private Networks? How do they relate? Response: VPNs only address some security levels - Virtual Private Networks are lower level and do not transfer information across boundaries.
Cory described Data Access' response to the Internet Services RFI (handout).
Distributed computing solutions today are highly proprietary, brittle and expensive to change. Starting now, we can use Internet to deploy business application (business objects) anywhere in the world. This gives us a massive marketing domain. The architecture looks like web clients and servers talking to backend business objects, uses generic client and web server software. There are requirements for loosely coupling business functions and business GUI interfaces. How the business objects talk to the browser client is currently a battle between RMI, ActiveX, and IDL. Some specific needs are richer metadata, richer transactions, sessions, more useful relationships (than in the OMG relationship service), business rules, and internationalization.
The rest of the day was spent continuing a discussion started in Madrid on potential areas that Internet Services RFI responses might cover. The general topic was, where does OMG go next relative to the Internet? What should an expanded ideal OMA provide that today's OMA does not.
We added to the Madrid list the following laundry list of items (some are redundant):