Side by Side Deployments (Rolling/Hot/InPlace Deployments)

One of the great features of ADF/Weblogic is side by side deployments. This allows you to deploy two different versions of an application to a Weblogic server without the need for an outage. Weblogic is smart enough deal with current and new session. Once the new version of the application has been deployed to the server the old version of the application set in to "Retired" status and the new version is set to "Active". The retired version of the application maintains any active sessions until they end (also has the option to expire all sessions immediately or after a set time period). Whilst the new active version of the application handles all the new sessions, this is quite a cool feature. I've used this a fair bit and it seems to work quite well. This only catch is if you are a deploying a large ear file the response times of the server do suffer.

Anyway, here is how you do it.

Firstly create a two test applications.

Create a MANIFEST.MF file and paste the following details inside. Take note of the Archive-Version, this is the version number that weblogic looks for when it decides to retire or promote the new application. 

You will need to create a new deployment profile.

Then define your new manifest file.

Then do the same as above but increment the Archive Version and do the above two steps to the second application.

In order to test that the side by side deployment worked. Deploy the first application and it should appear as 'Active' in the weblogic console, then deploy the second application and the first application should get set to 'Retired' and the new application will be set to 'Active'. 

To ensure that you don't have an outage you can test the site with a load testing too such as LoadUI as I did below. You can see an increase in response time when the second application is being deployed. In reality, it is Oracle's recommendation that you have the Admin Server running on a separate machine to your managed servers. So when you do a side by side deployment in "theory" you shouldn't see an increase in response times as you can in the below test.

Modifying Web Service Endpoint at Runtime

Recently, we came across an issue where we had to modify the end points of several previously generated web service proxies for a application with the requirement to run on a number of different environments.

The initial thought was that we could do this through an ANT script. However, this became very messing, very fast. So after a bit of think I realised the endpoint was in the request and the request could be modified.

Hence the below code refers the to the ENDPOINT_ADDRESS_PROPERTY property key for the request. Allowing you to modify the endpoint at run time before the request is sent. Opening the door to modify the endpoint to a string specified within a database or property file.

 TestWebService webservice = testWebServiceServiceagent.getTestWebserviceSOAPHTTPEndpoint();  ((BindingProvider)webservice).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "new end point");