OMG Internet Platform Special Interest Group
Minutes of Meeting #12
23 June 1997
OMG Document internet/97-06-01
Shel Sutton 3166 (co-chair)
Craig Thompson 4761 (co-chair,
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
At previous meetings of the Internet SIG, we issued an RFI
for Internet Services which resulted in a collection of recommendations
made to ORBOS and Common Facilities Task Forces for new RFPs that would
help connect OMG technology to the Internet and World Wide Web. Work
on several of those recommendations is now on going in the task forces
and has resulted in their issuing several RFPs. We held back two
areas of work within the Internet SIG that appear significant but that
need some better understanding to mature the idea bases before taking these
This meeting report covers progress on OTAM, compositional architectures,
a report on the US DoD NIMA Services Architecture, and discussion at a
joint meeting of the Security and Internet Platform SIGs, as well as the
status of coordination work with ORMSC.
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
Shel presented a first draft (skeleton) of the OTAM Facility White Paper.
Discussion was on what the idea behind OTAM is and how it is different
from Compound Documents, Object-based File Systems, Persistence, …. OTAM
is partly motivated by an earlier specification called FTAM for File Transfer
There needs to be some additional motivation up front in the current
paper draft and the following were suggested:
There was some confusion over whether OTAM is a service or facility.
From the discussion, OTAM is a facility in that it seems to
cover or make use of Persistence, Trader, Externalization, Registration,
Publish and Subscribe, Data Interchange, possibly others. We need
to nail OTAM's architecture down further.
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
We need a section on prior art and related work.
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
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 presented on "Compositional Architectures" (no foils) covered
the following topics. These are only sketched here but longer mini-green
papers on some of these topics should be available by the next OMG meeting
in Dublin and some of this work will be presented again at the ORMSC meeting
in Dublin (see below).
The presentation covered ideas from
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
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
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
At the last OMG meeting in Stressa, two members of the Security Platform
SIG recommended a joint meeting of the Security and Internet PSIGs.
Unfortunately, there was no agenda set up. So Craig
Thompson (co-chair of Internet SIG) started the discussion rolling
by relating that Internet SIG had issued an RFI, analyzed responses and
found the following overlaps relevant to security. A basic theme
of the discussion was that the Internet world is large and heterogeneous
and the OMG world is just now moving from a LAN-centered mindset (40 workstations
on a LAN) to a global WAN mindset (millions of users on gatewayed ORBs)
as Netscape/Visigenics, Javasoft, and others makes IIOP/CORBA/Java Beans
available pervasively. That means we have to think bigger (massively
more scalably) than before sooner (than we are ready to, give the
immaturity of ORB services implementations). Here are some areas
involving security where we have to do some serious work soon:
While there was some discussion on each topic, the main idea was to get
these areas of intersection between Internet SIG and Security SIG out onto
the table so they could find their way onto the appropriate roadmaps, for
instance to help move CORBAsec to the next level. Thompson promised
to write some mini-green papers on several of these topics for the Dublin
OMG meeting hopefully giving others a document around which a set of relevant
ideas can aggregate. Thompson believes this thread of ideas on Scaling
the OMA needs to get rolled in to discussions with the OMA Reference Model
Working Group, which is working on OMA-NG (our name for that effort --
to provide OMG direction for the next five years) and has arranged to begin
that interaction. The Internet SIG and Security SIG decided to meet
together again at Dublin (2 hour slot). Bill
Herndon (firstname.lastname@example.org) asked that notes on the joint meeting
be forwarded to him. The above notes are also being forwarded to
DARPA (Sami Saydjari), which is working on a Security Reference Architecture,
to encourage a technical interchange and coordination meeting with DARPA
on these subjects at a future OMG meeting.
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
Joint meeting of ORBOS Task Force, Common Facilities Task Force, and
Internet PSIG. As co-chairs, Thompson and Sutton gave short briefs
to the joint meeting of ORBOS and Common Faciliites on Tuesday morning
to keep them in the loop on Internet SIG work. Common Facilities
is organizationally recharted to include not only its old work but also
new work on services or facilities that result from Internet-Web related
topics. So the Firewalls RFP, which was also presented at this joint
meeting was voted on and passed and assigned to Common Facilities, which
will manage it RFP process though both groups will review its results.
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 <email@example.com>, chair of firstname.lastname@example.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.