Jonathan, Your response, and generally, the aggressive marketing that Inprise is doing on this list, compels us reply. By and large, our attitude towards competition remains one of "live and let live", so I have no intention of furthering the dishing that has gone on here of late. We applaud innovation especially wrt to advancing J2EE. The Inprise tradition of innovating, going back to adopting Java, developing Caffeine, is established and respected, its entrance into the the EJB container market is welcome. I'll add that I have nothing short of the utmost respect for the numerous other vendors on the list that have shown restraint in the face of recent posts. This makes perfect sense since vendors who have customers can not afford the vitriol, still it speaks well of them that they continue to treat this list with respect. I urge vendors and their boosters to use the vendor's own news groups for vendor specific traffic as EJB Interests is not an appropriate forum for promotional posts. We at BEA count ourselves among the CORBA vendors that are happy that the CORBA spec continues to progress. We have a lot of interest in the ORB, not the least of which is motivated by protecting our customers' investment in our ORB products. But this does not lead us to elevate even our own ORB infrastructure to the level called for by the EJB Interop spec. In this, we side decidedly with Rickard and invite you to do the same. The reasons are exactly as spelled out in Rickard's post, and ironically illustrated by your response. For example, Rickard states that there are existing and historical problems with IIOP, that in effect it does not work; you then talk directly to the evidence that contradicts you, supports his statements, namely that there is no interoperable security context. Further on, you argue that IIOP is just a protocol, yet it constrains innovation, prescribing ORB constructs for proxies and invocation (DII). You argue that IIOP is not obtrusive and make the incredulous claim that customers ask for and support the obtrusiveness. With all due respect, if CORBA was so great, why are so many ORB vendors re-launching themselves as EJB containers? I have nothing against this approach, having adopted it ourselves, but as I've wondered how this came about, I come to the conclusion that as an industry the CORBA market was worried about the wrong things. Compare the relative failure of the IIOP protocol, described in your own words, to the success of, say, HTTP: the comparison leads me to conclude that IIOP, as Rickard describes, is irrelevant, far from the required standard bearer that you call for here. As Rickard points out, IIOP is great for talking to C++. We agree. Your arguments in effect invite us to follow the path that the CORBA vendors have trod for years. We decline. We decline because the argument in favor is specious, too weak, and the arguments against it are too compelling: we decline because in the bigger picture, it is not just interoperability between EJB containers that is being addressed but rather interoperability across J2EE. J2EE calls for a level of interop that puts further, as yet to be defined, requirements on JDBC, JNDI, JTS, JMS, EJB. The functional requirements for each of those specification are, in and of themselves, rich and call out for innovative solutions. In our opinion, IIOP is dated and inefficient, not especially suited when both sides are Java, and there are no real examples of it working as claimed (respects to Fujitsu, Hitachi, others). We decline even though we offer support for RMI-IIOP, albeit targeting support for C++ connectivity with our own products, based on our own experience as a provider of an RMI-IIOP solution. I have a hard time understanding why we are even having this discussion. The only context that appeals to me at the moment is this: CORBA is a brand. Like all brands, it has some strong followers. Technology companies that market that brand abound. Here the attempt is being made to market that brand in the J2EE space, but not everybody buys it: only those who are loyal to the brand are drawn to products that bear the brand. The contrast is that J2EE is not defined as narrowly or even in terms of that brand, hence calls for the plurality and the opportunities we see in the market today. All the better for J2EE, imo. Where does this leave us? Java and J2EE owe their success to the API and SPI. Clearly, we would not be here otherwise. We argue, along with Rickard, that to stimulate innovation and motivate the progress of the J2EE specifications, we need to continue the pattern of success with precisely those approaches. We invite you to do the same or argue your cause at the next round table discussion. Until then, let's take this discussion off line. =========================================================================== 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".
