Eric Newcomer wrote:
> I think there are a lot of misunderstandings here, and
> perhaps some varying assumptions underlying the
> arguments.
>
> WS-* specs are actually designed to be multi
> transport, multi-data format, multi language
> compatible, and extensible.
My point about "one protocol" is specifically about "one standard". There are
times when XML is not important, nor advantageous. There are times when HTTP
is
not available, nor necessary. By the time you add all the ifs, ands and
buts,
you've eliminated the need for a new set of standards such as WS-*. The only
thing needed to make communications work is a documented protocol, or a library
that works on your language/OS of choice. Choosing Java/Jini doesn't reduce
the
set of protocols you can choose to use for your SOA. But, choosing to base
your
SOA on WS-* and then using more than one language/platform does limit your
choices of how you will solve problems in your SOA.
> I believe the software industry is past the point at
> which we imagine that a single operating system,
> programming language, database management system, or
> middleware system will become the one and only. I
> remember when we used to think CORBA would become such
> a thing, or C, or even Java. I remember during the
> late 90s when we all started thinking things like
> "I'll have to rewrite that in Java someday."
>
> The great thing about XML and Web services is that it
> supports heterogeneity - it was designed to layer on
> exising transports and protocols. XML can be used
> with any programming language. One of the significant
> problems XML solves is data independence. Without a
> neutral data type format, we face a literally
> polynomial explosion of data type mapping combinations
> -- Java has a different set of datatypes than VB, so
> does COBOL, C, SQL, and so on. All for good reason,
> of course, since the data types support the language
> design.
Which do you think more important? Having the ability to create rich,
featureful applications that run on any OS and can communicate effectively and
effeciently, or a homogeneous communications standard that limits the set of
features that you can use to solve problems in your SOA? It's not quite that
black and white, but that's the balancing point from my perspective.
> The software factory movement and associated domain
> specific language work takes as a fundamental
> assumption that no single general purpose language
> will ever be the best for everything.
Java is not good for everything, but is is absolutely the best language in
connection with Jini for creating performant distributed systems that are
portable across all OSes and which can scale using powerful platforms such as
RIO for QOS based systems configuration, automatically managing your SOAs
performance for you.
> With Java of course the classic tradeoffs have
> revolved around the ability to "write once run almost
> anywhere" - which means low level memory and I/O
> operations have to be abstracted through the VM and
> invalidate the use of some operating system specific
> libraries. Java today is of course much faster than
> it once was, but it is still not as fast as a native
> language. Java is often not the right choice for
> real-time or embedded applications, for example, or
> for games.
I don't see anyone saying that Java is the be all end all for everything. But,
it is often as fast as, or faster than compiled languages because of the
technologies that JIT compilers utilize which far surpass many things that are
possible with static compilation.
> But getting back to Web services. They are not
> executable. They are just applications of XML that
> define interfaces and a data model for
> interoperability.
That's a pretty good summary of some of the big limitations of web services.
> Our ESB uses WSDL to promote execution environment
> choice rather than restrict it. I have seen surveys
> for example that a large portion of the world's
> developers still use C/C++ for example. A great
> number use VB and C#. A good proportion still use
> COBOL, and some use other languages such as PL/I,
> Python, Perl, PHP, Ruby, Lisp, and so on.
It is exactly the fact that we still use so many languages that we find ESBs
and
things like web services to be necessary. If you want to focus on maintaining
a
heterogeneous computing environment from a language perspective, have at it.
Choosing to always use the lowest common denominator of computing possibilities
will keep you neatly positioned for your competitors to out perform you.
> IT environments tend to represent a mixture of
> technologies, such as .NET and J2EE, but also
> WebSphere MQ, CICS, IMS, Tuxedo, CORBA, Tibco, JMS,
> etc. Using a single executable language to bridge
> them all just won't work, or at least not as well as
> using XML as the independent format.
Java, as a language can trivally do XML just as most other languages can. The
question is, is XML capable of doing everything that you need in your SOA? I
think that missing out on mobile code is a big issue. Perhaps you enjoy doing
code distributions across 100's of computers to fix a bug in your client side
library?
> Our assumption is that the use of XML (and its
> application in WSDL) promotes choice rather than
> constrains it. Every language can understand XML. But
> not every language can understand Java.
The issue is to to make every language understand Java. The issue is that Java
can be used to bridge a large number of protocols directly. Out of that, you
have the ability then to choose which protocol you use on your ESB, and more
importantly, you can use mobile code to distribute to the clients, the
implementation of the protocol that you want to use today, and tomorrow you can
change that protocol and because of mobile code, the client doesn't know
anything about what you are doing differently.
The point of Jini with Java is that protocols no longer matter. It's the
application that's important, and with plugable endpoints you can change it.
What's different from using web services "only" is that with Java, you can use
mobile code to make that protocol change/adaptation invisible to the clients.
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/
