I am using XFire for my java ws stack solution and recently began using the JAXWSServiceFactory to resolve the namespace issues presented in XFIRE-582. Java to java communication through Xfire works great. However I use ZSI 2 for a Python ws solution. ZSI serializes the objects to xml including the attribute xsi:type="xsd:int" or other xml shcema types. For example: <ns1:getVersionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns1:getVersionResponse" xmlns:ns1="http://www.emergent.net/2006/servertools/processmanagement"> <ns1:version xmlns:ns2="http://www.emergent.net/2006/servertools/processmanagement/model" authors="Chris Thatcher; Stephen Couratier" build="3" component="Agent" contact="chris.thatcher@emergentgametech.com" license="http://www.emergent.com" major="1" minor="2" product="Server" subProduct="Tools/ProcessManagement" xsi:type="ns2:version"/> <ns1:genericResponseHolder xmlns:ns2="http://www.emergent.net/2006/servertools/processmanagement/model" xsi:type="ns2:genericResponse"> <ns2:responseCode xsi:type="xsd:int">1141</ns2:responseCode> <ns2:responseMessage xsi:type="xsd:string">Successfully Retreived the Versioning Information from the ProcessManagement Service Component</ns2:responseMessage> <ns2:fault xsi:type="xsd:boolean">false</ns2:fault> </ns1:genericResponseHolder> </ns1:getVersionResponse> This snippet is how the xml dom looks when logged at the 'pre-dispatch' phase of a Xfire client calling the ZSI python service. Note that the xmlns:xsd="http://www.w3.org/2001/XMLSchema" is not present. It does appear on the SOAP Envelope: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> I am assuming it is not included in the xmlns declarations in the response element because it only appears inside the attribute values, and to be frank it actually suprised me it caused any sort of error. Unfortunately it does: org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: prefix xsd is not bound to a namespace org.codehaus.xfire.fault.XFireFault: prefix xsd is not bound to a namespace at org.codehaus.xfire.fault.XFireFault.createFault(XFireFault.java:89) at org.codehaus.xfire.client.Client.onReceive(Client.java:386) at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:139) at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48) at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131) at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:75) at org.codehaus.xfire.client.Client.invoke(Client.java:335) at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77) at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57) at $Proxy60.getVersion(Unknown Source) at net.emergent.www.servertools.processmanagement.client.impl.ProcessManagementClient.getVersion(ProcessManagementClient.java:162) at net.emergent.www.servertools.processmanagement.server.EmbeddedSMSServer.confirmResources(EmbeddedSMSServer.java:193) at net.emergent.www.servertools.processmanagement.server.EmbeddedSMSServer.init(EmbeddedSMSServer.java:162) at net.emergent.www.servertools.processmanagement.server.EmbeddedSMSServer.main(EmbeddedSMSServer.java:170) Caused by: java.lang.IllegalArgumentException: prefix xsd is not bound to a namespace at com.sun.xml.bind.DatatypeConverterImpl._parseQName(DatatypeConverterImpl.java:324) at com.sun.xml.bind.v2.runtime.unmarshaller.XsiTypeLoader.parseXsiType(XsiTypeLoader.java:52) at com.sun.xml.bind.v2.runtime.unmarshaller.XsiTypeLoader.startElement(XsiTypeLoader.java:30) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:369) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:347) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:35) at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:201) at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:135) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:337) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:309) at org.codehaus.xfire.jaxb2.JaxbType.readObject(JaxbType.java:196) at org.codehaus.xfire.aegis.type.basic.HolderType.readObject(HolderType.java:43) at org.codehaus.xfire.aegis.AegisBindingProvider.readParameter(AegisBindingProvider.java:154) at org.codehaus.xfire.service.binding.AbstractBinding.read(AbstractBinding.java:206) at org.codehaus.xfire.service.binding.WrappedBinding.readMessage(WrappedBinding.java:50) at org.codehaus.xfire.jaxws.JAXWSOperationBinding.readMessage(JAXWSOperationBinding.java:149) at org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.java:42) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131) at org.codehaus.xfire.client.Client.onReceive(Client.java:382) ... 13 more I guess I'd expect to find the actual issue in SoapBodyHandler. I will look there now since this is a blocking issue for me. Thanks for any effort you can give this, I realize supporting the xsi spec probably low priority, but other services use it, and Jax-WS seems to be a stickler to the spec. XFire is an excellent product. Thanks, Thatcher