The calculator example had a SCA Composite external Web Service interface bottom-up generated on the Calculator interface class. I don’t want to take part at the religious war on the usage of the top-down (also called contract-first) versus the bottom-up (contract-last) Web Service generation approach. I personally prefer the "contract first" approach, because of interoperability and the control on „data types“ (avoid „type inflation“). But I don‘t damn bottom-up Web Services. It always depends on the intended usage scenario.
The following describes the top-down Web Service interface approach for Spring Beans used on the Oracle SOA Suite 11g in a step-by-step approach. I assume that you have installed the “Oracle SOA Composite Editor” and “Spring & Oracle WebLogic SCA” extension on Oracle JDeveloper. Furthermore I will not repeat the creation of the SCA Components for the AddService, SubtractService, MultiplyService and DivideService services from the last blog example. Keep the already developed CalculatorServiceComponent with the Calculator Components wiring. The CalculatorServiceBeanDef.xml should have no sca:service element and the CalculatorServiceComponent.componentType file has only reference elements.
After setting the start position the first step is the creation the WSDL file. The WSDL file keeps the schema declaration for the WSDL messages and defines the Port Type operations. Only the devide operation has an additional fault message in order to provide a SOAP Fault on a division by zero exception.
Drag and drop a Web Service Adapter from the Component Palette on the Exposed Services swim lane of the SCA Composite canvas. A Web Service interface for the SCA Composite is generated and the Web Service wizard is asking for the name and WSDL URL.
Name the Web Service Adapter CalculatorService and search for the new created Calculator WSDL file (Calculator.wsdl). Because we have only one Port Type the ICalculatorService Port Type is pre-selected. On this example we do not care about the Transaction Participation (default is NEVER).
Wire the WS Adapter with the Calculator Service Spring Bean. This will cause the generation of the necessary Java code.
The interface ICalculatorService class is generated based on the Port Type ICalculatorService. An information popup window will inform you.
Additionally a warning popup window will inform you about necessary changes on the Spring Bean Context Definition file.
That’s the composite.xml view after the creation of a Web Service Adapter on the exposed services swim land and the wiring to the CalculatorService Spring Bean.
Take a look at the Application Navigator view and the generated packages and classes. A new package named calculator.example.suchier was generated. That’s the WSDL targetNamespace (targetNamespace="http://suchier.example.calculator/") in the reverse order. The WSDL port type name ICalculatorService is the name giver of the Java Interface class. All WSDL Message definitions get equivalent Java classes. All generated classes are JAX-WS annotated.
The WSDL SOAP Fault declaration DivideFault becomes a Java Exception class which extends the java.lang.Exception class. That’s the exception which has to be thrown on a division by zero exception. The Web Service client will receive a SOAP Fault response.
The next step is the generation of the CalculatorServiceImpl class which implements the generated ICalculatorService interface class.
Instead of rewriting the existing Calculator Service operations we reuse the existing Spring Bean on the calculator package. So we have to inject the pre-existing Calculator bean. Take a look at the necessary changes on the Spring Bean Context Definition file.
Afterwards we create calculatorService setter and the implementation operations. The divide operation has an additional implementation part for checking the divisor on zero (and throwing an DivideFault exception in case of a zero value on the divisor parameter).
Last step is test the new Calculator service. On the divide operation we could check the “good day” scenario (where the divisor is different from zero).
And we could check the “bad day” scenario (where the divisior is equal zero).
Unfortunately there seems to be a bug on the Spring Bean SOAP Fault implementation. The SOAP Fault is just setting the faultstring element. But the fault detail element is not on the SOAP Envelope (I expected the DivideErrorType faultInfo information on the detail element).
The source code is available as 7-zip here.
That’s it. We create the first contract-first Web Service with Spring Beans on the Oracle SCA Container.
Hi Alexander,
ReplyDeleteI wonder how do you catch this fault in your BPEL process?
Regards,
Alec
Hi Alec,
ReplyDeleteyou have two ways to catch faults on your BPEL process which is calling a Spring Bean. One way is to use the "Add Catch Branch" or "Add CatchAll Branch" configuration on a calling scope or main process level. Afterwards you could add further activites on the catch branch in order to handle the fault. Another way is to use the SOA Suite Fault Management Framework which allows you to define policies for fault handling which occur when a BPEL process executes an Invoke activity. The Fault Management Framework intercepts the fault before it's returned to the BPEL process.