Posts Tagged ‘JDeveloper’

Best practices 3 – Oracle ESB and Mediator

This is the third post in our SOA and BPM best practices series. This blog provides best practices for Oracle ESB (Oracle Fusion Middleware 10g) and its successor (when it concerns routing and transformation): the mediator component in SCA (Oracle Fusion Middleware 11g). The previous blog in this series is about Web Services best practices.

Best practices 2 – Web Services

This is the second post in our SOA and BPM best practices series. This blog is about Web Services and provides a mix of general tips and more specific tips for Web Services that are implemented using Java and JEE. You can find the first blog in this series here.

Approach. Decide upfront, based on the requirements and constraints, what approach for Web Service development best suits your situation: top-down or contract first, bottom-up, or meet-in-the middle.

• Top-down or contract first. The starting point here is the contract of the Web Service: its WSDL. You either design it or it is provided as a ‘given fact’. From the WSDL you generate the implementation. If the contract frequently changes, regeneration of the code can cause difficulties since the implementation is overridden. If you use this method, make sure you don’t change the generated artifacts.
• Bottom-up or implementation first. The starting point is the implementation; all Web Service artifacts“such as its WSDL’s “ are generated. This is a fast approach when you want to expose existing components as Web Service. However, you need to be careful because you have limited control over the generated Web Service artifacts and it is therefore easy to break an interface if the Web Service is regenerated.
• Meet-in-the-middle approach. Here you define both contract and implementation yourself and later on create the glue between them. In case of Java you can use JAX-WS and JAXB APIs and code to create this glue. This is a very flexible approach: you can change both the WSDL and the implementation. It requires more work in the beginning, but is easier to change later on.

Compliance. A Web Service that isn’t standards-compliant is less (re)usable. Make sure your Web Service is compliant to the WS-* standards by using the WS-I profiles (Web Services Interoperability Organization).

Exposing operations. Don’t expose all methods as Web Service operations by default when using a bottom-up or meet-in-the-middle approach. Only expose those methods that are actually needed by service consumers. This promotes encapsulation and prevents access to ‘internal’ methods.

Products. Nowadays most products and technologies support Web Services. Keep their pros and cons in mind when deciding what technology to use. Java for example provides better support and a better runtime for Web Service development and XML-processing than relational databases.

Large XML documents. Avoid creating Web Services that receive, process, and/or send very large XML documents. XML processing is resource-intensive and relatively slow and therefore not well equipped for handling bulk data. Use other technologies such as database technologies or ETL tools for that purpose.

Quality of Service (QoS). It’s easy to develop basic Web Services-but it’s hard to make them robust, secure, and scalable (enough). Address these QoS (or non-functional) issues in the beginning of the project instead of discovering that requirements are not met at the end of your project.

Annotations. Be careful when using vendor-specific annotations (as opposed to the general annotations defined in the JAX-RPC, JAX-WS, and JAXB standards). Although vendor-specific annotations such as those in WebLogic can be very powerful they break portability of Web Services and tie them to a specific runtime.

Migration to WebLogic. See this blog for migrating JAX-WS Web Services from JDeveloper 10g/OC4J to JDeveloper 11g/Weblogic. Note from the blog that a bottom-up approach was used. After migration the WSDL was changed (among others the namespaces were changed) causing the invocation to fail. This is a typical example illustrating the pros of using a top-down or meet in the middle approach.

Next post in this series will be about best-practices for Oracle ESB and Mediator (FMW 11g).

ODTUG 2008 day 3: JDeveloper and BPA Suite

The third day of the conference, I decided to go check out some of the features of JDeveloper11g. The first session was done by Susan Duncan and Lynn Munsinger. The session showed the integration with Subversion. They had a very cool format: Susan was the PM who talked about the features of JDeveloper and some best practices with subversion. Meanwhile Lynn created an application that she checked in. Susan and Lynn then created a conflict in a JSPX file. Some of the cool features that they showed us were:

• XML aware merging in JDeveloper. This is really helpful, especially because a lot of the files in Java development are xml. One really cool part was that the visual editor actually showed the place of the merge conflict visually!
• Chat client in JDeveloper. I am not sure I will ever use it, I like my own chat client just fine. But the ideas is nice and you can use your own chat provider.
• Incoming changes from other developers. You can poll the svn repository for changes. They thought about this feature: you can set the timing in the preferences, so you don’t slow JDeveloper too much

