Actually, my point of view is from a B2B perspective. We currently have
connections to other companies for exchanging data. In one particular case
that I have in mind, we have a CICS based application communicating with an
application at another companies site. Since a requirement of this
application is "real time" processing, we are using LU6.2 protocol on an SNA
connection. This particular "wire protocol" allows security information and
to some degree, transaction context to flow over the wire, we can allow this
external company to invoke transactions in real time via this wire protocol.
Since this external company is complying with the LU6.2 protocol, in
addition to the semantics of the transaction they are invoking, we don't
care if they are running a CICS region, an IMS region, or a home grown tp
monotor running on an atari game machine!
The point I am making is that in this particular environment, there is no
way that we would allow this external company to send us a load module that
had to run in our internal CICS region (where we keep customer's accounts
with real money in them) just so that we can communicate faster with them!
If EJB servers are going to become the TP monitors of the future, I have a
vested interest in making sure that I believe that they can be secured in
this way.
John Zerbe - Mellon Bank
Information Technology Solutions - Middleware Team
Phone: 412-234-1048 E-Mail:[EMAIL PROTECTED]
> -----Original Message-----
> From: Neil Thorne [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, April 12, 2000 9:16 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Why embassies matter, was Why smoke signals matter
>
> I wouldn't think it was that much of a pain if I got was able to send lots
> of data of a particular kind very quickly. You are talking about a very
> generalised application when you talk about an email program. If you
> really
> want to encourage lots of different kinds of EJB server some better for
> speed, others better for resilience, etc. you have to make the protocol
> wide
> enough to allow these things, which bloats it and makes it slow. Or you
> can
> download a plugin which talks its own language. The plugin download might
> be
> a trivial hit if your performance increases substantially.
>
> -----Original Message-----
> From: Zerbe John W [mailto:[EMAIL PROTECTED]]
> Sent: 12 April 2000 08:00
> 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 �berg [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 �berg
> >
> > @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".
> ***
> This e-mail is intended only for the addressee. This e-mail and any files
> transmitted with it may contain confidential or privileged information. If
> you are not the named addressee or the person responsible for delivering
> the message to the named addressee, please contact
> [EMAIL PROTECTED]
>
> This e-mail has been scanned by MIMEsweeper.
>
> Visit the Prebon Yamane web site at http://www.prebon.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".
