In this previous article – Getting started with Java Cloud Service on the Oracle Public Cloud (WebLogic as a Service) – I have taken you on a introductory tour into JCS. That article describes how to get going – how to provision a JCS instance – associated with an instance in DBaaS and with backup set up with Storage CS.
In the article you are currently reading, I show you how to use this instance for deploying a Java EE application onto – and subsequently invoking that application.
Since the same consoles are available to us with JCS as with on premises WLS, we can perform an application deployment in the same way from the console by uploading a WAR or EAR file as we can do on premises. I tried my hand at a fairly large application – without any Java EE dependencies (no EJB, JMS or JDBC data source requirements): the ADF Faces Rich Client components Demo application – available from http://www.oracle.com/technetwork/developer-tools/adf/downloads/index.html . The downloaded file is about 105 MB. The subsequent deployment of this file to JCS fails: the step takes quite long – because 105 MB have to be uploaded again, from my laptop into the Oracle Public Cloud. This console could be extended by Oracle perhaps to also offer to upload directly from a URL. On three attempts, after about three minutes into the upload, the deployment process fails. Either on the JCS end or in the browser to server communication is a problem. I am not sure what it is caused by. For now, I will simply try my hand at a smaller WAR.
Plan B or Take Two at deploying a Java EE application
Instead of looking around for a suitable ready to deploy WAR file, it is probably even more rewarding to quickly develop a Java EE application, build it as a WAR file and deploy it to my new JCS instance. Using JDeveloper, I quickly whip up a JAX-WS application: a simple Java Class that with some JAX-WS applications is turned to a SOAP Web Service (by right clicking the Class and selecting the option Create Web Service):
The functionality of this service should be fairly obvious from the code. The WSDL that the derived service exposes can be previewed in JDeveloper:
Deployment of the service can be done from the project navigator: right click on the ViewController project:
and select Deploy | WebServices.
Select WAR as the target. Complete the wizard:
The WAR file is generated:
With this WAR file under my belt (download it from VerySimpleJCSTestApplication-ViewController-context-root), I return to the WLS Admin Console for the JCS instance and re-enter the deployment dialog.
Upload the WAR file that contains the Greeter Web Service
Step through the deployment wizard:
Then activate the changes:
click on the control tab
and activate the application:
Go to the Testing tab for the Web Service:
This tells us the URLs for the WSDL for the web service; note that there are two endpoints, because we have a two-node cluster and the application was deployed on both managed servers.
The end point to use is https://public-IP-address_for-loadbalancer/VerySimpleJCSTestApplication-ViewController-context-root/Greeter?WSDL. Note that is an HTTPS address – using the default SSL port 443. The WSDL can be viewed in the browser:
I create a new SoapUI project for this WSDL:
and then send a test request to the service – from SoapUI on my laptop to the JCS instance on the internet:
This clearly proves that the JCS instance is running, that the application deployment was successful and that the load balancer is also doing its job.
I have also performed a little load test from SoapUI:
375 service requests were sent; the average response time – including network latency – is a little over 40 ms. A second load test yielded an average response time of 270 ms. A third was back down to just over 40.
It is interesting how this is little load test is perceived from the JCS end – in the Service Metrics console:
Resources
Download the very simple WAR file for the Greeter application discussed in this article: VerySimpleJCSTestApplication-ViewController-context-root.
