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/
