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. 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. 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. I think it's safe to say that in the design of any language -- I've only helped design and implement one but it was a TP glue language (STDL) that included interdependencies with COBOL, C, and SQL -- that there are inevitable tradeoffs depending on what you're fundamentally trying to achieve. The reason we designed STDL was to handle TP specific operations that were not standardized across those languages, but of course we didn't want to reinvent COBOL and C and SQL, either. 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. 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. 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 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. 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. Eric --- Gregg Wonderly <[EMAIL PROTECTED]> wrote: > William Henry wrote: > > Our difference is that I am assuming that I won't > throw away existing > > IT assets and rewrite them in Java and if we can > leverage non-Java > > mission critical assets naturally why add the > layer of Java? Whereas > > you seem to be making the assumption that > rewriting them or wrapping > > them in Java is a most desirable. > > I know that fighting the integration battle by > continuing with a diverse > language set is painful. Wrapping legacy apps with > web services interfaces is > no different than wrapping them with a Jini wrapper. > The upside is that the > transport layer would be plugable and could be multi > faced. Jini's Exporter > facilities would allow you to export a service with > WS-* and native JERI > supported interfaces. This would give you the > flexability to use the most > effective interface for your application. If you > just do it with WS-*, then > everything has to speak WS. This forces you to > standardize on a single > transport interface which can be a limitation in and > of itself. The choices > available with JERIs plugable transport empower you > to make the best choice of > transports that meets your needs. > > > Having built your own proprietary brokers etc. is > a luxury - (but > > proprietary ... unless you now have conformed to > the specs). > > My broker, because it uses a lightweight, native > java ESB, can have any type of > external interface plugged in. I have JMS in/out, a > private XML socket stream > inbound, and JDBC out plus several other vendor > specific inputs. By not driving > the core with a standard that has limits, I have the > flexibility to plug in > whatever I need. That's an architectural advantage > that just using WS doesn't > support. > > > They turn to the elusive "best > > practices" for better guidelines. and just when > they are about to > > "get it" a new Hello World demo from a new > technology come on the > > scene to solve their problem and start the cycle > again. But to assume > > that the Java specs are any less complicated than > the CORBA or even > > the WS- specs ..... ? > > Absolutely the Jini spec is less complicated! It's > perhaps more technically > oriented (distributed systems problems are not > simple to solve). This might > make you feel complication. I consider complication > to be measured by lack of > flexibility and lack of features that make doing > some things decidedly difficult > if not impossible. > > Having well defined behaviors with well defined > programmatic interfaces makes > things a lot less complicated. > > Learning something new can feel like complication. > But, I think it's decidedly > shortsited to place training at the front of your > decision tree. > > > All I'm saying is this: Way to go Java! When you > need to build > > something new and Java fits the need then use it. > But let's not > > assume it will work in all cases and let's not > force in in places where > > it's neither needed or wanted. > > I would only argue that limiting your choices to > "something new" is only > complicating your SOA. By having multiple > languages/platforms visible to the > overall SOA, you are going to always demand using > the most commonly available > transport/interchange/messaging system. Standards > might be in place to make > this seem easy. But, if those standards complicate > your design, or impact your > inter-system latency, performance and evolution > choices, then they may not have > provided you with the "feature" that you needed. > > There are infinite choices, making the right choice > is important. Standards > aren't always the best choice, and often provide > more value to the implementors > selling implementations than to the users. > > I'm not saying the WS is not valuable. I'm only > saying that it is a choice, and > applying it to the backbone of an inhouse SOA > doesn't make sense across the > board. WS can provide an inter-business backbone. > But making it the only > choice will limit choices and increase your > dependencies on 3rd party software > that you can't tune or adjust as needed. > > 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/
