Mark Baker wrote:
> On 8/25/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>
>>The JMS API will be usable for the
>>enternity of Java. HTTP is no more resilent than CICS or COBOL.
>
> What I'd like to know, is how you managed to send an email to this
> list from the alternate universe you obviously inhabit? 8-)
I can only suppose that you know something that I don't know, such as the date
that JMS will no longer work to allow messaging between so equipped Java
programs? Is someone besides microsoft injecting EOL control into their
software systems? I'm not a JMS fan, because it was originally locked into the
J2EE platform, a lot of third party solutions were developed for J2SE. But, it
does work, and it does make it possible for Java processes to talk.
It surely makes sense that if you need to, that you might choose to use a wire
protocol that provides interoperability with more disparate programming
languages/platforms. But, I think it's short sided to design an architecture
to
only support on wire protocol. So, if you can support more than one, then why
not use one which provides optimal client-service performance?
> Serously though, languages come and go, but protocols that reach
> ubiquity tend to hang around for a very long time; portability doesn't
> provide anywhere near the network effects that interoperability does.
Mark, if you can tell me exactly when Java, C, C++, COBOL, ASP.Net, C#.Net,
Ruby, Python or any other programming language will no longer be viable, then
that will be the moment that I'll be convinced that programming language
features have no value in system design.
There are plenty of protocols that have left the building. Every part of the
technology game is up for grabs. What we have to decide is what values are
more
important to the total advancement of computer based service development. I
contend that a single programming environment is a giant leap forward because
it
stops recreation which adds no value, and focuses everyone on the extension of
the language and associated libraries and platforms to really add value.
All we've managed to do is create evolution at a huge cost. Java created a
revolution by providing platforms in addition to the language. No other
language has had such an extensive and useful library/platform.
All the other languages that I am aware of have only slightly evolved the
capability of the programmer to be productive (and consistently so) for a wide
range of applications. Some Application Oriented Languages, have made a
certain
smaill class of applications.
It is this focused level of productivity with small language systems targeted
at
specific types of problems which is the driving force creating the lack of
language level interoperability. Java provides a nice level of consistency in
language use across the whole set of platforms from Java-card to JEE. Yes,
there are some language features not supported.
The language feature distinctions force everyone using multiple language
environments to have to use an abstraction layer to communicate between
applications written with different languages.
If you desire to take on the task of wire protocol based interoperability, why
would you not choose to reduce the total number of programming languages you
are
using for systems development to reduce the total number of support issues you
have as well as to reduce training needs and other factors?
If you think that wire level interoperability is the ulitimate solution, what
are you doing to accomidate the changes in wire protocol that will occur over
the life of that wire protocol? What if new security mechanisms, encapsulation
needs or other changes are needed? How will your application deal with those?
Or, will you wrap the application as Stefan suggests, with a new
isolation/mediation layer?
Tell me more about what you view as the language based barriers which makes it
impossible for language/API based interoperability. How are those barriers any
more difficult to work through than those associated with wire protocol
development?
I don't see how wire protocol interoperability is either technically,
practically or politically easier to manage than language API based
interoperability. In the end, a particular wire protocol has to be interfaced
to an application with a particular programming API. So, how will that API be
any less of an issue than another API such as JMS as an example?
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/
