Gregg, I think we are all aware that Jini and JERI have failed to take the market by storm. Just because a technology is "right" in the eyes of an expert does not guarantee its adoption by the market. This is a fact of life not a philosophical preference. Why technologies succeed and others fail, despite the latters' sometimes seeming merit is a complex question of market psychology. Mind you someimes one can point a finger at ineffective marketing as being an obvious cause. To be frank I doubt that even Sun would claim that they have done a good job of marketing J/JS technologies.
To return to the original theme of this thread, the fact that JavaSpaces failed miserably to take off (I speak from the experience of a tediously long market survey I did a couple of years ago) does not automatically preclude someone else launching an alternative tuple spaces implementation. Java, on the other hand, has probably turned out a far greater success that a hardware-centric company like Sun could have dreamt of - as we all know. That does not mean that political and psychological factors outside the control of technical arbiters would always make it acceptable in a given situation. We all know people who in certain situations prefer alternatives. This does not mean that they are necessarily naive or childish. Gervas --- In [email protected], Gregg Wonderly <[EMAIL PROTECTED]> wrote: > > Anne Thomas Manes wrote: > > Unfortunately, the market frequently isn't especially concerned with the > > best technical solution. Politics happen. > > So if we accept any and all politically motivated decisions as okay, where are > we going? > > > I know the JERI enables interoperability with non-Java environments, but > > Jini/JS still has a hard dependency on Java, and that will always cause > > political resistence, limiting its potential adoption rates. > > Only as long as people interacting with the politically driven, naive position > are viewed as behaving acceptably. It seems to me, based on the people which > I've interacted with, that the vast majority of the political positions are > driven from ignorance and childish NIH behavior more than any sane, rational > decision process. So, to me, it's not an acceptable position. It's one to ask > more questions about and find whether there is a secondary basis or some other > factor that is creating the outward view of "politics." > > I come from a line of thinking that people will behave the way you expect them > to behave. Match your expectations to what you want, not to what you think they > can produce, and you'll get more rational behaviors. > > But, I'm probably a bit odd in that regard. > > > btw -- this comment isn't quite accurate: > > > > "In WS-* applications the conversion from native data types to SOAP or some > > other wire or invocation layer representation is done smack in the middle of > > the application. What difference does it make where that conversion is > > done?" > > > > Typically when using a SOAP framework, such as .NET, Apache Axis, WebSphere, > > WebLogic, SAP NetWeaver, SOAP:Lite, PEAR SOAP, Ruby SOAP, etc, the > > application doesn't need to perform conversions from native types to XML. > > The conversions are performed automatically by the middleware. > > As Dan mentioned, for a few basic types, yes. And for others, sometimes IDE > wizards and other similer tools can be helpful about providing coversion > functions. But in the end, its closer to the user code, and part of the > software that is built into the delivered package, instead of being a choice at > deployment time. > > If it's done at deployment time, two things can happen. One, you'll be > motivated to have a library of standard conversions which will allow for better > code reuse. And two, if you don't need the coversion, you don't have to > mechanically turn it off, or plug into the service at a different level to > provide an interface that meets the need of the deployment. > > Gregg Wonderly > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
