---

Agenda

• Background on this meeting
• Object Transfer and Manipulation (OTAM) Facility, Shel Sutton, MITRE
• Compositional Architectures, Craig Thompson, OBJS
• NIMA Reference Architecture, Shel Sutton, MITRE
• Joint Meeting of Internet Platform SIG and Security Platform SIG
• Report of ORBOS and Common Facilities and Interactions with ORMSC

---

Participants

• Shel Sutton 3166 (co-chair)
• Craig Thompson 4761 (co-chair, minutes)
• Tim Turley D83
• Tom Heir 989
• Jeff Suttherland 25297
• David Chizmadia 25488
• Akika Tanaka 12933
• Pascal Bar 21307
• Brent Hammond D75
• John Chen 15736
• Francois Berleur 28980
• Gary Word D103
• Pranab Baruah 25243
• Larry Smith 24714
• Bill Janssen 8569
• Jim Rhyne D99
• John Plocher D70
• Gene Vayngrib D113
• Gregory Blank D114
• Harri Poyhonen D65
• Mike Lippinen 23807
• Rainer Kossmann 16758

Background on this meeting

• the first involves a facility (suite of services and facilities) for what is called below an Object Transfer and Manipulation (OTAM) Facility.  Alternatively, it could be known as an Information Access Facility or possibly an Object-File Facility though the latter term is too narrow since OTAM is intended to provide a uniform front end to a wide variety of data sources.
• the second effort involves developing architectural concepts on the topic of compositional architectures that are needed for OMG to better realize its goals of interoperability, mix-and-match, plug-and-play, and scalability.  With the newly expanded charter of the Object and Reference Model Subcommittee (ORMSC) to extend the OMA, this work naturally needs to be coordinated and that is being accomplished.

Object Transfer and Manipulation (OTAM) Facility, Shel Sutton, MITRE

There needs to be some additional motivation up front in the current paper draft and the following were suggested:

• If someone has not made it into an object, you cannot get a hold of it.
• How would you wrap all the data sources that exist to make them available in an OMG services environment - that is, how do you make it easy for OMG to access all file systems, databases, repositories, ... everywhere (Craig)

Issues:

• is OTAM a facility (collection of services) and are there some contained services that would be independently useful that OMG has not yet identified? Yes, the interface for Object FTP is an example, similarly some object interface to MIME. Generally,  there are several identifiable services within OTAM that OMG has or has not got so OTAM is a rich source of extending OMG with a better information access architecture.
• is this an externalization service for non IDL? A: it includes this potentially or a registration facility for non-OMG externalization types like MIME.  Wasn't this the Data Interchange Service's original motivation? A: this is broader in scope and includes the DIS scope.
• Does OTAM include load balancing? It could, it depends on how broad we make it. (this might be a problem if we cannot distinguish what it does and does not do)
• OTAM vs. FTP. OTAM is envisioned as a higher level facility that might sit in front of OFTP but also provide DBMS access.
• Does OTAM expose a query interface? Probably not, it is probably simpler than an OODB or JDBC-like facility
• How does OTAM differ from the Persistence Service (old or new) if it just exposes object interfaces to data sources?  Good question!  One thought is that OTAM as a facility exposes its internal architecture to allow hooking in new data sources via a registration, federation, or trader protocol.
• How does OTAM add value?  One thought is, by putting OTAM in front of a file system, you have a place to hang information on file type (.doc), relations among file types (via inheritance), operations on file types (print, ...), and you can hide whether files are local or distributed across the Internet.  Also, this is true for other data sources than files, including database data and stream data.

We need authors to fill in the document - some are assigned. Shel will broadcast the outline to the people who volunteered to fill in sections.

Thought:  the DARPA I*3 Architecture is providing an OTAM-like reference architecture and we should arrange for them to talk about their work at a future OMG meeting. (tech transfer opportunity).

Thought:  OTAM is probably a bad name.  It is a pretty narrow derivative from FTAM which did not make huge waves in industy.

Compositional Architectures, Craig Thompson

