|
From: David W. \(XML\) <da...@dr...> - 2005-08-03 02:25:39
|
Robert, Good catch. On the certification front. I've done the Drummond testing with a = commercial product. I would venture that if Hermes can freely interchange with the target = server (say Cyclone - which BTW has probably the most complete = implementation) - that is exactly like completing the Drummond testing = anyway. Of course Drummond makes you perform a range of tests with four or more = other vendors - but you can easily verify that Hermes matches those = needs. BTW - the CPA handling in current Hermes is not all it should be. My = understanding that is being enhanced - along the lines we did in the = code here - http://ebxmlbook.com/interop/=20 All this is about verifying the operation. For example - Oracle now has = a ebMS compatible server to for iHub - but its not "certified" - and = I'll wager that your management would happily use it, eh? Hope that helps your decision making. Thanks, DW ----- Original Message -----=20 From: Robert A. Stockfleth=20 To: ebx...@li...=20 Sent: Tuesday, August 02, 2005 6:05 PM Subject: [ebxmlms-general] RE: SSLHandshakeException (SSL PROBLEM) A few weeks ago I figured out where my SSL Handshake problem is coming = from. =20 It seems that by default Hermes uses the HttpsURLConnection class to = connect (when you're accessing a HTTPS URL). =20 I rewrote the SSL connection portion of Http.java to use the Socket = class instead of the HttpsURLConnection class. When I connected using = the exact same keystore - the handshaking process worked properly. =20 It seems like something inside the HttpsURLConnection class was not = compatible with the Cyclone server, my private key or both. =20 Anyone have any ideas (that don't involve hacking the source apart)?? =20 PS Any chance future versions of Hermes will undergo Drummond's = "EBXML" certification. Many large companies will not allow outside = vendors to connect, unless they are using an officially EBXML certified = application. =20 |