Wolf and EJB-INTEREST:
Some thoughts to liven up the conversation...
Your example is exactly part of what CORBA attempts to do. That is, allow 2
different languages to communicate (using a language neutral intermediate
form). Thus, person (appserver) interoperability is _facilitated_ using a
standard intermediate form (IIOP). But, a standard API is still needed on top
of that intermediate form to properly communicate with another entity - thus
IDL for defining those APIs and a set of standard APIs (CORBA Object
Services). A common intermediate form facilitates communication but does not
ensure it by itself.
Your pluggin still has to have a Muttersprache translator. The question is,
does it translate Muttersprache into "N" different languages (i.e. different
wire protocols or APIs) or a common language (English) which can then be
translated into "N" different languages as required? Either approach will work
but have radically different engineering costs. But I think this example
misses the point of the API vs wire protocol argument.
So, what I'm going to attempt to do here is argue that we need both a standard
API _and_ a common wire protocol. A standard API to help facilitate a more
exact representation and interpretation of syntax _and_ semantics (to help
prevent the problems with implementation that JKW alluded to) and a standard
wire protocol to facilitate communication between heterogeneous systems in the
MARKETPLACE. One technical, one political.
>From your example, you (a translation application) translate Muttersprache
using a common API - call it English. Then, using a common wire protocol
(SMTP, Unicode, ...) we send this out to some other entity. That entity knows
about the common wire protocol and thus can interpret it using some different
tool, written in some different computer language, by some different vendor
running on some different platform. Minimal architectural constraints here.
Then, you have another translation application that translates the common API
(English) into whatever form you need (Spanish). Maybe a better example would
be translating a specific Muttersprache conversation describing a ballistics
problem (Newtonian physics) into an exact mathematical representation (that
precludes ambiguity) and then back into a target language such as French.
For interoperability to succeed we must agree on both the syntax and semantics
of the information passed between components whether that information is passed
by a common wire protocol or a common API or both. As JKW stated, the failure
of either end to properly interpret/implement the syntax and semantics of the
interface cripples that interface _politically_. (If I fail to translate
Muttersprache into F=ma then I'll not succeed in communicating regardless of
whether symbolic mathematics is valid). If vendors fail to properly implement
the interface, then the interface will fail. This is independent of whether
which technique is used and I believe that this was JKW's major point.
Wire protocols have a long history of interoperability success stories long
before the appearance of IIOP - RS232, TCP/IP, etc. Whether IIOP is a success
or not is not indicative of the validity of the approach. Its the
implementation of the protocol, not the idea of the protocol by itself (which
is what I think JKW is arguing) which determines its success in the
_MARKETPLACE_. I believe that having a standard wire protocol helps immensely
in achieving the goal of heterogeneous systems interoperability as CORBA has
shown (sans the failure to adhere to the interface problem). Other protocols
have suffered more or less from the same implementation symptom - e.g. RS232 in
the old, old, days didn't always work so seamlessly. But as I'm claiming, wire
protocol is not sufficient. Maybe its not even necessary, as some argue, from
a technical perspective, in the software world.
Thus enter the common API approach. The common API via JINI approach is new
and interesting. Its not yet a proven technology. But the API approach _is_ a
proven technology for expressing syntax and semantics (arguably to some
degree). Both the wire and API approach _can_ help to achieve
interoperability. I argue that we need both to effectively achieve it. API
for a tighter specification of the syntax and semantics of the information
being passed independent of its transport, and a common wire protocol to
facilitate heterogeneous system interoperability in terms of the realities of
the marketplace. (Note here that we could augment Java APIs defined in terms
of standard Java types with a richer specification based upon XML that would
capture more of the semantics. But that's just an improved API specification
mechanism and a red herring for this argument.)
The question is, can the JINI approach succeed in the marketplace and thus make
wire protocols obsolete? While JINI might be able to hide wire protocol
issues, it forces an architectural constraint on systems that use it - namely
Java. Cool enough technology, ..., but (I think I'm showing my age here)
technology by itself is not necessarily a win :-(
See Dick Gabriel's "Worse is Better" paper from 1991. Still relevant if a bit
dated technology wise.
http://www.kde.org/food/worse_is_better.html or
http://www.ai.mit.edu/docs/articles/good-news/good-news.html
I believe the JINI approach to interoperability at the API level has a number
of problems:
1. Its Java-centric.
My understanding is that JINI in current form relies upon Java serialization
and RMI (at least for initial communication with the lookup service). Thus it
requires Java (in part) to operate. This is a fundamental flaw with respect to
the marketplace (not technospace).
The world is not all Java as much as we would like it to be. The reality of
the world is that it is heterogeneous - different implementation languages,
different platform types, different platform capabilities (performance,
capacity). I believe that the success of a language platform today is hinged
upon its ability to interoperate with the rest of the world. (Being an old
Lisper, I'm intimately familiar with what happens when you attempt to
reconstitute the world in terms of your own world view!)
Some vendors understand this, some don't. Some used to not understand this and
now do. Interesting that both have had to deal with the US Justice department
in one way or another. Those who don't learn from history are doomed to repeat
it :-) Are we just going down the same path again but badging it Java? But I
digress.
Yes, I know in theory one can embed a JVM in each application to deal with
downloadable stubs in the client and skeletons in the server, and communication
with the lookup service, but this seems to beg the question of performance,
footprint size, platform availability, organizational acceptance. Possibly
more importantly, it _forces_ an implementation architecture that uses a JVM
for inter-component communications. For application servers, this probably
isn't a big deal; they are already big and many are written in Java. For an
appserver written in C (presumably for performance reasons) this imposes a Java
intermediary for interserver communications thus reducing potential performance
for the cluster. But it does fix one's architectural choices.
But, my main point here is not technical. Its political. JINI doesn't work
for interoperability because it mandates an interoperability solution at a
level that imposes itself on existing systems (embedding a JVM to be JINI
aware) that is not acceptable in the marketplace. JINI is fine in its own
niche, but goes too far to work for heterogeneous system interoperability.
2. Security.
As a number of others have already stated, this is a serious marketplace
issue. No way I'm going to allow arbitrary code from the outside world to run
in my environment. Without some sort of sandbox idea similar to applets, I
don't see JINI succeeding beyond a niche market.
So...
- standard APIs for communicating syntax and semantics (possibly augmented
with stuff such as XML to tighten up that semantic specification) mapping onto
- standard wire protocol to facilitate heterogeneous system interoperability
(technically not necessary, but politically required)
Using both helps with the technical aspects while keeping the realities of the
marketplace in sight...
JINI does the API thing with potentially fatal flaws relative to the
marketplace.
IIOP does the wire protocol thing but falls short in exacting specifications of
APIs.
Arguably, combining wire protocol and API definitions is exactly what CORBA
does. IDL for defining interfaces in an exacting way, common service APIs
(such as Naming Service, Object Transaction Service) defined in terms of IDL,
and a well defined mapping of these APIs onto a common wire protocol to
facilitate heterogeneous system interoperability.
Geez, I'm sounding like a marketing droid.
Just some thoughts to keep this interesting discussion alive and well :-)
ba
> If You publicized a plugin that allowed me to
> speak to You in my native(?) language (Muttersprache),
> without having to worry about what You can understand,
> I would definitely use that plugin. It would make life
> easier for me and would boost my e-mail performance :-).
>
> The security aspect has to be concerned. But if the
> plug-in would be delivered by the application server
> vendor and people with security restrictions could
> get it directly from the vendor and install it statically
> instead of downloading it, then this problem could also
> be solved.
> Additionally, the "pro-API" group doesn't argue against
> standardization of IIOP communication. That leaves the
> option to everyone to buy app servers which support IIOP.
>
> Wolf Siberski
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Zerbe John W
> > Sent: Wednesday, April 12, 2000 3:00 PM
> > To: [EMAIL PROTECTED]
> > Subject: FW: Why embassies matter, was Why smoke signals matter
> >
> >
> > Rickard,
> > How are we all able to communicate on this list? Did we all
> > have to download
> > and install an E-mail translator for each other's Email
> > software? I happen
> > to be using Microsoft Outlook to formulate this response.
> > I'll bet that
> > there are people using things like Lotus Notes to read this message.
> > Wouldn't it be a pain to have to install a plug-in (build and
> > embassy) for
> > each different vendor's email products? Isn't it convenient
> > that by virtue
> > of having a common, well defined wire protocol for email that I can
> > communicate directly with you with no extra set up and not
> > having to trust a
> > plug-in not to have a virus of some sort in it?!
> >
> > Being a financial institution, we have a long standing policy against
> > accecpting and running code from external sources. Its much
> > more difficult
> > to do damage with a packet of data over a wire protocol.
> >
> > John Zerbe - Mellon Bank
> > Information Technology Solutions - Middleware Team
> > Phone: 412-234-1048 E-Mail:[EMAIL PROTECTED]
> >
> >
> > > -----Original Message-----
> > > From: Rickard Vberg [SMTP:[EMAIL PROTECTED]]
> > > Sent: Wednesday, April 12, 2000 3:09 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Why embassies matter, was Why smoke signals matter
> > >
> > > On Tue, 11 Apr 2000 13:39:00 -0700, Jonathan K. Weedon
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > > Why application server interoperability
> > > > should be based on smoke signals
> > > >
> > > ><vendor>
> > > <snip>
> > >
> > > Either I am really bad at explaining things, or you really haven't
> > > listened at all. You took one of the minor points of the
> > anti-protocol
> > > side, enlarged it as much as possible, and almost provided
> > an argument
> > > for your point of view. I'm not very convinced just yet,
> > sorry. And if
> > > this was the best argument you could come up with, I don't
> > quite see why
> > > we're still discussing this.
> > >
> > > Anyway, I'll try to play your game and use metaphors. Maybe
> > that will be
> > > easier to understand.
> > >
> > > Once upon a time there was an indian tribe called the
> > Hopis. They lived
> > > in groups that were far apart on the great plains of America. To
> > > communicate they found that the most effective method was
> > to use smoke
> > > signals. This worked very well since the land was dry and fires were
> > > easy to set up, and the absense of high mountain ranges and
> > clear skies
> > > made it even more effective. All is well.
> > >
> > > In another country, far away, there are Tibetan monks who
> > live in the
> > > rocky neighbourhood of the Himalayas. They too needed a way to
> > > communicate between the monasteries. However, unlike the Hopis they
> > > found that smoke signals didn't quite work. The high mountains and
> > > strong winds made the smoke dissipate too much to make it work well.
> > > Making a fire was also tough since the landscape was
> > covered with snow,
> > > and burnable material scarce. Hence, they used fast runners to send
> > > messages. Comparatively slow, but reliable.
> > >
> > > In yet another country, living in the vast Amazon rain
> > forests of South
> > > America, there was a tribe who don't really have a name
> > (AFAIK it's not
> > > pronouncable using western syllables). Nevertheless, they
> > too needed to
> > > communicate over distances somehow. But smoke signals
> > wasn't reliable
> > > (have you ever tried to light a fire in a rain forest?
> > "Difficult" is an
> > > understatement), so they mimicked the animals and used
> > sounds. Sounds on
> > > particular frequencies and created using fairly large
> > instruments can
> > > travel far in a forest, and since it was hard for an
> > untrained ear to
> > > distinguish it from animal sounds they were easy to conceal from
> > > unwanted listeners.
> > >
> > > All three tribes communicated like crazy within their
> > respective groups,
> > > until one day they each learned of each others existence.
> > "Hey, cool,
> > > more dudes to chat with!" they thought. So, the Hopis
> > started signaling
> > > using smoke, thinking that "hey, anyone can do smoke
> > signals, right?".
> > > Unfortunately, neither the monks nor the Amazon fellows ever got the
> > > message, and if they did they wouldn't have been able to
> > decipher the
> > > signals. Tragedy. So many new friends, and no way to talk.
> > >
> > > And so it was for a long time, until one day one of the
> > Tibetan monks,
> > > after a particularly inspiring meditation session, had a vision:
> > > "I know, let's send one of our guys to the Hopis. We can use sign
> > > language, or he can learn the Hopi language, and if they
> > have something
> > > interesting to say he can come back and tell us!". And thus
> > the concept
> > > of an "embassy" was born.
> > >
> > > The Amazon dudes learned of this trick and also sent an
> > ambassador of
> > > their tribe to the Hopis. After some tweaking the monk, Hopis, and
> > > amazon dude managed to understand each other, and the monk could run
> > > back with some important information, whereas the Amazon
> > used his horn
> > > to tell his friends (and considering the distance he had to
> > blow REALLY
> > > hard! But it worked).
> > >
> > > And from that day they communicated without a glitch. Happy happy.
> > >
> > > And noone ever considered using smoke signals only. Because
> > history had
> > > shown them that this didn't work too well all over the world.
> > >
> > > The End
> > >
> > > /Rickard
> > >
> > > Metaphor reference:
> > > "tribe"="vendor"
> > > "Himalaya"="firewall"
> > > "horn"="cell phone"
> > > "embassy"="API-based proxy"
> > > "smoke signal"="IIOP"
> > > "running monk"="RMI/SOAP"
> > > "conceal from unwanted listeners"="super-mega-encryption++"
> > >
> > > --
> > > Rickard Vberg
> > >
> > > @home: +46 13 177937
> > > Email: [EMAIL PROTECTED]
> > > http://www.telkel.com
> > > http://www.ejboss.org
> > > http://www.dreambean.com
> > >
> > >
> > ==============================================================
> > ============
> > > =
> > > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the
> > > body
> > > of the message "signoff EJB-INTEREST". For general help,
> > send email to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> > ==============================================================
> > =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the body
> > of the message "signoff EJB-INTEREST". For general help,
> > send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