• Limitations of OMA - what it does not explain but does not preclude - the OMA architecture is more and less than various groups seem to think it is.  Thompson outlines some of the original motivations based on 1990 work.  For one thing, there is a mapping from a calling tree to an object bus with functions hanging off.  But the missing ingredient of what calls what functions is missing in the diagram.  So, where the IEEE definition of architecture is in terms of functions and relationships, the OMA does not really record relationships -- these must be recorded separately.  On the other hand, the OMA does not imply a narrow client-server architecture but in fact can be viewed as functions connected by some dispatch bus.  And it is possible to overload functions dynamically by routing them (dynamically rewiring them) which is done in practice via wrapping.  The OMA is actually object-model neutral, including IDL so any object model could play the role of the object model.  Due to encapsulation, the objects in the OMA expose an interface but not their implementation so there is no way for OMG-ers to talk about dependencies of how a higher-level function (like a facility) calls or depends on a lower level one.  So there is no explicit mix-an-match story.  Finally, it is not really specified how one functions invokes another, whether explicitly as in A calls B or implicitly as in B is executed as a side effect of calling A.  And we do not really say much about the binding time of one A invoking B.  The value of the OMA is that it does not preclude these various possibilities.  When you go on to CORBA, you see IDL bound together with a distribution specification but the OMA can even be interpreted so that the apparent distribution is of the ability to invoke any side-effect behavior, not just distribution.  Also, the OMA really takes no explicit stand on object granularity, though assuming IDL everywhere does cause some problems in creating a sort of requirement for inserting distribution boundaries into systems, and the fact that language mappings as defined are one way (IDL to X) favors greenfield design over legacy code wrapping.  All of the above possible interpretations need to be better or more explicitly discussed because better understanding enriches the OMG architecture and helps us understand how little the OMA pins us down and how useful the possiblities are.  Also, it helps us to understand that we might need to say a little more if we want to add various capabilities to OMA architectures, like componentware capabilities to allow customers to mix and match software or mobile code.  Maybe we do not need to revise it but we do need to explain the possiblities a little better.
• Areas where more work is needed
• fundamental concepts - There are a number of concepts that we need to understand better.  We need a richer vocabulary.  We might want to operationally define facility, service, component, and framework.  We need to define policy, containment model, binding time, boundary, and some other terms.
• dispatch mechanisms - we need to talk more about dispatch, binding time, before-and-after methods, understand  (security) intercepters and portable object adapters and how they relate, and understand how to specify how to order or insert or delete side-effects like security, replication, versioning, persistence, etc.  We need some guarantees that only responsible parties can install or disable various behaviors.
• composition/containment model - we need some sort of uses specification to relate implementations to interfaces so we can explicitly model dependencies and talk about how to wire up services.
• federation - if CORBA-CORBA interoperability is needed to allow CORBAs to talk, we also need service-service interoperability to allow like services to operate together as if they are one.
• -ilities - we need to list a bunch of ilities (scalability, evolvability, ... many more) and see how to build systems made from components that exhibit these properties.  If the parts have these properties and the composition preserves them, then ...
• packaging - if we have a containment model, we also need to augment some contained subsets with packaging information to wall off certain configurations.  We need this idea so we can package sets of functionality.  So for instance, we can compile a package and make it opaque, sell packages, own intellectual property and license packages, etc.  But we sometimes might want the ability to look inside the wrappings if we have the right permissions.
• interoperation - we need to define interoperation.  Right now, it is reasonably defined as "unplanned reuse" but other definitions are possible, as when we create two services or facilities that are the same modulo some capabilities and then we consider how to make them interoperate or federate.  Do ideas like projection and completion help to explain how nearly similar services or facilities can be made to fit round pegs into square holes.
• the economy of componentware - ok, now, given that we have 10000 components, can we hook them together and can we realistically assume people will start buying them or selling them?  (This is happening for ActiveX and will happen for Java Beans for similar reasons.)  But how do we get past the current state where CORBA vendors vend their ORBs with their services and no or few service vendors have begun to create saleable services that port across ORBs.  Further, as a consumer, do you want to buy a car or a collection of parts from lots of vendors that might work together?  Too many people from too many places are making heavy investments in OMG and componentware technology for the answer to be that we have generated another generation of monolithic systems that do not have some of the promised benefits of componentware.  So we need to make sure we can get there from here.  Warning:  it might require thinking.

