Eric Newcomer wrote:
> I think it may be a question of whether or not one
> believes it's still possible for a single language to
> become ubiquitous. I don't.
>
> Also it's not necessarily a lowest common denominator
> situation. If you use WS-* for bridging software
> domains and use Java for what it's best for within its
> domain, everyone wins.
I guess I must be using the wrong words...
Having to bridge requires you to compromise in some sense. Continuing to
create
applications that require bridging is promoting that position and making your
architecture more susceptible to the speed of technologies related to that
bridging.
> I may not have been clear enough in identifying the
> role I see for Web services. I do not see them as
> replacing Java - that would be foolish. But as a way
> to tie together Java, C, COBOL, C++, VB, etc. XML and
> Web services do a great job.
Many times WS can do the things (which you are restricted to using) needed to
solve problems due to the multi language environment. There are times when
that
is desirable. I did say not "always" needed or desirable.
> One thing I forgot to mention about the STDL
> experience - we designed STDL data types for
> compatibility across COBOL, C, and SQL. The
> intersection of common data types across these
> languages is pretty small.
Yes, and that is my point. If you need to do that, do it. But don't turn your
ESB and entire SOA on end to make that the common mode of operation.
> Regarding mobile code, I do not think Java has the
> corner on that market either. It's as possible to
> create C++ plug ins that are dynamically loaded in a
> microkernel container, for example.
Which C compiler generates code that I can run on all processors and is bound
to
all versions of all libraries running everywhere? The other piece is security.
There is no specification in C for code level security, authentication and
authorization. We've already seen on the web what can happen when downloaded
binary code is not controlled by a security system.
> Unlike Web services, Java was not designed as an
> interoperability language.
I think this is where you are missing the whole argument. Java has support for
interoperability with a wide range of protocols/platforms. If you need to do
something that Java can't do as your service (I'm not sure what that might be
given my experience using Java for a wide range of applications), then have at
it. But, neutralize your homogenenity at the points where it interferes with
the architecture more than it adds value.
> It was designed to be a
> ubiquitous general purpose language. I would never
> argue that Web services should replace Java, and I
> can't agree that the reverse is the case, either.
Humm, Java, like many languages supports web services programming paradigms.
It
is not a replacement for web services. However, mobile code is a replacement
for and a huge advantage to web services protocols. Java provides one of the
most robust, flexible and capable mobile code environments in a mainstream
programming platform that is available today. The security model, URL
classloader support and the other advanced features of Jini 2.1 are unmatched
from my perspective.
As I've said here before, the JERI stack extends the RMI programming model
quite
extensively with a plugable stack. This makes it possible to use RMI calls
into
a wide range of wire protocols. The wire protocol no longer matters when you
have this capability.
Web services is like the phone network trying to do ATM. What the phone
company
found out is that routing needs to be alot more dynamic and the application
needs to be in charge of a lot more and be able to make more choices. The
inclusion of IP based networking is exactly what allows the wire protocol to
not
be important. What web service do is completely isolate the application from
network based computing. You get to reimplement all of the facilities of the
network protocols because you can only send data. This is where web services
break down.
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/
