How about a short scenario for the sake of this very interesting thread? Say: ++ application on a CICS system ++ application written in 'C' on some U*X system ++ application written in VB on some Windows system, including Excel spreadsheets (the most used development environment and application in the world) ++ application written in COBOL on an OpenVMS system ++ application written in RPG III on an AS400 ++ new application under development using Java, Jini and a DB
The Java/Jini application has a requirement to reuse "services" from the other systems. What is the best way to: 1. define those other systems, i.e., their interfaces to Java/Jini 2. allow those other systems to invoke code in the Java/Jini application 3. ensure smooth transition of the legacy "services" to the Java application under development, i.e., as new "services" are written, they will seamlessly replace those in the "old" systems 4. provide a development, test and deployment environment to all systems (this is not directly related to WS-*, but without it things become a nightmare very quickly) The above scenario is not something off the top of my head, but something I've seen with many customers. Cheers, john --- In [email protected], 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 > 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/