• DARPA supported work on compositional architectures and component assembly
• MCC Object Infrastructure Project ideas
• Internet SIG's recent-past recommendations to OMG on OMA extensions needed for scaling and evolving OMA-built systems
• component architectures like Java Beans and ActiveX

NIMA Services Architecture, Shel Sutton

NIMA is the new DoD National Imagery and Mapping Agency that is the result of an organizational merger of DMA and some other US Federal mapping and imagery agencies.  Its budget is in the $B.  Ron Burns is Chief Architect for NIMA's next generation software architecture. Gary Burns (Booze Allen) and Shel Sutton (MITRE, an FFR&DC Federally Funded R&D Organization) support Ron. NIMA's vision is to lower its costs and produce better service via a shift in business plan from one where they gather and store much data and do most of the processing to deliver a suite of information products (maps, for instance) to diverse customers to one where suppliers do most of this work.  They eventually  want to purchase 80% of their data and software from COTS sources (commercial off-the-shelf) while still retaining the agility for quick reaction responses to an increasing variety of customers.  They believe a services architecture and component assembly holds the key, as well as a public process of engaging with industry in developing such an architecture.

The presentation covered NIMA's business motivation for standardized components. The architecture presented will be the basis for a multi-billion dollar shift. NIMA deals in level one data (in OGC terms), not raw data and sensor analysis but data minimally processed and geo-positioned. A goal is to empower end users to cut-and-paste the functionality they need based on visual development tools where most of the data and software components are commercially supplied.  The architecture is aligned with OMG's and also the Open GIS Consortium's (OGC), which is aligned with OMG via the OMG GIS SIG, which Shel chairs.

Geospatial Information Access and Catalog Services are going to be required on 20 July in future acquisitions. Shel mentioned that it is hard for MITRE or the government to push NIMA specs into OGC since they are not vendors and can't team with vendors or it shows favoritism.

NIMA hope to make this transition in 3-5 years. NIMA is still working on getting a workable transition strategy. The aim is to be component-based by 2003. So NIMA understands that the only way to deliver the next-generation for the reduced $ is to go the components route. Number of NIMA seats is potentially 1/2M minimum (includes division level in field and logistics). But can go down to individual soldier with head mounted displays. Currently there are 3M US forces. 1/6 to 2/3 might use this.

Aside:  Shel mentioned that IBM announced last week a Universal Virtual Machine (UVM) that supports Basic, Java, C++, Smalltalk - available late this fall.

Joint Meeting of Internet Platform SIG and Security Platform SIG

