Jason,
Everything I stated is fact, unlike what you said. Of course I do not like
to use such language on this board but lets be honest saying that I was
incessantly babbling and was being paid by Inprise is not this nicest thing
to say to someone especially when its untrue. I believe your email was
unprofessional and most certainly will reflect on your company. I have
received alot of nice emails from people on this board who have valued my
opinions. If you review some of my psots you will see that most of the
content relates to design issues. I have not attacked every ejb vendor only
the ones that have not provided reliable and quality solutions. IAS is one a
few good EJB Servers the rest are far behind and unless they adapt they will
end just like the dodo. What you attempted to do would in my opinion be
classed as a bribe, is this company practice. Everbody is entitled to their
own views and I would welcome people to refute some of the claims I have
made about SOME products. I am not alone in my views. I think a better email
from youself would have been one that centers on discussion of my posts and
not on shuting me up. Is the truth sometimes that hard to take. After taking
some time out and reviewing my response I must admit that I feel some regret
for having to stooping to your level. I have decided that maybe its just as
well to leave the lambs with the foxes. I will not be posting on this board
anymore, after this last one.
I have just finished reading Steve McConnell's new book: After The Gold
Rush, Creating a True Profession of Software Engineering. Very appropriate
considering your first response. In the book he discusses what I have been
trying to say for along time on this board but not so elegant:
"In the early days of a new technology, there are few established players or
products. The technological barriers to entry are low, and early products
can be small, unpolished, and unreliable and still succeed."
"One of the most damagng mistakes that sucessful gold rush companies make is
to persist in using gold rush development approaches as the technology
matures and their projects scale up."
"One surpising implication of gold rush dynamics is that the companies that
are succesful during one gold rush are likely to fail during the next gold
rush."
This is typically of SOME of the EJB container products that I have
complained about. My views of the IAS and some others can be expressed
better below:
"Post-gold rush software development is characterized by more methodical,
lower-risk, capital-intensive development practices."
"The emphasis is less on rushing software to market quickly and more on
reliablility, interoperability, usuability, and other software engineering
considerations that hardly matter during a gold rush but that matter alot
after a technology matures"
""Post-gold rush customers are what Moore calls "early majority", "late
majority" and "laggards". They are risk averse and want polished products
that work reliably."
If you review my previous posts you will seen a striking similarity to the
views expressed by Steve.
kind regards
William
PS: Steve even mentions "interoperability"
> -----Original Message-----
> From: Jason A. Westra [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, March 16, 2000 2:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Does IIOP Matter !!! READ THIS !!!!!!!!!!!
>
> Your choice of words is a confirmation on your character. Once again, can
> this discussion list stick to EJB topics, not vendor bashing?
>
> thanks,
> Jason
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Louth, William (Exchange)
> Sent: Wednesday, March 15, 2000 1:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Does IIOP Matter !!! READ THIS !!!!!!!!!!!
>
>
> Jason,
>
> Please put your money where your mouth is and send me 50,000 dollars and
> then maybe I will stop, anything to help your company. I will galdly
> forward
> you my bank details. By the way did you know that the webster dictionary
> has
> 2 interesting entries regarding your companies name:
> 2. The stick or wand with which persons were formerly admitted tenants,
> they
> holding it in the hand, and swearing fealty to the lord. Such tenants were
> called tenants by the verge.
> 10. Penis.
> kind regards
> William
>
> > -----Original Message-----
> > From: Jason A. Westra [SMTP:[EMAIL PROTECTED]]
> > Sent: Friday, March 10, 2000 2:47 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Does IIOP Matter !!! READ THIS !!!!!!!!!!!
> >
> > William,
> >
> > Someone must be paying you to slam EJB vendors other than IAS and babble
> > incessantly about IAS features. If so, what is the price? I will pay
> > more
> > for you to stop...
> >
> > Jason
> >
> >
> > Jason A. Westra
> > Chief Technology Officer
> > Verge Technologies Group, Inc.
> > www.vergecorp.com
> >
> > Verge News:
> >
> http://industry.java.sun.com/javanews/stories/story2/0,1072,23299,00.html
> >
> >
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Louth, William (Exchange)
> > Sent: Thursday, March 09, 2000 9:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: Does IIOP Matter !!! READ THIS !!!!!!!!!!!
> >
> >
> > Hi all,
> >
> > I have extracted the following posting from the Inprise Appserver
> Newgroup
> > (I hope this is OK jkw). I think everbody who is considering buying a
> > server
> > or throwing out their current one read this. I know this might cause
> alot
> > of
> > heated discussions but I think it is time we got to the truth about this
> > interop thing. I have had enough of the wild claims, somethings verging
> on
> > outright lies by ejb server vendors. I think it is hard enough building
> > distributed systems without these kind of issues not being resolved. My
> > reading of the spec was that ejb would provide us both portable beans
> and
> > interoperability between beans residing in different containers. Can
> some
> > inform me that this is not the case because of some vendors not updating
> > their architectures or because of my reading being incorrect.
> >
> ==========================================================================
> > ==
> > =================
> > Why IIOP matters
> > Eyal,
> > Consider a deployment including the following:
> > a) WebLogic Server 5.0
> > b) IAS4 (or any other server supporting full IIOP)
> > c) Client program
> > Let's say that the client (c) wants to access EJBs in both servers (a)
> and
> > (b).If you use WebLogic's proprietary RMI protocol (T3), then your
> client
> > (c) can only access (a), not (b), since our product does not support the
> > T3
> > protocol. If you use WebLogic's client-side IIOP protocol, then your
> > client(c) can access (a) or (b). However, if (c) starts a transaction,
> > this
> > transaction will not be propagated to (a), but will be to (b), since
> > WebLogic does not provide full JTS support, meaning IIOP based
> transaction
> > propagation, as per: <http://java.sun.com/products/jts/index.html>
> > Furthermore, since WebLogic only provides client-side IIOP support,
> beans
> > deployed in (a) cannot communicate withbeans deployed in (b), and vice
> > versa. All of these interoperability limitations go away ifyou use two
> > products which provide full support for IIOP.This means using IIOP not
> > only
> > for client-to-server interoperability (which WebLogic supports,
> > partially),
> > but also for server-to-server interoperability (which WebLogic does not
> > support at all). With full IIOP based products, (c) can call (a) and
> (b),
> > either within the scope of a transaction or not.
> > I find it curious that the EJB specification recommends using IIOP in
> > exactly the opposite way. The spec. recommends using IIOP for
> intra-server
> > interoperability, since this is where you need to get different vendors
> to
> > agree how to communicate, and a standard protocol is very much needed.
> For
> > the case of client to server communication, the EJB spec does not
> > currently
> > recommend a particular protocol, since you can always use the particular
> > vendor's client-stubs to get the the objects. With WebLogic, they
> support
> > IIOP only for clients. Curious...
> > -jkw
> >
> ==========================================================================
> > ==
> > ===
> > Eyal,
> > To the best of my knowledge, the following application servers provide
> > full
> > support for IIOP:
> > GemStone, IAS4, Oracle, Persistence, etc.
> > The following provide only client support for IIOP:
> > WebLogic Server 5.0 (still in Beta), iPlanet (not yet in Beta)
> > The following do not support IIOP at all:
> > WebLogic Server 4.5.1 (current WebLogic release)So to answer
> your
> > question:
> > Users of WLS 4.5.1 are completely isolated, in terms of
> interoperability.
> > Users of WLS 5.0 or iPlanet can only use (non-transactional) IIOP
> clients,
> > but have no interoperability among different servers.Users of:
> GemStone,
> > IAS4, Oracle, Persistence, etc. can do whatever they want, in terms of
> > interoperability. Sorry for the "etc.", but I believe there are quite a
> > few
> > other vendors who are building EJB solutions using full IIOP. I just
> > don't
> > know the whole list.
> > -jkw
> >
> >
> >
> > ***********************************************************************
> > Bear Stearns is not responsible for any recommendation, solicitation,
> > offer or agreement or any information about any transaction, customer
> > account or account activity contained in this communication.
> > ***********************************************************************
> >
> >
> ==========================================================================
> > =
> > 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". <<
> > File: Jason A. Westra.vcf >>
>
>
> ***********************************************************************
> Bear Stearns is not responsible for any recommendation, solicitation,
> offer or agreement or any information about any transaction, customer
> account or account activity contained in this communication.
> ***********************************************************************
>
> ==========================================================================
> =
> 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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
