RE: SOAP/WSDL support?
Did they do what WL 6 does and use their own packaging for the parser they depend on and let people simply interface others from whereever they please? The XMLRegistry idea seems pretty neat. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Cannon-Brookes Sent: Tuesday, May 01, 2001 7:30 PM To: Orion-Interest Subject: RE: SOAP/WSDL support? Kevin, Orion 1.4.8 supports JAXP 1.1 and removes the need for Xerces. (It updates to the latest Xalan, and also uses Crimson). Not sure how this affects your ApacheSOAP stuff (sounds interesting - any URLs to read up?) -mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Wednesday, May 02, 2001 11:59 AM To: Orion-Interest Subject: SOAP/WSDL support? Hey all, I am wondering why it is Orion still uses an old version of xerces.jar and such. There are a number of new things that I can't do with their shipping version of xerces.jar. Anyways, I think (if the Orion team reads this), that adding support for SOAP using ApacheSOAP would be a great feature. Having built in support for running SOAP services (with examples of writing a service, as well as a client to access that service) would be a very good thing.
RE: SOAP/WSDL support?
Gottabe xerxes. After their victory in the W3C, IBM borged XML4J and handed the dregs to Apache. Xerxes is required. Apache doesn't know from Crimson or JAXP (although the XP model leapfrogs SOAP for Java, as per the comments in JSR101). Right now, if you want ApacheSOAP, you gotta break Orion's optimization. From the ApacheSOAP page: Apache-SOAP requires Apache Xerces (Java) version 1.1.2 or later. These versions support the DOM level 2 candidate recommendation which provides namespace support. If you have any other XML parsers (or other JAR files which may have the org.w3c.dom.* interfaces), then it is very important that you place the JAR file xerces.jar from Xerces at the front of your classpath. Apache-SOAP will not work otherwise. and: While it is possible to use another parser, the current codebase does not support making this change conveniently; hence the mechanism is not documented here. The link is here: http://xml.apache.org/websrc/cvsweb.cgi/~checkout~/xml-soap/java/docs/instal l/index.html (hope that wraps properly.) My experiences with SOAP on WebSphere, JRun, Oracle and the BEAst, is that its like a side of beef followed by a pound of bacon, followed by a quadruple-decker banana split without the fruit, washed down with a gallon of buttermilk: it may sound appetizing, byut in the long run, it just serves to clog things up. (joke folks, for the humor impaired). It's big, fat, slow and UGLY. With JAXP/Crimson and the various XSLT implementations, as well as JMS and JAXM (WG/JSR 67) and XML-RPC (WG/JSR 101) as well as JSR 102 (JDOM 1.0), JSR 104 (XML TRUST) and JSR/WG 95 (J2EE Services for Extended Transactions), we get FAR MORE than the W3C gave us. Keep in mind (in becomes clearer when you analyze the Executive Committee voting records) that SOAP is seen by the WAS vendors as an 'additional service' for which they can charge a lot of additional money. For IBM, it will be MQSeries, for the BEAst, more connectors, and for Oracle, well that will further their drive to 'increase prfits and improve margins (sic).' XML-RPC is the way to go, not SOAP. SOAP is simply what pieces of XML-RPC Microsoft let us have. They lost in court and they're back to their old 'embrace-extend-extinguish' tricks, this time cheered on by their former rivals, who see nothing but bigger margins. Which would you rather have. Pieces of proprietary classes, or the whole schmeer as a true Java API? Or, to put it in the words of Dave Winer, (the creator of XML-RPC and co-creator of SOAP) candidly at a Web conference before Microsoft fully suborned him: SOAP is for dopes. Now, here's the Java way for J2EE, from the Blueprint: http://java.sun.com/features/2001/02/xmlj2ee.html and more: http://developer.java.sun.com/developer/onlineTraining/protocolhandlers/ (watch that wrap, again) and, finally, the WAS vendors, in all their nastiness: http://java.sun.com/aboutJava/communityprocess/vote/jsr/jsr_101.html Looking at the Apoache Project's XML pages, though, looks like the pressure is on Sun to knuckle under, or Apache's gonna take it's ball and go home: The Crimson codebase is based on the Sun Project X parser. It is also the parser currently shipping in Sun products; however, the future plan is to move to a different codebase called Xerces Java 2. Xerces 2 is currently under development. [Link to Xerces 2, once a project page has been created.] from: http://xml.apache.org/crimson/ If I got a vote (which none of us do) it would be to wait and follow the JCS and spend the time optimizing Orion for EJB and JSP and servlets and XHTML DOM. FASTER, smaller, better. For those that want all of the functions of Apache/Tomcat with all of its stability and speed (heheheheheh), use that, or follow the directions above to implement Xerxes and SOAP for JRun. It should work for 1.4.7 and 1.4.8. Speed is good. Simple is better. Both are best. Go Magnus and Karl. dedmike mailto: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Cannon-Brookes Sent: Tuesday, May 01, 2001 9:30 PM To: Orion-Interest Subject: RE: SOAP/WSDL support? Kevin, Orion 1.4.8 supports JAXP 1.1 and removes the need for Xerces. (It updates to the latest Xalan, and also uses Crimson). Not sure how this affects your ApacheSOAP stuff (sounds interesting - any URLs to read up?) -mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Wednesday, May 02, 2001 11:59 AM To: Orion-Interest Subject: SOAP/WSDL support? Hey all, I am wondering why it is Orion still uses an old version of xerces.jar and such. There are a number of new things that I can't do with their shipping version of xerces.jar. Anyways, I think (if the Orion team reads this), that adding support for SOAP using ApacheSOAP would be a great feature. Having built in support for running SOAP services
RE: SOAP/WSDL support?
If you want SOAP it is no big deal. You just need a SOAP client. Also who needs to write a web service when you can just use the EJB directly via SOAP. Works great. MS may have thought up something worth while. I don't know why you need to break Orion's optimization. -Original Message- From: Michael J. Cannon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 02, 2001 3:06 AM To: Orion-Interest Subject: RE: SOAP/WSDL support? Gottabe xerxes. After their victory in the W3C, IBM borged XML4J and handed the dregs to Apache. Xerxes is required. Apache doesn't know from Crimson or JAXP (although the XP model leapfrogs SOAP for Java, as per the comments in JSR101). Right now, if you want ApacheSOAP, you gotta break Orion's optimization. From the ApacheSOAP page: Apache-SOAP requires Apache Xerces (Java) version 1.1.2 or later. These versions support the DOM level 2 candidate recommendation which provides namespace support. If you have any other XML parsers (or other JAR files which may have the org.w3c.dom.* interfaces), then it is very important that you place the JAR file xerces.jar from Xerces at the front of your classpath. Apache-SOAP will not work otherwise. and: While it is possible to use another parser, the current codebase does not support making this change conveniently; hence the mechanism is not documented here. The link is here: http://xml.apache.org/websrc/cvsweb.cgi/~checkout~/xml-soap/java/docs/instal l/index.html (hope that wraps properly.) My experiences with SOAP on WebSphere, JRun, Oracle and the BEAst, is that its like a side of beef followed by a pound of bacon, followed by a quadruple-decker banana split without the fruit, washed down with a gallon of buttermilk: it may sound appetizing, byut in the long run, it just serves to clog things up. (joke folks, for the humor impaired). It's big, fat, slow and UGLY. With JAXP/Crimson and the various XSLT implementations, as well as JMS and JAXM (WG/JSR 67) and XML-RPC (WG/JSR 101) as well as JSR 102 (JDOM 1.0), JSR 104 (XML TRUST) and JSR/WG 95 (J2EE Services for Extended Transactions), we get FAR MORE than the W3C gave us. Keep in mind (in becomes clearer when you analyze the Executive Committee voting records) that SOAP is seen by the WAS vendors as an 'additional service' for which they can charge a lot of additional money. For IBM, it will be MQSeries, for the BEAst, more connectors, and for Oracle, well that will further their drive to 'increase prfits and improve margins (sic).' XML-RPC is the way to go, not SOAP. SOAP is simply what pieces of XML-RPC Microsoft let us have. They lost in court and they're back to their old 'embrace-extend-extinguish' tricks, this time cheered on by their former rivals, who see nothing but bigger margins. Which would you rather have. Pieces of proprietary classes, or the whole schmeer as a true Java API? Or, to put it in the words of Dave Winer, (the creator of XML-RPC and co-creator of SOAP) candidly at a Web conference before Microsoft fully suborned him: SOAP is for dopes. Now, here's the Java way for J2EE, from the Blueprint: http://java.sun.com/features/2001/02/xmlj2ee.html and more: http://developer.java.sun.com/developer/onlineTraining/protocolhandlers/ (watch that wrap, again) and, finally, the WAS vendors, in all their nastiness: http://java.sun.com/aboutJava/communityprocess/vote/jsr/jsr_101.html Looking at the Apoache Project's XML pages, though, looks like the pressure is on Sun to knuckle under, or Apache's gonna take it's ball and go home: The Crimson codebase is based on the Sun Project X parser. It is also the parser currently shipping in Sun products; however, the future plan is to move to a different codebase called Xerces Java 2. Xerces 2 is currently under development. [Link to Xerces 2, once a project page has been created.] from: http://xml.apache.org/crimson/ If I got a vote (which none of us do) it would be to wait and follow the JCS and spend the time optimizing Orion for EJB and JSP and servlets and XHTML DOM. FASTER, smaller, better. For those that want all of the functions of Apache/Tomcat with all of its stability and speed (heheheheheh), use that, or follow the directions above to implement Xerxes and SOAP for JRun. It should work for 1.4.7 and 1.4.8. Speed is good. Simple is better. Both are best. Go Magnus and Karl. dedmike mailto: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Cannon-Brookes Sent: Tuesday, May 01, 2001 9:30 PM To: Orion-Interest Subject: RE: SOAP/WSDL support? Kevin, Orion 1.4.8 supports JAXP 1.1 and removes the need for Xerces. (It updates to the latest Xalan, and also uses Crimson). Not sure how this affects your ApacheSOAP stuff (sounds interesting - any URLs to read up?) -mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Wednesday, May 02, 2001 11:59
RE: SOAP/WSDL support?
Kevin, Orion 1.4.8 supports JAXP 1.1 and removes the need for Xerces. (It updates to the latest Xalan, and also uses Crimson). Not sure how this affects your ApacheSOAP stuff (sounds interesting - any URLs to read up?) -mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin Sent: Wednesday, May 02, 2001 11:59 AM To: Orion-Interest Subject: SOAP/WSDL support? Hey all, I am wondering why it is Orion still uses an old version of xerces.jar and such. There are a number of new things that I can't do with their shipping version of xerces.jar. Anyways, I think (if the Orion team reads this), that adding support for SOAP using ApacheSOAP would be a great feature. Having built in support for running SOAP services (with examples of writing a service, as well as a client to access that service) would be a very good thing.