• firewalls RFP is needed now - Thompson argued that a first order partitioning of security domains in practice in the Internet today is the firewall which creates the DMZ that separates the inside of a corporate network (intranet) from the outside.  He mentioned the NIIIP Consortium's roadblock three years ago when they began a large scale effort to build virtual enterprise technology based on CORBA and found they could not use OMG technology to pass CORBA/IIOP across firewalls. They went on to invent some OMG-related firewall technology to remove the roadblock.  Some discussion followed on whether firewalls is the right partitioning technology -- its there now so it must be comprehended for OMG technology to scale today even if it gets replaced eventually.  Also we talked about layers of firewall technology to thwart breakins where there are several diverse kinds of technology to negotiate to make entry harder.  Thompson mentioned that John Sebes (TIS) is taking the Firewall RFP to vote in ORBOS on Tuesday (which passed!--none too soon).  At the same time, Thompson noted that firewalls are a pretty coarse solution.  The Internet is changing how business wants to do business.  Increasingly, many people in organizations do as much or more day to day collaborative business (requiring sharing) with those outside the company firewall as those within.  So for instance companies now want to give their customers views into their order entry process to track orders and similarly want to give suppliers views into some aspects of the supply chain.  Virtual Private Networks is one interesting direction but even finer-grained controls will be needed to allow more flexible partitioning, based on access control lists, roles, and other to-be-invented mechanisms like community of interest.  At any rate, the border of in-out is shifting and is likely to grow more gray but we need some firewall solutions now.
• generalized intercepters - Thompson mentioned that it is commonly claimed that "if you don't build security in from the start, you can't get it later on" but that there are a variety of kinds of behaviors that have this property (system management instrumentation, QoS, replication, distribution, versioning, ...). Some say security is special because you want it to have the property that it is non-bypassable and probably separately specified in a security kernal (separation of concerns).  But actually so do these other services need the non-bypassable integrity property.  For instance, it does no good to insert a versioning layer if users can bypass it.  The point is that security is not so special but is an important member of a more general class of modularly insertable behaviors.  Then Thompson pointed out that the OMG Security Spec has developed the notion of Interceptors to permit security to be inserted as an ORB wrapper and that that notion needs to be generalized to allow these other services to be inserted in the same way.  Also that interceptors appear related to the Portable Object Adapter (POA) architecture.  So we need to do some work to rationalize and generalize both maybe to create an X-Unaware Wrapper capability.  Some in Security SIG recognize this opportunity and there is some work ongoing in the direction of generalized interceptors.  Thompson recommends that the interceptor spec be removed fom security (where it is hidden) and moved more visibly into CORBA CORE.
• federation - Thompson pointed out that because the Internet is big, CORBAs will talk to CORBAs (federation of CORBAs) and services will need to talk to services (query to query, namespace to namespace, transaction to transaction, etc.) and that this applies to security as well.  That is, it is imperative to put effort on how to compose homogeneous (because it is the easier problem) and heterogeneous (because it is the normal problem in the large) security policy domains to guarantee end-to-end properties.  Luckily, the Security spec contains the notion of policy.  But there is more work to be done here.  While federation is a general pattern, we need more experience with it in contexts like security before we can understand its most general form so there is work to do in future Security SIG meetings on this topic.  The ability to add to or remove oneself from federates dynamically is needed.  There are several examples of federated architectures -- the High Level Architecture mandated by DoD Defense Modeling and Simulation (see OMG Simulation SIG) is one useful model. The E-commerce Services Negotiation RFP is probably relevant here.
• composition - Thompson mentioned that OMG does not really have the right language for talking about a higher level object being composed of  or dependent on lower level ones.  Some sort of containment model is needed.  In Security, this is relevant because security cannot just be pushed down into the infrastructure at or below the ORB layer but also may need to wrap individual services or facilities.  That is, it is not just end-to-end but also top-to-bottom integrated (wrapped) into systems.  Jishnu later pointed out that the Multiple Interfaces spec is probably relevant here.
• fundamental concepts - Thompson pointed out that the terms policy domain, policy objects, policy management (invented for the security spec) might need to be generalized, that several old fundamental terms (facility, component, framework) might need to be operationally defined, and that some new fundamental terms (boundary/perimiter, containment model, X-unaware wrapper, trusted passport, ...) might need to be invented at the OMA level to describe what's happening when we scale OMA architectures by federation.  There was some discussion on using the term confederation rather than federation to get across the idea that control is not centralized (as some think federation connotes) but often decentralized (as confederation by contrast) connotes.  Agreed.  This is a good job for the OMA Reference Model Working Group to take on but it will need help from groups like Security SIG.
• survivability - Finally, Thompson pointed out that in the very large, survivability of the component middleware infrastructure is a major security issue.  One approach is to assume a federated OMA environment with thousands of federated CORBA implementations and huge service multiplicity and look for vulnerabilities, what happens if parts of the network are knocked out and how to recover or wall off threats.  So imagine a services architecture where you cannot only add but also someone else can (malicously or for some good purpose) subtract or replace services and predict the threat models associated.  DARPA has a program working in this area.

Report of ORBOS and Common Facilities and Interactions with ORMSC

OMA Reference Model Working Group and OMRMSC.  Thompson participated in the OMA RM WG meeting and volunteered to bring them mini-green papers (on OMG architecture) on the topics related to composability to the Dublin meeting.  Both Kevin Tyson, chair of the OMA RM WG, and  Jishnu Mukerji <jis@fpk.hp.com>, chair of ormsc@omg.org, the parent committee of RMWG, agreed these would be potentially useful for discussion and Jishnu will reserve a 45 minute slot on the ORMSC agenda for discussions on compositional architectures at the Dublin OMG meeting.