Capgemini Oracle Blog

Capgemini Oracle Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

SOA Development on the road and on the fly

Categories : How-toSOATechnical

In April 2010 Oracle added BPM to the SOA Suite, this version is also known as Oracle Fusion Middleware 11gR1 patch set 2. One of our lead developers and Java Architect, Gert Jan Kersten reports from the field as he collects experiences while working with this stack.
First his observation how to work off-line in a SOA Composite environment, SOA development requires you to be on-line, but there are locations where there is no on-line, like in a train. How to handle this situation. Secondly how to handle Permspace problems in a 64 bits environment (when you’re in hurry…) Off-line SOA development with JDeveloper In a project I use JDeveloper for developing a BPM 11gR1 solution. In the solution a number of web services are accessed. As the BPM process is actually a SOA composite these services are defined as external links of the BPM SOA composite. This works fine when you’re on-line. However when you’re developing off-line, for instance in a train, you run into problems. SOA development within JDeveloper is all about creating SOA Composites. A composite makes developing life easy when it comes down to combining functionality like BPM, Web Services, Adapters. External functionality can be defined in a Composite as external links. When creating the external links you have to supply the location of the WSDL of the web services. There are several options to access the WSDL’s, one of which is to retrieve the WSDL from an external application server. The WSDL specified this way is not included in the project itself but creates a link to that application server. Whenever using the BPM project, JDeveloper tries to access the application server to retrieve the content of the WDL. As I sometimes work in locations where there is no connection to the application server, I installed a local application server to test the project on. However, JDeveloper still tries to access the original application server and connection errors occur:
When specifying the WSDL there is an option to copy the WSDL and its dependencies into the project. It comes with a big warning that there is danger of synchronization issues and should only be used for offline designing. Another option is to use the WSDL retrieved directly from the projects used to develop the Web Services. These WSDL’s are incomplete, but there are ways to circumvent the problems arising from the incompleteness. I'll discuss that in another blog. Inspired by “there is no problem in computer science which cannot be solved by one more level of indirection (Butler Lampson)” the solution I now use is indirection of the application server hostname. Create two entries in your local copy of the host file (unix: /etc/hosts, windows: c:windowssystem32driversetchosts): #bpmserver centralApplicationServerIpAddress bpmserver 127.0.01 By commenting one of the entries either the local or the original application server can be selected. There are two points to consider with this solution: The local and original application servers need to be configured on the same ports. Remember to switch the host entries before starting JDeveloper, as JDeveloper caches the entries! Permspace problems in a 64 bits environment
In order to educate our Oracle people in the BPM 11G stack we’ve organized an internal Capgemini course, which is based upon the book ‘Getting Started with Oracle BPM Suite 11gR1’. To facilitate this course the run time environment is installed on our Capgemini's internal cloud (provided by HP).
During preparation of the course I installed the SalesQuote demo and tried all modules. While verifying all modules and doing some experiments the stack used up all CPU and eventually crashed. After restarting everything was running fine again.
At the first meeting Léon Smiers, was giving an overview presentation. I was supposed to deliver a demo later on. During the presentation by Leon, I was going through all modules once again, to verify everything was running OK. But then, bummer, again a crash of the SOA stack. I decided to have a look at the java crash file and fortunately quickly spotted a plausible cause: the permspace was exhausted: heapspace.png I changed the maximum permspace (-XX:MaxPermSize) in the start up script from the default value 512m to 756m and restarted the stack. Now all modules could be started without a problem. The stack was installed according to the instructions form Oracle. Only deviation was that a 64-bit jvm was used instead of a 32-bit jvm. Apparently the additional memory needed to store the objects in the 64-bit jvm was just too much for the default permspace! Gert Jan Kersten is certified Java Architect

About the author

Léon Smiers

Leave a comment

Your email address will not be published. Required fields are marked *.