Before we start talking about how to do things better, we need to have a clear picture of how we do things today, and why that approach is not optimal. Obviously every organization is different, and there is a continuum of maturity. In this post, I am going to attempt to describe what I think is a fairly typical, or average, scenario. Some organizations will be better, some worse.
This average is based on a lot of experience with a lot of different organizations. It is not based on any one organization, so if you know me, and you see yourself, it is totally coincidental!
I think the best way to describe how things are normally done today, is that there seems to be a fundamental, possibly unacknowledged, assumption that everything will be all right in the end.
A lot of development is done is isolation – individual components are developed separately from each other, by different teams, or different developers, sometimes even by external organizations. Each of these groups will do their own local, usually manual, testing of the individual components they are developing.
As much as 90% of the time allocated to the project may be consumed before starting to do any proper integration testing – i.e. making sure that all the individual components actually work together when they are assembled into the whole system.
Often this integration testing late in the project lifecycle will identify many problems, a decision will be made to work 24×7 until the project go-live cut-over to get all of these issues fixed, and then we have everybody working under a considerable amount of pressure, which leads to cutting corners, and giving up on good practices in favor of just getting it done.
To make matters worse, the developer’s memory of the codebase is not fresh – it could be weeks or months since they last worked on the component where the issue was found, and it might even be a different person trying to fix the issue, who has no familiarity at all with the code in question.
Often there is a lack of documentation, tests, and so on. Does this story sound familiar? It is starting to hurt. We have absolutely no idea what the quality of our system is – i.e. how good or bad it is.
When we arrive at the go-live day, we have a lot of fear and uncertainty. We have no idea if the system is going to work in production. We have never tested it under a production-like load, and we have not really tested it for performance, longevity, etc.
Maybe this is not you, maybe you are lucky enough to work in an environment that is not like this, but I can tell you from first hand experience that there are a lot of environments that are exactly like this.
So what do we do about it? We need to change the fundamental assumption of SOA development. We should be assuming that the system works and that it is in a releasable state at all times.
That means that we need to adopt techniques like continuous integration, continuous inspection, and continuous delivery. Every time a developer makes a change, we need to get fast feedback to the developer (and other stakeholders) to tell them if that change was good – did it break the build? What was its quality score? Did it cause any of our tests to fail? Could we release the system with this change in it? How confident are we to do that?
We need to find problems faster, when they are smaller, fresh in the developer’s mind, and easier to fix. We need to check quality at every step in the process. We need to test the application, we need to automate the testing, automate the provisioning of environments, test the environments as well as the applications. Essentially, we need to go through a mini-release cycle over and over again, every time we introduce a change. We do this to prove to ourselves that we can still build the application, to know how confident we are in its quality, and to know that we can actually provision an environment and deploy the application in to it.
There is nothing magical about this. People are doing this today in many software projects. We can use the same methods and tools to achieve the same benefits in SOA projects.
We can achieve almost everything we want to do without really needing much changed in the products. There are some things of course that it would be great if Oracle added to the products, but that need not be an excuse to get started.
In the next post, I am going to outline a roadmap of where we want to get to, and then over this series of posts, we will in essence conduct an open proof of concept together, to show that we can achieve these goals, and how, in detail.
Coherence 12.1.2 was recently released, including the new Coherence Managed Servers and also Maven support. You can read more about it here.
You may also be interested in these two excellent video introductions/demonstrations from the Coherence team:
Both cover the new Maven support in Coherence.
The ADF Product Management team has just announced the ADF Architecture TV YouTube channel. The channel will publish new episodes on ADF design, architecture, development and deployment best practices each week, for a total of about 100 episodes.
The channel has specifically been designed with small, discrete episodes on topics encompassing the whole ADF development lifecycle, introduced by key Oracle ADF folks like Frederic Desbiens, Duncan Mills, Chris Muir, Frank Nimphius and Grant Ronald.
You can find the ADF Architecture TV channel here and you can watch the introductory video here.
Here is the official announcement is here and the complete set of episodes has been indexed on the ADF Architecture Square on Oracle Technology Network.
Oracle has just released version 12.1.2 of the Fusion Middleware platform. This release includes some new support for build automation with Maven and for continuous integration. In this post I want to give you a quick tour of what is new. In a follow up post, I will go through a detailed example of using the new Maven features.
Fusion Middleware 12.1.2 includes WebLogic Server, Coherence, ADF and JDeveloper. In this release, Oracle has added the following capabilities to support customers use of Maven to build projects targeted at Fusion Middleware runtime environments:
Let’s start the tour with the new WebLogic Maven Plugin. This new version, with Maven coordinates com.oracle.weblogic:weblogic-maven-plugin:12.1.2-0-0, provides a much more idiomatic implementation that the older Maven plugins that have shipped in WebLogic in the past. It supports all the same goals, plus some new ones. But the focus is more on the primary use case – continuous integration – and less on running individual goals from the command line without a POM. That is not to say that you cannot still run the individual goals from the command line, but the plugin is much more interesting when you start to consider what you can do with it when you start mapping goals on to Maven lifecycle phases.
Here are the goals supported by the weblogic-maven-plugin:
| install | Install WebLogic Server, from a zip or jar installer, optionally with a response file. |
| uninstall | Uninstall WebLogic Server. |
| create-domain | Create a (simple) WebLogic Domain from one of the provided domain templates, or one of your own. This is only intended for simple domains. For anything else, you should use the wlst goal. |
| start-server | Start a WebLogic AdminServer or managed server. |
| stop-server | Stop a WebLogic AdminServer or managed server. |
| appc | Run appc on the project to prepare it for deployment. This generates and compiles the classes needed to deploy EJB and JSP and validates the deployment descriptors. |
| ws-clientgen | Generate a web service client from a WSDL. |
| ws-wsldc | Generate artifacts and a skeleton Java implementation from a WSDL. |
| ws-jwsc | Build a JAX-WS web service. |
| distribute-app | Prepare for deployment by copying deployment files to the target servers and validating them. |
| deploy | Deploy an application (EAR, WAR, etc.) |
| redploy | Redeploy an application. |
| undeploy | Undeploy an application. |
| update-app | Update an application, using the provided plan. |
| list-apps | List the applications on a particular target (server, cluster). |
| start-app | Start an application. |
| stop-app | Stop an application. |
| wlst | Run a WLST script – using either the WebLogic Server wlst.sh or the ‘oracle_common’ one (which loads additional libraries). |
You can read detailed documentation of each goal, including details of the parameters, and example POMs in Chapter 3 of Fusion Middleware: Developing Applications for WebLogic Server.
I will be providing some examples of how to use the plugin in a followup post.
The Coherence Maven Plugin allows you to build applications for the new Coherence container. It has Maven coordinates com.oracle.coherence:maven-gar-plugin:12.1.2-0-0 and it introduces a custom packaging type of gar for the Coherence Grid Archive.
Here are the goals supported by the maven-gar-plugin:
| generate-descriptor | Populate a Maven repository from an Oracle Home |
| package | Package into a GAR |
| repackage | Run POF configuration code to enhance packaged GAR |
You can learn more about the Coherence Maven Plugin in action in a soon to be published from Tim Middleton from Coherence Product Management. I will update this post with a link when it is available.
A number of archetypes are provided to help you create new projects. These all create projects with some sample code and and appropriate POM in place. Each of these creates a POM which points to an Oracle-supplied hierarchy of parents. Here are the archetypes and parents (in bold) in 12.1.2:
com.oracle.maven:oracle-common:12.1.2-0-0 - com.oracle.weblogic:wls-common:12.1.2-0-0 - com.oracle.weblogic.archetype:basic-webapp:12.1.2-0-0 - com.oracle.weblogic.archetype:basic-webapp-ejb:12.1.2-0-0 - com.oracle.weblogic.archetype:basic-webservice:12.1.2-0-0 - com.oracle.weblogic.archetype:basic-mdb:12.1.2-0-0 - com.oracle.coherence:gar-common:12.1.2-0-0 - com.oracle.coherence:maven-gar-archetype:12.1.2-0-0
The parents are provided as a point of customization. If you want to specify some properties or behaviors at a product-wide or site-wide level, you can add them into these parent POMs.
One of the challenges when using Maven with Fusion Middleware in the past, was that Oracle did not provide POMs describing the dependencies that you needed to compile, package and deploy various types of projects. In 12.1.2, these POMs are supplied with WebLogic Server, Coherence and ADF/JDeveloper. But you still need a convenient way to load these into your Maven repository – either your local developer repository, or a shared repository.
The other challenge is that Maven and Fusion Middleware make different assumptions about how installed software will be patched. When you apply a one off patch using OPatch, this could result in a JAR file being updated that is one of those dependencies you use in your Maven builds. But OPatch will not necessarily update any version numbers, so how does Maven know there is a new version of the dependency?
To address these challenges, Oracle has shipped a ‘Maven Synchronization Plugin’ which allows you to populate a Maven repository from an Oracle Home. This plugin will let you set up your Maven repository in the first instance, and it will find any changes after you patch you Oracle Home and populate those to your repository as well.
This plugin has the coordinates com.oracle.maven:oracle-maven-sync:12.1.2-0-0, and the main goal you will want to use is its push goal.
Expect some more information, samples and videos soon 🙂
Update: Seems I was a bit early! The site should be launched soon 🙂
The A-Team has launched a new web site – the A-Team Chronicles which aggregates and organizes content produced by The A-Team members (including your humble blogger).
The A-Team is a central, outbound, highly technical team comprised of Enterprise Architects, Solution Specialists and Software Engineers within the Fusion Middleware Product Development Organization that works with customers and partners, world wide, providing guidance on implementation best practices, architecture, troubleshooting and how best to use Oracle products to solve customer business needs.
This content captures best practices, tips and tricks and guidance that the A-Team members gain from real-world experiences, working with customers and partners on implementation projects, through Architecture reviews, issue resolution and more.
A-Team Chronicles makes this content available, through short and to the point articles to all our customers and partners in a consistent, easy to find and organized way.
If you like the articles we post here, you might find even more interesting articles at the new A-Team Chronicles site, covering a wider range of Fusion Middleware topics.
Oracle has launched a new, interactive, online, and FREE ADF Mobile course: Developing Applications with ADF Mobile.
From the announcement:
“The course blends media-rich content to bring you interviews with the experts, engaging interactions, and inviting demos and graphics that keep you interested as you learn all about ADF! Developing Applications with ADF Mobile will take you straight through from the basics of ADF Mobile, to developing mobile applications, accessing web services, and integrating with mobile device functionality. A future release of the course will include mobile security topics as well.”
Heidi Buelow (@heidibuelowBPM) from the BPM Product Management team at Oracle, has published some Case Management samples on java.net.
They include the ‘EURent’ case definition, which is a car rental scenario. Included is a document that walks you through the use case. There is also a sample Case Management UI that you can use to run the case.
BPM 11.1.1.7 has a new ‘instance patching and migration’ feature that allows you to apply changes to running instances of processes (without changing the revision of the process) and/or to migrate running instances between revisions of a process.
There is a short viewlet demonstration posted here, but no sound unfortunately.
I have a number of posts that talk about using Maven to automate builds for Fusion Middleware projects. I know that there are some people who have not used Maven before, or maybe only a little. So I wanted to post a few short videos that explain the basic concepts and give a real example.
Here is the first installment – Basic Maven – you might want to watch fullscreen 🙂
Coming soon:
Building a Custom BPM Worklist, Oracle InSync 2011 User Group presentation
Performance Tuning for Oracle Business Process Management Suite 10g, Oracle Whitepaper, July 2011
Performance Tuning for Oracle Business Process Management Suite 11g, Oracle Whitepaper, February 2013
Oracle BPM Suite 11g: Advanced BPMN Topics, Packt Publishing, September 2012
Fusion Middleware 12.1.2: Developing Applications with Continuous Integration
Fusion Middleware 12.1.3: Developing Applications with Continuous Integration
RedStack 
You must be logged in to post a comment.