Hi!
On a similar note, there's a disconnect between the capabilities of tools created by the software industry and the requirements of the scientific community. I have just completed a particular type of Open GIS Consortium (OGC) web service called a Sensor Collection Service. The XML Schema referenced from the WSDL file comprises 54 XML Schema documents spanning 15 namespaces. Not only did the Axis bean code baulk at this but, when I had completed the project, clients found that the .NET tools couldn't handle anything like the complexity of the SCS XML Schema. Consequently, I supplied 'client software'. The originators of SOAP are conning the software world and no one seems to mind! If it's legitimate to distribute platform-independent data (XML) it must be legitimate to distribute the program logic that uses that data. If only we had a platform-independent way to deliver program logic! Forcing web service clients, as a matter of fiat, to write their own program logic is the antithesis of OOP: interfaces, inheritance, polymorphism all exits to promote reuse. Reuse is the Holy Grail of software development. It could be argued that each client has their own needs and so it's not possible to write generic client-side code. Such an argument is false. The fact that XML Schemas are used to formalise the data transmitted within SOAP envelopes means that each web service is necessarily application-specific and, as such, is tractable to low-level client code. Such code exposes data (in the form of XML, if appropriate) that can then be used in whatever way the ultimate consumer-code requires. I recently wrote a web service for the Government of Canada that provided document-literal content in the form of Web Ontology Language (OWL). Everyone was pleased with the outcome and loved the OWL implementation BUT the first thing they did was to nominate someone to write a generic client that dealt with the XML and provided the desired content through a Java component that everyone could use/reuse. Hey, that's an idea...I wonder if we could supply Java client-side code with our web services. That way, the .NET folks and all other non-Java folks could continue to do what they do and the sane software developers can get back to the preferred paradigm of using portable code. XML and Java go together. Sun and all other interested parties seem to be blind to the fact that making portable client-side code an integrated web service deliverable would make those services far more viable. Not everyone wants to get into WSDL, etc. when they could simply use a bean! SOAP and web services are infrastructure. Folks who use my web services want turnkey solutions. For them it's about access to scientific data. They want to operate at a higher level of abstraction than SOAP! Warmest regards, Jeff Cogent Logic Corporation Toronto, Canada ----- Original Message ----- From: "Galbreath, Mark A" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 14, 2004 11:22 AM Subject: RE: Project from hell? > EXACTOMUDO! :-( > > -----Original Message----- > From: Sherman, Dennis (END-CHI) [mailto:[EMAIL PROTECTED] > Sent: Friday, May 14, 2004 9:12 AM > > Your task sounds to me suspiciously like someone at an executive level > having heard about web services, and thinking they've found the silver > bullet to all their problems.