The session was fun and informative, despite some technical difficulties they suffered.

The second session was about reusability features in JDeveloper. Shaun O’Brien talked about the resource catalog, libraries, page fragments, task flows, and page templates. I really like the taks flows: I think this is an important improvement in JSF, and I hope this will be added to the specification. The resource catalog, the templates and the possibility to compose components by combining existing ones are powerful concepts as well. The presentation lacked a demo, though.

The last session was really up my alley: a session about the BPA Suite. There were only a few people in the room, but we had a very interesting exchange of ideas. This was stimulated by the presenter, Ann Horton. She had a nice introduction and demo, and asked plenty of questions to fuel the conversation. I hope ODTUG will have more of these next year…

Automated build & deployment in OC4J 11g

Automated build & deployment is very important. Not only is it a condition for continuous integration, it helps prevent costly errors during development and build promotion.

Now pretty soon (hmmm, well, next year at least , we will have this new Oracle stack: Oracle Fusion Middleware 11g. A lot of improvements, not only in ADF and SOA Suite, but also in the management of the application server and the different suites. One of the downsides is that you need to rewrite (and maybe re-consider) your existing automated build and deployment solutions. A lot of stuff has changed, the JMX interface for example. I wondered about the ant tasks….

I decided to write a very tiny ADF BC application in JDeveloper11g tp2 and deploy it to the standalone OC4J11g (Preview). Right away I ran into a problem: the runtime installer does not work (yet). Luckily, Steve Muench wrote a technote that explains how to fix that. It is written in May 2007, for preview 1. In preview 2, some of the libraries have ‘disappeared’. If you are following the steps that are described in the technote, you can skip copying %JDEV_HOME%\BC4J\lib\adfrcutils.jar and %JDEV_HOME%\BC4J\lib\connmbean.jar; they are no longer there.

Next I needed some tool to automate the build and deploy process. Since the Oracle application server and SOA Suite support Ant driven deployment, I decided to go with that for the deploy tasks. I wondered if I could still use the deployment task from the previous version as described in the deployment guide for version 10g.

To test it, I deployed the ADF BC application to an ear file in JDeveloper11gtp (I will get to build tools later in this blog), and ran the following ant task:

<target name="deploy" depends="init" >
<oracle :deploy userid="${oc4j.admin.user}"
password="${oc4j.admin.password}"
file="${deploy.dir}/${ear.file}"
deploymentname="${app.name}-ear"
logfile="${log.dir}/deploy-ear.log"/>
<oracle :bindWebApp
userid="${oc4j.admin.user}"
password="${oc4j.admin.password}"
deploymentname="${app.name}-ear" webmodule="${app.name}-webapp"
websitename="${oc4j.binding.module}"
contextroot="/${app.name}" />
</target>

It works fine. The nice thing about JDeveloper11g is that the resources are project specific. This means that now the deployment profile for an ear file, will only take the connection that you need for this application. Not every connection that you have ever stored in the IDE.
Still, I don’t like to use the deployment profiles from JDeveloper. Managing the dependencies that are needed for your application(s) is really difficult. This gets worse if you have several different projects and workspaces. If want to do continuous integration you need ant or maven, or some other tool.
Ant soon becomes unmanageable when you have several artifacts and a lot of libraries. I had good experiences with Maven in the past, so I decided to have a go with Maven2.

There is a very nice post by Aino Andriesen on the Amis weblog. Unfortunately, the libraries that ADF uses have changed. This means you need to do some work to get them all listed in your pom.

• create a directory structure as described by Aino
• create an ant build file based on the project in JDeveloper. This will point you to all the jar files that are used by the webapplication. You don’t need to package all these files, these are the standard libraries needed to compile any ADF BC application
• add the jar files that end up in the ear file generated by JDeveloper deployment profiles as dependencies to the pom
• add the jar files to your local repository. You can use the following command for that: mvn install:install-file -Dfile=[path-to-file] -DgroupId=[group-id] -DartifactId=[artifact-id] -Dversion=[version] -Dpackaging=jar
• add the ant deployment task with Antrun plugin

You are done. If anyone is interested in getting the pom, just leave a comment and I will send it to you. All in all not so painful after all!