Posts Tagged ‘migration’

Some tips & tricks on migrating SOA Suite 10g to 11g – Part 2

This blog contains some experiences taken from our migration from SOA Suite 10g to SOA Suite 11g. The previous one was about custom XSLT functions, sensors, composite instance tracking, and Domain Value Maps (DVM). This entry is about using Oracle Internet Directory (OID) 10g as identity provider for SOA Suite 11g.

Integrating OID 10g with SOA Suite 11g
Using OID 10g as identity- and access provider in SOA Suite 10g wasn’t entirely trivial. After applying the steps as documented in Oracle BPEL Process Manager Administrator’s Guide 10g you needed to perform some additional configuration steps that could be somewhat tricky at first. Jaap Poot has some great blogs on this.

Some tips and tricks on migrating SOA Suite 10g to 11g

Just a few things I noticed last week when migrating BPEL and ESB projects from SOA Suite 10g to SCA composites and components in SOA Suite 11g.

Exception-handling in JAX-WS Web Services on WebLogic

There is more to exception-handling in JAX-WS Web Services than meets the eye. Especially when throwing custom (checked) exceptions from your Java methods that are exposed as Web Service operations. There’s a nice blog by Eben Hewitt on using SOAP Faults and Exceptions in Java JAX-WS Web Services. I recommend reading it; especially when you get the following error: javax.xml.ws.soap.SOAPFaultException java.lang.NoSuchMethodException. This is one of the issues you might run into when migrating from Oracle Application Server (OC4J) to Oracle WebLogic Server.

Migrating EJB 3 applications from OC4J to WebLogic

In a previous post I talked about migrating JAX-WS Web Service projects from JDeveloper 10g/OC4J to JDeveloper 11g/WebLogic. This is one of the activities in a current migration project of a SOA-environment from an OC4J-based stack (OC4J 10g, JDeveloper 10g, SOA Suite 10g, ADF 10g, WebCenter 10g, EJB 3/TopLink Essentials) to a WebLogic-based stack (WebLogic 10g, SOA Suite 10g, ADF 11g, EJB 3/EclipseLink).

As mentioned in the previous post, a lot of migration steps are performed automatically when importing 10g projects in JDeveloper 11g. This is also the case for EJB 3 applications that use TopLink Essentials as persistence provider. All references to this provider are replaced with EclipseLink references since EclipseLink -based on TopLink 11g- is/will be the de facto Oracle persistence provider. Deployment of these EJB 3 components to our development environment -Integrated WebLogic Server in JDeveloper 11g- works fine and everything runs smoothly.

For test, acceptance and production environments we use separate WebLogic 10.3 installations. These are “clean” environments. Instead of having all kinds of frameworks deployed on your application server -as is the case for Oracle Application Server and the Integrated WebLogic Server in JDeveloper 11g- this environment is actually clean, lean and mean.

Although in my opinion this is what you want out-of-the-box -you don’t have all kinds of preinstalled frameworks that you do not use, less classloading issues, and so on- initial deployment of our EJB 3 components failed when deploying: NoClassDefFoundError: org/eclipse/persistence/jpa/PersistenceProvider. That’s because Oracle WebLogic 10.3 is not shipped with TopLink 11g/EclipseLink.

There are several solutions for this. You can use patches 9J3A and 5KXF to install TopLink 11g/EclipseLink on WebLogic 10.3. They can be downloaded using SmartUpdate; I couldn’t find them on MetaLink (yet). You can also install EclipseLink manually on an Oracle WebLogic domain as described in the EclipseLink’s User Guide. Other ways of solving this -although I don’t recommend these options- is to package the persistence provider with every application. That means including EclipseLink archives into an application’s WAR or EAR. Or you can switch to Kodo -BEA’s former JPA implementation- since this is shipped with Oracle WebLogic 10.3. However in the latter case you’re not using the go-forward/strategic persistence provider, which is EcslipseLink. Note that later versions of Oracle WebLogic will probably ship with EclipseLink.

Migrating Web Services from JDeveloper 10g to 11g

Although most of the migration steps from JDeveloper 10g/OC4J to JDeveloper 11g/WebLogic are automated, there are some exceptions. One such case where you have to roll up your sleeves and do some coding are EJB 3 Session Beans that are exposed as Web Services using JAX-WS annotations. JDeveloper 10g generates a separate Java interface containing JAX-WS Web Service annotations when using the EJB 3 Session Bean Wizard and selecting the option to create a Web Service interface. Note that this option isn’t available in JDeveloper 11g, but you can right-click an EJB Session Bean and select the generate Web Service option that will give you the same result.

When migrating the JDeveloper 10g workspace to a JDeveloper 11g application -by opening the jws file in JDeveloper 11g- most of the migration work is automatically done; for example the workspace and project files are updated and existing deployment plans are converted.

If you then deploy the project to the integrated WebLogic server everything seems to deploy and run just fine. However if you expand the deployment in the WebLogic Server Administration Console you’ll see that there are no web services listed, only EJBs.

Here are some simple steps to correct this:

1. Remove the Java interface containing the JAX-WS Web Service annotations that was generated in JDeveloper 10g and remove the interface from the implements statement in the EJB Session Bean class.
2. Add a @WebService annotation to the EJB 3 Session Bean containing the following arguments: name, serviceName, and portName. Check the WSDL of the current deployed Web Service generated with JDeveloper 10g to obtain its metadata such as name, namespace, and portname. These values can be used in the new @WebService annotations of the migrated Web Service in JDevloper 11g so that Web Service clients don’t break due to different namespaces, portnames, endpoints, and so on. You can also use other annotations to influence the endpoint and WSDL of the Web Service. However mind that some annotations are WebLogic-specific and not part of the JAX-WS standard.
3. Optionally add other JAX-WS annotations as needed.
4. Replace the JAX-RPC project libraries with the JAX-WS Web Services library.
5. The current WebLogic JAX-WS stack -more specific the JAXB implementation- does not support java.util.Map and java.util.Collection family types as Web Service method return or input types. Deployment fails with the message “java.util.Map is an interface, and JAXB can’t handle interfaces” and “java.util.Map does not have a no-arg default constructor”. A logical workaround would be to replace these types with concrete implementations that have a no-argument constructor; for example java.util.HashMap. Although deployment then succeeds, the information contained in the map is lost at runtime when requests/responses are (un)marshalled. A final workaround was to replace the java.util.Map with a two-dimensional array. Although I’m not really happy with this workaround, it works for now.

Deploy the project and voila, the WebLogic Server Administration Console shows both EJBs and Web Services.

So “no coding required”, or just a little bit perhaps ?

P.S. Some useful links:

• Oracle-By-Example “Building Web Services” in JDeveloper 11g
• JDeveloper 11g Release Notes for Web Services Development