Re: How Infospheres differs from Java Beans, Active X, Netscape ONE,

Joe Kiniry (
Fri, 20 Sep 96 12:35:43 -0800

You wrote:
> In an earlier post to FoRK, I was wondering out lout how our
> research in Infospheres (<
> differed significantly from Java Beans, Active X, and Netscape ONE,
> if our component object models were so similar. I think I
> understand our differences to be in 2 areas:

now that i have actually read the java-beans specification,
recently available from sun, i can now comment on this topic
(infospheres vs. java beans vs. netscape one vs. active x vs. etc.).

first, let's clarify the issues so that we don't compare apples to
oranges, as it were. i'm going to respond to the previous couple of
messages on related topics to give us some context.

> I (Adam) got the following from
> <
> Apparently Sun is selling its Java Beans as Magic Beans well
> worth selling the family cow for. I wonder what kind of
> beanstalk is going to grow out of this, fee fie foe fum and
> all. I'm still not sure how the chicken farmer anecdote below
> is relevant.

sun's java beans effort should be classified as a (supposedly)
lightweight, non-distributed component architecture. it has more in
common with com/ole, opendoc, and taligent's early work than with
dcom, netscape one, or corba. java beans is a component level
abstraction that maps to other models; it provides generic models
for the following services: storage/persistence, events, properties,
methods, and scripting. essentially, it is a super-lightweight
opendoc that is not tightly bound to a document-structured format
like the current implementation of opendoc is (not entirely, but
close). they have taken care to make sure that these generic models
map onto the "complementary" technologies of ole, activex, and
opendoc parts.

> What IS fun though is to watch Sun make Netscape and
> Microsoft out to be the bad guys (yet again) who ruined HTML
> for the masses, but then recoil in their position (hey, look
> at all the cool things that happened when substandard <TABLE>
> tags were implemented! :)
> I also like how Sun appropriated the name COM for their own
> use. COM is becoming quite the overloaded acronym. Speaking
> of overloading, the overloaded use of the word "component" has
> begun, too.

they have dropped the use of "COM" as far as i can tell, because of
the overloaded connotations. the only folks using COM now, to my
knowledge, are Microsoft. too bad Microsoft's Component Object
Model actually has nothing to do with "objects" in the classical
sense...but that is a discussion for another day.

> In fact, when you get right down to it, Sun's Component
> Object Model (COM) resembles the Infospheres model
> (< more every time I hear
> about it:
> 1. COM's component interface publishing and directory system
> resembles the Infosphere interface discovery model.

this is true though java beans do not provide multiple interfaces
to a given bean, unlike infospheres and microsoft's com (if i say
com from now on i mean microsoft's com - got it!?).

> 2. COM's component layout functions resemble the
> Infosphere Djinn Generator application.

a bit. actually, the beans model let's beans render themselves any
way they like and a bean is not necessarily a part of a structured
frame; it can have its own interface(s), each with their own
structure and frame. they also provide mechanisms for discovering
whether it is appropriate to show ones interface or not (beans on
servers need not show themselves; meaning, beans can be
migrating/mobile java class-sets without user interfaces). there is
quite a bit of support for beans rendering themselves, being part
of application builders, customization modules, etc.

> 3. COM's handling events to components resemble the
> Infosphere asynchronous RPC mailbox model.

actually, they are fundamentally different since the beans event
model is completely synchronous and local. you can use javasoft's
remote method invocation (rmi) or corba-interoperability (idl)
within a bean but both are also synchronous at this time.

> 4. COM's component object persistence, or the ability to save
> information about the component over time, resembles the
> Infosphere persistent object model.

this is correct and, given the new object serialization
specification, the flexibility we give our components is now
available to beans, to some extent. in the previous implementation
java objects were serialized (to files or marshalling for
on-the-wire transfers) automagically using their own format. this
was nice because you didn't have to deal with it at all and all you
have to remember was to tag your non-private instance variables with
the transient keyword if they were local and non-persistent (like
file descriptors, awt peers, etc.). the new model makes things a
bit more difficult but puts more control in developers' hands. now,
if an objects is to be made persistent it has to implement the
serializable or externalizable interface. if you implement a class
that conforms to the externalizable interface you have complete
control over how your object is made persistent; the serializable
interface does most everything for you. of course, this has serious
impact on development of classes that inherit from outside sources
(class toolkits, for example) because of this interface restriction.
there are also issues of security and information hiding here that
sun is trying to solve (and doing a decent job at thus far). the
infospheres model does not make this restriction except when you
engineer a djinn that is a java object and you _wish_ to use java's
serialization structure.

> 5. COM's support for linking components into an application
> resembles the Infosphere Djinn Initiator application and
> the Infosphere session model. (gulp!)

except, as noted previously, their components are entirely local.
all beans that are part of a given runtime have to be running on the
local machine (though they can be obtained from remote sources and
can communicate with remote objects if they pass the security
restrictions), likely within the same java virtual machine (they do
not detail such implementation strategies yet).

> 6. Java Beans leverage off existing technologies -- like the Web,
> Java, IDL, and RMI -- as does the Infospheres project.


> Note that they even dip into the telephone analogy like the
> Infospheres project does, in mentioning the metaphor for the
> directory service! I think Infospheres needs to clearly
> distinguish itself from Java Beans on its homepage. What is
> it that makes us different? :)
> -- Adam

in writing this up i'm making the first pass at clarifying these issues.

> Remember Rohit's four predictions about Object World?
> 1) The world realizes the battle lines will be DCOM vs IIOP.
> 2) Some folks are trying to play neutral party (Oracle).
> 3) Some people are innovating around the margins (ILU, RMI)
> 4) Radical innovation is still possible, esp in the guise
> of HTTP/2.

