Anne Thomas Manes wrote:
> Gregg,
>
> Unfortunately, the market frequently isn't especially concerned with the
> best technical solution. Politics happen.
>
True enough - however, as an analyst, I'd have thought you should be
attempting to cut through the politics and present the best solutions?
You appear to be advocating accepting the opposite?
> 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.
>
Isn't this similar to complaining that to run 'C' I must have the
appropriate libraries and the binaries compiled appropriately for all my
different systems? i.e. One must have a JVM installed?
S'far as I can see this argument could be trivially reversed. I'm a
Java house and object to all the aggravation I get with 'C' on different
platforms?
The next question would then be:
How many companies hate the hard dependency on Java vs those that hate
the hard dependency on native code?
Followed by:
If you hate the hard Java dependency is that because you aren't aware of
the myriad of architectural and implementation level solutions available
to make this easy to deal with?
And lastly:
If you are prepared to ignore all those options and solutions presumably
you're happy to pay the penalty of low levels of design abstraction
forced on you by having to do marshalling/unmarshalling into/out of XML
where only a subset of primitive types can be handled automatically?
> 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. In the Java toolkits, a service is implemented as a POJO,
I'm not sure that's entirely true either! Conversions are automatic for
a relatively small, well-defined subset of types and typically nothing
as complicated as an Object or struct. It has to be that way to cope
with the fact that programming languages as a whole only have these
primitive types in common.
This leads to a nasty issue where the middleware does some conversions
and the rest have to be dealt with by you. Sometimes the middleware
comes with tools to help with that but you still have to take some
positive manual action and know when that action is going to be required.
Of course, you could build your system entirely based on just this
subset of types but you lose a lot of expressive power. You could of
course compensate by writing marhsalling code to convert back and forth
between the primitives and your more complex objects but lets face it,
we all have better things to do, right?
> and clients simply invoke operations on proxy objects. It feels very
> much like RMI, although it's a document exchange system rather than a
> distributed object system. Developers should be aware of that subtle
The difference being? One can do document exchange over the top of a
distributed object system or do a distributed object system on top of
document exchange. IMHO, this is about your preferred way of viewing
things more than it's an implementation level issue.
So, can you please explain what you consider the differences to be
because at the abstract level, I see little difference?
> distinction (although many aren't -- leading to a variety of bad
> practices).
>
> Anne
>
Dan.
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/
