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 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. 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. 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. Unlike Web services, Java was not designed as an interoperability language. 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. Eric --- Gregg Wonderly <[EMAIL PROTECTED]> wrote: > 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 > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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/
