ADF Application Module can be enabled as Service Interface (SDO), but i take a different approach to this as shown below.
1. Create Application Structure
Create Generic Application. Delete generated Project. Add Model Project and Web Project (without Faces). Create Connection (hrdb) to HR Schema.
2. Generate Business Components and Prepare Service API
2.1 Generate ADF Business Components using JDevelolper Wizard. Create Application Module later, otherwise initial wizard adds many entries to Application Module’s Data Model.
2.2 Create simple POJO for Country object.
2.3 Create service method to return all Country objects. Expose it to Client Interface.
3. Create Web Service POJO class
Create POJO class with necessary API method(s). This example is not showing any exception handling, but you can throw Checked Exception to indicate Validation, Application or System type error situations to client.
Alternatively, you can also start by creating WSDL file to represent your Web Service.
4. Generate SOAP Web Service from POJO
Generate Web Service using JDeveloper wizard. This generates SOAP Web Service only with JDeveloper 11.1.1.x, hopefully future versions of JDeveloper will allow generation of REST Services.
Note annotations added by Wizard.
5. Test Web Service
Right click Web Service in Application Navigator and select Run or Debug.
Why this approach?
1. This approach allows for flexibility in exception handling, as you can control types of exception thrown to client. Service Generation approach from Application Module throws Runtime Exceptions which is seen as SOAP Fault by client and it does not have any useful information.
2. You may want to control WSDL and / or Schema to confirm to your Enterprise Standards, which is possible only when using this approach.
3. This approach is little bit clean, as Web Service and BC4J code is organized in separate projects.
And, It is not at all difficult to generate Web Service from POJO with available Wizards.
5 thoughts on “Create SOAP WebServices using BC4J”
Thanks Chandresh! This is very helpful
Can you give one concrete example regarding benefits (“Why this approach?”) you are mention?
Let’s say you have Application Module method that approves Order and transaction is committed and this method is exposed in SOAP WebService. There is possibility of validation exception or system level exception (database connection failed) in this API call, and in such situation caller of WebService will receive SOAP Fault without any details on what caused fault or type of exception.
Chandresh, thanks for the nice blog.
I am also thinking that this is the best approach, especially because AppModule cant expose complex types.
All in all, in last two versions of jdeveloper I experienced an issue with ‘oracle.jbo.client.Configuration classNotFound’ when application is deployed on weblogic.
do you have any advice to share regarding the issue?
Check deployment descriptors in your EAR for library references. For example, adf.oracle.domain library may be missing in weblogic-application.xml.