point 1 is interesting since, in the past, people kept comparing
dcom to various distributed systems and frameworks when, in fact, it
is simple an object-oriented revision of dce's rpc. it's just a
wire-format folks! i agree with points 2, 3, and 4, though i would
couch my assent with the statement that if the w3c is the only
organization that is engineering and pushing the adoption of http/2
(ng, whatever) as something more than a web-transfer protocol, they
will have quite the uphill battle given the amount of investment
that has gone into its competitors.

> From what I saw at Object World, these were all observable
> trends. Of course, for Intranet applications, people seemed to
> be leaning to Microsoft to the point that it was noticeable --
> that's why I kept hearing OLE, OLE, OLE.

funny, isn't it? given we had no ability to support intranet
components until the advent of activex. gee whiz! now you can
download a com object _and_ some code to let you view and possibly
edit it! what a concept! before, (and still, for the most part),
if someone sends you a document with an embedded ole object that was
created by an application that you didn't have installed on your
local machine you were sol buddy. now you can get an activex part
that will help you out, though it will have to be installed like any
other microslop (oops, it slipped) application permanently on your
hard drive (imagine the impending clutter and code-bloat there!).

i gotta say that this is just wacky. i mean first we get the
statements like "there are over 1000 activex components available
today!" which when translated from marketspeak means "in the past
eight years over 1000 com objects have been engineering, possibly
the majority of them being classes in microsoft's foundation class
set, and since activex is just com-revisited we can now call them
activex parts!".

> This point is driven home in William Blundon's article
> <
> tml included below if you want to read it. It drives home the
> point that the Internet and intranet markets are two different
> beasties. -- Adam
> =================================================
> By William Blundon
> =================================================
> While Java is the leading candidate for true
> cross-platform software development, Microsoft's ActiveX
> and Distributed COM will provide an elegant solution for
> corporations creating intranet applications. Java has
> an excellent chance of winning in the Internet, but
> Microsoft's preeminence on the existing corporate
> desktop will make it a real player in many enterprise
> applications.

all i gotta say here is "elegant solution"?! @#$?*# !

> 1. DJINN - A djinn is a program structuring construct that serves
> as an infosphere component, and our research involves creating
> techniques for specifying, designing, implementing, reasoning
> about, and discovering djinns.
> 2. SESSIONS and VIRTUAL ORGANIZATIONS - Collections of djinns can
> come together in either connection-oriented or connectionless
> groups to perform distributed tasks. Sessions and virtual
> organizations are two structuring concepts that allow djinns to
> perform such distributed tasks. Our research involves creating
> techniques for specifying, designing, initiating, executing,
> termination, and reasoning about sessions and virtual
> organizations.

good summary here. note that a java bean can be a djinn, but every
djinn can't be a java bean. likewise for ole object, com object,
activex component, and opendoc part.

> Note that in our Infospheres research, we make use of
> object-oriented and Web technologies wherever possible in the
> specification, design, implementation, reasoning about, and
> discovery of djinns, sessions, and virtual organizations. In this
> way, we complement current ongoing efforts rather than compete with
> them. In some sense, then, we can build these constructs using Java
> Beans, Active X, or Netscape ONE, or even whatever else might be
> coming along, because their component object models ARE so similar
> to ours.
> ) Adam

they are similar because that is the whole point of our model; they
are subsets because our structure, model, and verbiage encompasses
them all. admittedly, our implementation still has a ways to go to
give real examples of this statement, but i'm working on it.

questions or comments always welcome,