javax.jbi.messaging.MessagingException: More than one operation defined
Hi,
i had already implemented a web service consisting of 6 methods that works fine. Now i want to access this service via JBI. Therefore i developed a service assembly containing only of a soap binding component. When i try to access the jbi environment via the inbound endpoint OpenESB throws following exception:
[#|2006-07-26T16:23:50.531+0200|WARNING|sun-appserver-pe9.0|com.sun.jbi.component.com.sun.httpsoapbc-1.0-2com.sun.jbi.httpsoapbc.embedded.GrizzlyRequestProcessor|_ThreadID=32;_ThreadName=httpWorkerThread-12010-2;_RequestID=a33dbb24-d088-4a6a-9642-96187c32bb36;|Exception in processing request.
javax.jbi.messaging.MessagingException: More than one operation defined. Unable to resolve operation: {http://service}UseRepositoryService,UseRepository,inbound
at com.sun.jbi.httpsoapbc.InboundMessageProcessor.execute(InboundMessageProcessor.java:214)
at com.sun.jbi.httpsoapbc.embedded.GrizzlyRequestProcessor.processAsynchRequest(GrizzlyRequestProcessor.java:214)
at com.sun.jbi.httpsoapbc.embedded.GrizzlyRequestProcessor.service(GrizzlyRequestProcessor.java:173)
at com.sun.enterprise.web.connector.grizzly.ProcessorTask.invokeAdapter(ProcessorTask.java:667)
at com.sun.jbi.httpsoapbc.embedded.JBIGrizzlyAsyncFilter.doFilter(JBIGrizzlyAsyncFilter.java:70)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.invokeFilters(DefaultAsyncExecutor.java:143)
at com.sun.enterprise.web.connector.grizzly.async.DefaultAsyncExecutor.interrupt(DefaultAsyncExecutor.java:132)
at com.sun.enterprise.web.connector.grizzly.async.AsyncProcessorTask.doTask(AsyncProcessorTask.java:81)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
How can i specify in my service assembly that if i send a SOAP request for method X on my client that OpenESB routes this message to the correct Outbound endpoint?
Thank you
Thomas
Hello Thomas,
If possible it would help to see the WSDL.
It is possible for example that the BC is not able to uniquely identify which operation is meant if the binding is document/literal and more than one operation uses the same message or messages which can not be distinguished on the wire.
The BC does have an enhancement on top of the WS-I BP handling in that it will fall back onto matching on the soapaction if available; that is, it will see if the soapactions are unique amongst those candidate operations ?and whether the soapaction sent by the client matches one of them.
But if neither the wire signature nor the soapaction can disambiguate the request it could return the fault shown.
Andi
Hi Andi,
thanks for your answer. I am posting a part of the wsdl now:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://service" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://service" xmlns:intf="http://service" xmlns:tns1="http://types" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.2.1
Built on Jun 14, 2005 (09:15:57 EDT)-->
<wsdl:types>
<!-- types -->
</wsdl:types>
<!-- messages -->
<wsdl:message name="getAllInstancesFromDBResponse">
<wsdl:part element="impl:getAllInstancesFromDBResponse" name="parameters"/>
</wsdl:message>
<wsdl:message name="saveInstanceRequest">
<wsdl:part element="impl:saveInstance" name="parameters"/>
</wsdl:message>
<wsdl:portType name="UseRepository">
<! -- .............-->
<wsdl:operation name="saveInstance">
<wsdl:input message="impl:saveInstanceRequest" name="saveInstanceRequest"/>
<wsdl:output message="impl:saveInstanceResponse" name="saveInstanceResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="UseRepositorySoapBinding" type="impl:UseRepository">
<!-- additional operations >
<wsdl:operation name="saveInstance">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="saveInstanceRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="saveInstanceResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="UseRepositoryService">
<wsdl:port binding="impl:UseRepositorySoapBinding" name="UseRepository">
<wsdlsoap:address location="http://localhost:12010/service/repository"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
How can i solve this problem? Shall I specify for every method a soap action? Does the wsdl from the outbound endpoints need also this soapaction?
Thanks
Thomas
Thanks Thomas, I had a look at the WSDL excerpt.
I couldn't tell from the snippet whether there are other operations defined in the porttype which use the same input message "saveInstanceRequest" - it also doesn't show if you're using document style or rpc.
If there are no other methods that use the same message, we're looking at a different issue than what I described - and soapaction won't help.
I'll assume for now that you have no other operations in that WSDL that use the same input message.
If I understand the set-up you are trying to achieve correctly, you are not just trying to invoke the webservice from JBI, but also would like JBI to essentially publish a "proxy" for this same webservice. Right now the HTTP BC doesn't support use as a pure proxy; although that enhancement is planned.
What you could do for now to achieve this effect is use for example the BPEL engine to invoke your service; and expose that BP as a webservice.
Andi
The soapaction solution would only apply in the case where
Hello Andi,
thanks for your reply. To exclude the soap action error i will post the complete wsdl file now. But in my opinion every operation has its own input and output definition.
The consumer wsdl:
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://service" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://service" xmlns:intf="http://service" xmlns:tns1="http://types" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!--WSDL created by Apache Axis version: 1.2.1
Built on Jun 14, 2005 (09:15:57 EDT)-->
<wsdl:types>
<schema elementFormDefault="qualified" targetNamespace="http://service" xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://types"/>
<element name="loadEcore">
<complexType>
<sequence>
<element name="ecoreId" type="xsd:long"/>
</sequence>a
</complexType>
</element>
<element name="loadEcoreResponse">
<complexType>
<sequence>
<element name="loadEcoreReturn" type="xsd:base64Binary"/>
</sequence>
</complexType>
</element>
<element name="loadInstance">
<complexType>
<sequence>
<element name="instanceId" type="xsd:long"/>
</sequence>
</complexType>
</element>
<element name="loadInstanceResponse">
<complexType>
<sequence>
<element name="loadInstanceReturn" type="xsd:base64Binary"/>
</sequence>
</complexType>
</element>
<element name="loadInstanceForProject">
<complexType>
<sequence>
<element name="instanceId" type="xsd:long"/>
</sequence>
</complexType>
</element>
<element name="loadInstanceForProjectResponse">
<complexType>
<sequence>
<element name="loadInstanceForProjectReturn" type="xsd:base64Binary"/>
</sequence>
</complexType>
</element>
<element name="deleteInstance">
<complexType>
<sequence>
<element name="instanceId" type="xsd:long"/>
</sequence>
</complexType>
</element>
<element name="deleteInstanceResponse">
<complexType>
<sequence>
<element name="deleteInstanceReturn" type="xsd:boolean"/>
</sequence>
</complexType>
</element>
<element name="getAllInstancesFromDB">
<complexType/>
</element>
<element name="getAllInstancesFromDBResponse">
<complexType>
<sequence>
<element maxOccurs="unbounded" name="getAllInstancesFromDBReturn" type="tns1:InstancePackageValueBean"/>
</sequence>
</complexType>
</element>
<element name="saveInstance">
<complexType>
<sequence>
<element name="resourceBytes" type="xsd:base64Binary"/>
<element name="fileName" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="saveInstanceResponse">
<complexType>
<sequence>
<element name="saveInstanceReturn" type="xsd:boolean"/>
</sequence>
</complexType>
</element>
</schema>
<schema elementFormDefault="qualified" targetNamespace="http://types" xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="InstancePackageValueBean">
<sequence>
<element name="ecoreId" type="xsd:long"/>
<element name="fileName" nillable="true" type="xsd:string"/>
<element name="id" type="xsd:long"/>
<element name="name" nillable="true" type="xsd:string"/>
<element name="usedModels" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</schema>
</wsdl:types>
<wsdl:message name="loadEcoreRequest">
<wsdl:part element="impl:loadEcore" name="parameters"/>
</wsdl:message>
<wsdl:message name="loadEcoreResponse">
<wsdl:part element="impl:loadEcoreResponse" name="parameters"/>
</wsdl:message>
<wsdl:message name="saveInstanceResponse">
<wsdl:part element="impl:saveInstanceResponse" name="parameters"/>
</wsdl:message>
<wsdl:message name="loadInstanceForProjectResponse">
<wsdl:part element="impl:loadInstanceForProjectResponse" name="parameters"/>
</wsdl:message>
<wsdl:message name="loadInstanceResponse">
<wsdl:part element="impl:loadInstanceResponse" name="parameters"/>
</wsdl:message>
<wsdl:message name="getAllInstancesFromDBRequest">
<wsdl:part element="impl:getAllInstancesFromDB" name="parameters"/>
</wsdl:message>
<wsdl:message name="loadInstanceRequest">
<wsdl:part element="impl:loadInstance" name="parameters"/>
</wsdl:message>
<wsdl:message name="getAllInstancesFromDBResponse">
<wsdl:part element="impl:getAllInstancesFromDBResponse" name="parameters"/>
</wsdl:message>
<wsdl:message name="loadInstanceForProjectRequest">
<wsdl:part element="impl:loadInstanceForProject" name="parameters"/>
</wsdl:message>
<wsdl:message name="saveInstanceRequest">
<wsdl:part element="impl:saveInstance" name="parameters"/>
</wsdl:message>
<wsdl:message name="deleteInstanceRequest">
<wsdl:part element="impl:deleteInstance" name="parameters"/>
</wsdl:message>
<wsdl:message name="deleteInstanceResponse">
<wsdl:part element="impl:deleteInstanceResponse" name="parameters"/>
</wsdl:message>
<wsdl:portType name="UseRepository">
<wsdl:operation name="loadEcore">
<wsdl:input message="impl:loadEcoreRequest" name="loadEcoreRequest"/>
<wsdl:output message="impl:loadEcoreResponse" name="loadEcoreResponse"/>
</wsdl:operation>
<wsdl:operation name="loadInstance">
<wsdl:input message="impl:loadInstanceRequest" name="loadInstanceRequest"/>
<wsdl:output message="impl:loadInstanceResponse" name="loadInstanceResponse"/>
</wsdl:operation>
<wsdl:operation name="loadInstanceForProject">
<wsdl:input message="impl:loadInstanceForProjectRequest" name="loadInstanceForProjectRequest"/>
<wsdl:output message="impl:loadInstanceForProjectResponse" name="loadInstanceForProjectResponse"/>
</wsdl:operation>
<wsdl:operation name="deleteInstance">
<wsdl:input message="impl:deleteInstanceRequest" name="deleteInstanceRequest"/>
<wsdl:output message="impl:deleteInstanceResponse" name="deleteInstanceResponse"/>
</wsdl:operation>
<wsdl:operation name="getAllInstancesFromDB">
<wsdl:input message="impl:getAllInstancesFromDBRequest" name="getAllInstancesFromDBRequest"/>
<wsdl:output message="impl:getAllInstancesFromDBResponse" name="getAllInstancesFromDBResponse"/>
</wsdl:operation>
<wsdl:operation name="saveInstance">
<wsdl:input message="impl:saveInstanceRequest" name="saveInstanceRequest"/>
<wsdl:output message="impl:saveInstanceResponse" name="saveInstanceResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="UseRepositorySoapBinding" type="impl:UseRepository">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="loadEcore">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="loadEcoreRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="loadEcoreResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="loadInstance">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="loadInstanceRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="loadInstanceResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="loadInstanceForProject">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="loadInstanceForProjectRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="loadInstanceForProjectResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="deleteInstance">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="deleteInstanceRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="deleteInstanceResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="getAllInstancesFromDB">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getAllInstancesFromDBRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="getAllInstancesFromDBResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="saveInstance">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="saveInstanceRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="saveInstanceResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="UseRepositoryService">
<wsdl:port binding="impl:UseRepositorySoapBinding" name="UseRepository">
<wsdlsoap:address location="http://localhost:12010/service/repository"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Except for the service name, port, address etc the provider wsdl is the same.
Could you tell me if it works when i will only use one operation for example?
I had already implemented a service assembly which contained only one operation. That SA worked fine.
If the Service Assembly and Binding Component descriptors had wrong references e.g. the wrong interface-name, would OpenESB throws an exception while deployment?
In addition, could you tell me a good link to a nice bpel engine example? How is the interaction between client ans service using the bpel engine?
I think using the SoapBC the interaction is following:
Client --> BC --> Service
With Bpel engine?
Client --> BC --> bpel --> BC2 --> service?
Thanks a lot
Thomas
Okay, the WSDL looks fine to me; it should not result in ambiguous wire signatures. So the question remains - why was it not able to identify the operation.
It is possible that the SOAP message received does not match what the BC expects to see on the wire (given the WSDL) for some reason. What are you using as the client? You might want to see what the http request looks like; if you can post it I can also have a look. Using a soapaction (in the WSDL and the HTTP request) may help the BC to match an operation, but depending on the reason for the failure to match on the message for that operation that really would just be a band-aid - i.e. it might then report a failure in processing that message.
I probably should also qualify my statement in regards to use as a 'proxy'; as long as your service/port names are different as you described for provider and consumer you should be able to achieve what you're trying to do; having one or multiple operations should not affect this.
OpenESB will ensure that the SA/SU descriptors are valid according to the spec (i.e.report a failure during deployment); the remaining SU contents is like a black box to it though and the component (e.g. the BC) will validate those artifacts such as the WSDL and also report failures if found.
The fact that it is listening on that port / context in your soap address also shows that the BC has matched the information in the descriptor to the corresponding WSDL port and is servicing it. Obviously if you do find a condition where an invalid condition isn't reported please file a bug.
What can also help in creating the SAs/SUs is to use the enterprise pack; which will make it easier to validate / build valid artifacts.
In regards to BPEL, you could have a look at this article
http://java.sun.com/developer/technicalArticles/WebServices/soa3/
which also comes with videos and project artifacts
(http://java.sun.com/developer/technicalArticles/WebServices/soa3/
loanProcessing.zip)
Right, if I understand your scenario correctly if you were to use BPEL in this case it would look something like this
client -> HTTP BC -> BPEL SE -> HTTP BC -> external webservice
Obviously the BPEL can orchestrate webservices in whatever way you define - and can receive one or multiple messages at the points you define; but in this simplistic case you would mostly just define a receive and invoke.
Andi
Hi andi,
my soap request looks like this:
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:q0="http://service" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<q0:deleteInstance>
<q0:instanceId>1</q0:instanceId>
</q0:deleteInstance>
</soapenv:Body>
</soapenv:Envelope>
If you need more information i can plug-in a TCP monitor.
At the moment i use the Web Service Explorer from the Eclipse WTP. If the scenario should work i will create stubs using axis.
In the meantime i tried to change the consumer wsdl so that behind every port is only one operation. Therefore i added 6 connections to the service assemblies jbi.xml. In addition, the endpoint.xml of my BC has now 6 portmaps that direction is inbound. The jbi.xml of the BC has also 6 consumues tags. But if i try to access NMR i get also an exception. I post the stacktrace at the end of this message.
I think that i should start working with the bpel engine. My Service has still 6 methods. How do i define the SOAP BC for my client? If it consumes again the wsdl that "throws the messaging exception: More than one operation defined" i can磘 see a progress.
Thanks a lot
Thomas
-
StackTrace:
[#|2006-07-28T15:27:44.140+0200|WARNING|sun-appserver-pe9.0|com.sun.jbi.component.com.sun.httpsoapbc-1.0-2com.sun.jbi.httpsoapbc.embedded.GrizzlyRequestProcessor|_ThreadID=23;_ThreadName=pool-1-thread-5;_RequestID=30bcdca1-bb2e-45ad-ba8f-830ee72fce73;|Exception in processing reply
javax.jbi.messaging.MessagingException: Failed to denormalize input.
at com.sun.jbi.httpsoapbc.servletsupport.HttpServletDenormalizer.denormalize(HttpServletDenormalizer.java:120)
at com.sun.jbi.httpsoapbc.embedded.GrizzlyRequestProcessor.processAsynchReply(GrizzlyRequestProcessor.java:448)
at com.sun.jbi.httpsoapbc.embedded.GrizzlyRequestProcessor.onReply(GrizzlyRequestProcessor.java:252)
at com.sun.jbi.httpsoapbc.MessageExchangeSupport.notifyOfReply(MessageExchangeSupport.java:80)
at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processRequestReplyInbound(OutboundMessageProcessor.java:166)
at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processMessage(OutboundMessageProcessor.java:135)
at com.sun.jbi.httpsoapbc.OutboundAction.run(OutboundAction.java:37)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
at com.sun.jbi.httpsoapbc.util.Util.messageAsDom(Util.java:28)
at com.sun.jbi.httpsoapbc.SoapDenormalizer.denormalize(SoapDenormalizer.java:103)
at com.sun.jbi.httpsoapbc.servletsupport.HttpServletDenormalizer.denormalize(HttpServletDenormalizer.java:94)
... 9 more
|#]
[#|2006-07-28T15:27:44.171+0200|SEVERE|sun-appserver-pe9.0|com.sun.jbi.component.com.sun.httpsoapbc-1.0-2com.sun.jbi.httpsoapbc.OutboundAction|_ThreadID=24;_ThreadName=pool-1-thread-6;_RequestID=7aa3df7c-032d-4cb7-b826-568587066844;|Unexpected exception in processing outbound message
java.lang.NullPointerException
at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processRequestReplyOutbound(OutboundMessageProcessor.java:238)
at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processMessage(OutboundMessageProcessor.java:137)
at com.sun.jbi.httpsoapbc.OutboundAction.run(OutboundAction.java:37)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
|#]
In regards to the failure in normalizing, I think you have hit the current limitation of not supporting usa as a "pure" proxy after all. You could either use two BC instances of the HTTP BC and service the inbound/outbound WSDLs separately, or use the BPEL SE to orchestrate your scenario..
This is separate from the issue of it matching up the operation though. From a preliminary look at your request that looks ok, so I now suspect some kind of bug. I know there are test cases for this particular scenario, so something must be slightly different in your scneario that gets it in trouble. I'll see if I can reproduce your issue.
For now you can either use the approach you mentioned; using an operation per port - or there are other options like using soapaction, or for example using rpc style on your inbound.
andi
Hello,
i needed some days to get familiar with the bpel engine. The bpel engine deployed in my service assembly receives the client request and executes the bpel script. The script describes following workflow:
--> receive client request
--> copy data
--> invoke service
--> copy data
--> reply to client
If the script reaches the invoke tag the bpel engine throws following exception:
[#|2006-08-01T16:07:12.843+0200|SEVERE|sun-appserver-pe9.0|com.sun.jbi.component.com.sun.bpelse-1.0-2com.sun.jbi.engine.bpel.core.bpms.bpelImpl.runtime.BPELInterpreter|_ThreadID=22;_ThreadName=Thread-74;_RequestID=6ddbd400-91cb-4c9a-b4ab-cd00caed38be;|Unknown exception occured while executing a business process instance.
java.lang.NullPointerException
at com.sun.jbi.engine.bpel.core.bpel.model.runtime.impl.InvokeUnitImpl.process(InvokeUnitImpl.java:165)
at com.sun.jbi.engine.bpel.core.bpel.model.runtime.impl.InvokeUnitImpl.doAction(InvokeUnitImpl.java:75)
at com.sun.jbi.engine.bpel.core.bpms.bpelImpl.runtime.BPELInterpreter.interpret1(BPELInterpreter.java:794)
at com.sun.jbi.engine.bpel.core.bpel.engine.impl.BPELProcessManagerImpl.process(BPELProcessManagerImpl.java:688)
at com.sun.jbi.engine.bpel.core.bpel.engine.impl.EngineImpl.process(EngineImpl.java:207)
at com.sun.jbi.engine.bpel.core.bpel.engine.impl.EngineImpl.process(EngineImpl.java:546)
at com.sun.jbi.engine.bpel.core.bpel.engine.impl.EngineImpl.processResponse(EngineImpl.java:195)
at com.sun.jbi.engine.bpel.BPELSEInOutThread.processResponse(BPELSEInOutThread.java:500)
at com.sun.jbi.engine.bpel.BPELSEInOutThread.run(BPELSEInOutThread.java:220)
|#]
[#|2006-08-01T16:07:12.859+0200|WARNING|sun-appserver-pe9.0|com.sun.wsdl.model.common.model.impl.XMLElementImpl|_ThreadID=22;_ThreadName=Thread-74;_RequestID=6ddbd400-91cb-4c9a-b4ab-cd00caed38be;|Associate element with owner XML document first!|#]
[#|2006-08-01T16:07:12.859+0200|SEVERE|sun-appserver-pe9.0|com.sun.jbi.component.com.sun.bpelse-1.0-2com.sun.jbi.engine.bpel.core.bpms.bpelImpl.util.DOMHelper|_ThreadID=22;_ThreadName=Thread-74;_RequestID=6ddbd400-91cb-4c9a-b4ab-cd00caed38be;|failed to parse the file BPELRuntimeException: faultCode=OTHER_ERROR: local part cannot be "null" when creating a QName|#]
[#|2006-08-01T16:07:12.875+0200|SEVERE|sun-appserver-pe9.0|com.sun.jbi.component.com.sun.bpelse-1.0-2com.sun.jbi.engine.bpel.core.bpel.engine.impl.EngineImpl|_ThreadID=22;_ThreadName=Thread-74;_RequestID=6ddbd400-91cb-4c9a-b4ab-cd00caed38be;|couldn't process the event com.sun.jbi.engine.bpel.core.bpel.engine.impl.ResponseInComingEventKeyImpl@b2068ef9|#]
[#|2006-08-01T16:07:12.875+0200|SEVERE|sun-appserver-pe9.0|com.sun.jbi.component.com.sun.bpelse-1.0-2com.sun.jbi.engine.bpel.BPELSEInOutThread|_ThreadID=22;_ThreadName=Thread-74;_RequestID=6ddbd400-91cb-4c9a-b4ab-cd00caed38be;|Failed to process status of InOut - messageExchangeId: 143362050878913-5319-133737340322650026|#]
It seems that my web service is not registered within my jbi environment. Or do you have an other opinion about this exception?
The invoke:
<invoke name="InvokeRepositoryDeleteInstance" partnerLink="RepositoryImpl" operation="deleteInstance" portType="service:Repository" inputVariable="DeleteInstanceInput" outputVariable="DeleteInstanceOutput"/>
My service based on axis is deployed as war in the application server. It doesn't occur under the web service tab if i use the admin console of sun application server. Does JBI manage web service based on axis other than services that are developed with sun wsdp?
Regarding to the document (Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK) which you recommended i read (under: Role of Java EE Service Engine As a Service Provider)
When a Java EE web service is deployed, the deployment runtime of Application Server notifies the Java EE Service Engine so that an endpoint is enabled in the NMR of the JBI runtime. The notification enables any component deployed in NMR to access the Java EE web service. For example, a BPEL application running inside the BPEL engine can access the Java EE web service by sending a normalized message to the endpoint enabled by the Java EE Service Engine.
Does the term "Java EE web service" include both services developed with sun wsdp and services developed with axis?
A futher question (regarding to the loan demo) ;-):
My service assembly is similar to the loan service assembly:
--> one soap bc
--> one bpel se
In the demo the loan service assembly uses the the java ee service engine to invoke the service. In the pdf i read (putting it all together, step 4):
The first activity in the BPEL script happens to be an invocation of another
service. The BPEL SE constructs a normalized message and updates the message content with the loan request message and the message headers, with the service name urn:LoanProcessorEJB/wsdl}LoanProcessorEJB and port
LoanProcessorEJBSEIPort. This message, too, is sent on the delivery channel. The BPEL service engine has no knowledge of the provider of the service other than the service definition in the WSDL file.
Which files provides this information (urn:... & port) for the service engine? I couldn't find this information in any file.
Thank you. I really appreciate your answers and suggestions.
Thomas
From the stack and the null pointer logged, i think hat it could primarily be because DeliveryChannel couldn't send the message to the service provider. (This code is old and has been fixed too). I think the invoke was returned with a ME error.
There are other possibilities, error situations, but nothing i can think of right away.
As you point out, your SA should also be having JavaEE (i think). I haven't played with this component, so i am not sure if it does things differently. Did you install JavaEE service engine? I am assuming you are using netbeans. Did you then go to the properties of the JBI composite project and say update on the components. Then you should see 3 of them, http BC, bpel SE, java EE SE. Then generate and deploy.
You should see the service and port values in the jbi.xml.
-Kiran.
Hello,
no, i dont use netbeans (but i will install it as soon as possible). Consequently i cant create and deploy my service assembly with netbeans. I use the ESB Administration Console to see my service assemblies and components. Within this console i see that the Java EE Service Engine is started. So i think that i have installed this engine.
Now i will try the netbeans Tools Bundle.
Thank you
Thomas
Thomas,
Using netbeans is good. I use that and hence i can remember only that route of generating SA.
If there is another way of repackaging your SA outside of netbeans, maybe you want to try that out, to include Java EE. How were you packaging the SA so far. Did you happen to get that with the loan application pre-built?
-Kiran.
Hello,
i developed a simple ant script that created my Service Assembly. The deployment of the SA followed by the autodeploy folder of jbi.
Regarding to the Loan Example i only examined the dist folder of the LoanRequestorJBI project. I noticed that the Processor wsdl had an invalid soap adress location. I assume that this adress should be changed with netbeans.
Thomas
Hello,
yes, my scenario works fine. I developed the SA with the Netbeans 5.5 Beta Tool Bundle. I have a last question regarding to the soap binding component.
The quickstart demo uses the soap bc, too. Within the bc it exists a file named endpoints.xml which content looks like:
<portmaps>
<portmap direction="outbound" endPoint="soapLAFPayrollServiceEP" service="{http://www.payroll.org/payroll/wsdl}LAFPayrollService" />
<portmap direction="inbound" endPoint="soapSAFPayrollServiceEP" service="{http://www.payroll.org/payroll/wsdl}SAFPayrollService" />
</portmaps>
My solution has a portmap.wsdl. The content is:
<definitions targetNamespace="ICAN_jbi_portmap" ........ ..........>
</definitions>
In which file are these information (e.g. portmap direction="" ....) provided? Or are these information (in the endpoints.xml) redundant or rather unnecessary?
Thanks a lot!
Thomas
Thomas,
Earlier we were generating information related to the endpoint activation into the endpoint.xml for BCs and portmap.xml for SEs. That has changed to use the jbi.xml itself. I would guess you have an old project or your project system code isin't the latest. You should see these entries in the jbi.xml. portmap.wsdl is also obsolete and no longer needed.
-Kiran.
Hi Thomas, I know you're not using this anymore right now - but FYI I reproduced your original issue with the operation identification. It had trouble with the namespace prefix - which is now fixed.Thanks!Andi
Hi,
could you please indicate exactly what the trouble was and how you fixed it? I have the sampe problem using the BPEL system. Everything works fine - as soon as I define a WSDL with more than one operation, there is the problem. Unfortunately, all the blueprints only use single operation services for the BPEL system
The problem occurred with namespace prefixes in the child element of the soap body. Before the fix it worked with default namespaces set on that element, but prefixes tripped up the logic that distinguishes operations. This is not an issue for RPC style - or if unique soap action hints are provided wtih the request.
Also note that there can be valid reasons for this error when using document style messages. That is, if the wire signature of the input messages for multiple operations is not unique - and there is not unique soap action provided in the request, the BC has no way of telling which operation is meant.
I hope this helps.
