Hi,
This is my first post on this list, though I have been monitoring this
list closely for a few months now. And I may add that I feel that I am
not knowledgable enough to be taking sides, but, on second thoughts the
subject is so provocative.... Here goes.
> a. It very much seems that you are assuming that all your clients are
> Java clients as you dont support any other form of communication.
> Hence the question are all EJB clients written in Java? If not then
> what are our options.
Line 1 is a misinterpretation. I don't think Rickard has, at any point
in his communication, mentioned that "any other form of communication"
should not supported. On the contrary, (if I have got it correct) his
pitch seems to be that complete freedom be given with regard to wire
protocol, as long as the API exposed by the server to access the data
being pumped thru the protocol is standardised. Now you mention (later
in this mail) that your post is from the standpoint of an application
end perspective. IMHO, the application developer should concentrate on
the logic(s), rather than worry about the wire protocol. As long he is
sure that he has a set of standardised API's, and that he can build
interoperable applications, how should he be bothered if it is SOAP, or
IIOP, or RMI over IIOP, or XYZ under the covers ?
> b. So to connect to another application, the vendor would have to come
> up with a "connector API" and re-invent another wire protocol to talk
> to his application. OK.
If I have understood correctly, the vendor DOESN'T have to come up with
an API. However, they DO HAVE TO implement the standard API's. So, no
question of re-inventing another wire protocol. Well, one may now ask,
"So what wire protocol do we use ?". The answer to this could be "For
your internal stuff, use your custom protocol (so that you optimise to
the best possible extent). For interoperablity, provide hooks for one or
more of RMI/IIOP, SOAP, etc. with the API making it clear to the other
end the protocols supported/understood by it. This should be implemented
transparent to the app developer - maybe in the same way that RMI falls
back to CGI, etc., for tunnelling thru firewalls." This policy leaves
the field open to internal optimisation, and also makes adequate
provisions for interoperability. (I might point out that the danger here
could be a Micro$oft type clone, which builds a $uper-optimi$ed protocol
(relying on tweaking its OS to support it or whatever), but doe$n't
provide hook$ to the other$. If this app server outperforms others by a
significant factor, it might become the choice of all, and because of
its non-interop kill off all others. But, i$ this a reali$tic a$$umption
?)
> Rickard, it really seems to me that support for IIOP would help a lot
> in both the above cases. I wont even begin to say that i understand
> all the issues that you and Jonathan are discussing. But it seems to
> be standardisation/implementation complexity issue than anything else.
> Forgive me if I have an application end point perspective. But i just
> want to remind you of the concerns raised by Andrew. They are real.
Andrew's concerns are certainly REAL. I personally appreciate his
viewpoints. However, there could have been less flame in them. I am not
saying that one should sweeten a bitter pill, but sometimes he got
"carried away" in flaming the other containers.
Now this has been a long mail from a guy who understands only part of
what is being said on this list. Also, I wouldn't be surprised if I have
misrepresented Rickard's outlook to the issue ;-( ,and confused a few
others in the bargain (Advance apologies for that). Looking forward to
some enlightening mails which might set the record straight,
Cheers.
--
Uddipan Bagchi
Associate Consultant,
e-Commerce Division,
e-Enabling Solutions,
WIPRO Ltd.,
3rd Floor, Basappa Complex,
40/1A, Lavelle Road,
Bangalore - 1.
Phone:(080)-2215010 - Ext. 314
(080)-6680876 (PP)
mailto:[EMAIL PROTECTED]
http://www.wipro.com
The World's First SEI CMM Level 5 Software Services Company
===========================================================================
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".
