The Java Cloud Service (JCS) in the Oracle Public Cloud allows me to deploy Java EE applications such as JAX-RS and JAX-WS REST and SOAP Web Services, Servlet | JSP | JSF Web Applications, EJB and JMS artifacts and ADF applications to the public cloud and make them accessible to developers, testers and end users anywhere in the world. For components to be deployed to the JCS – I have to do nothing special (!) during development or deployment: anything that runs on premises will run in JCS.
In this article, I will describe some of my initial experiences with JCS: what did I have to do to get going the first time – from having nothing more but a (trial) subscription to JCS to deploying and running my first Java EE application on JCS. I thought this would be a very long article with a large number of tips and tricks and with deeply technical steps. I felt some reluctance to even get going – feeling a little daunted by a new world full of new terminology. As it turned out – this is not a long article and it certainly does not contain a lot of tips. My initial reluctance was misplaced. JCS is just WebLogic – hosted on a different machine than my laptop and with a different provisioning interface. The amount of cloud terminology is limited (cloud account, identity domain, service instance is probably the bulk of it – along with simple tooling: dashboard, service console). JCS builds on three other Oracle Public Cloud Services that we need to be aware of: DBaaS (Database), Compute Cloud Service and Storage Cloud Service.
You do not need guidance from me for all the steps you need to go through. I worked with an excellent tutorial on Oracle Help Center – Getting Started with Oracle Java Cloud Service – and I heartily recommend you do the same.
The steps (described in this tutorial) that you need to go through in order to have your first Java EE application running are:
- (do: 5 minutes | then wait: days up to months) Get a [Trial] Subscription to the Oracle Java Cloud Service – for your Oracle account (the same one you use for OTN and any other interaction with Oracle); an Oracle Java Cloud Service trial environment or purchased subscription comes with Oracle IaaS Public Cloud Services, which provides you access to Storage CS and Compute CS – both of which underpin the JCS instance;
Note: Database Cloud Service is a prerequisite of Java Cloud Service and is priced separately. When you request provisioning of an instance of JCS, you need to specify the DBaaS instance that it should make use of. Read my previous article on DBaaS to get going with the Oracle Database as a Service offering and prepare a database instance.
- (do: 5 minutes) Associate the [trial]subscription with an existing or a new Oracle Public Cloud account (and thereby to an identity domain)
- (do: 5 minutes) Generate SSH keys (you can reuse the SSH key pair you may already have created to get going with Oracle DBaaS)
- (do: 5 minutes) Create Storage Container with the Storage Cloud Service
- (do: 10 minutes | then wait: 30 to 90 minutes) Complete a wizard to request provisioning of a JCS Instance
- (do: 2 minutes) Access the newly created WebLogic instance – through cloud based web consoles including WLS Admin Console and Enterprise Manager Fusion Middleware Control
- (do: 5 minutes) Deploy and run a simple (no dependencies) Java EE Web Application through WebLogic Admin console to verify whether we can make an application sing on JCS
All in all – this is almost a walk in the park. Yes, there is some new lingo to get used to. And yes, the process is a little different from installing WebLogic locally and creating & configuring a domain – but it is certainly no harder (in fact, quite a bit simpler unless you have very good scripting set up). It takes a little longer than I would have expected – but not much longer than local installation and configuration would take. And it happens in the background – as long as I can keep myself occupied, I do not really mind that somewhere inside the Oracle Data Center stuff is going on to provision my new WLS instance. One hour – with no effort on my part – is not bad, compared to any of the enterprises where I have worked as a consultant – where days, weeks and sometimes even months seemed to be the norm. Granted, in these organizations, getting hardware assigned, network set up, virtual machines prepared complicated the picture. However, as development team requesting a WebLogic instance that really should not be my concern. With JCS – infrastructure is required to: units of compute and storage. Provisioning of these IaaS resources is done automatically as part of the provisioning of the JCS instance; as I said: not my concern!
The final set up that the tutorial – and this article – results in is illustrated below. All action is inside a single identity domain, starting from two explicit service subscriptions (DBaaS and JCS) that come with two implicit IaaS service subcriptions (Storage CS and Compute CS). With four explicitly created instances: storage containers for database backup and JCS backup, the MyJCSDB database instance and the WLSJCS12c WebLogic instance. With service associations from the JCS to the DBaaS instance and from JCS and DBaaS to the respective storage containers for backup.
Some Action Details
As I wrote before – the details about the steps to take are described very clearly in the tutorial. I will not repeat these instructions. I will however write a little bit about my experiences while following the instructions.
After creating the DBaaS instance, generating the SSH public/private key pair and creating the storage container on the Storage Cloud Service, I opened the JCS service console from the general dashboard.
In the console, I pressed the Create Service button
This took me to a configuration wizard (the Create Oracle Java Cloud Service Instance wizard) where I specify the details for the new service instance that will be provisioned. On the first page, I selected the subscription type – meaning the service level and billing frequency (Oracle Java Cloud Service: Production-level service, monthly). On the second page the software release – WLS 12c (188.8.131.52) – and on the third the edition – Enterprise Edition. This is all in line with the tutorial.
Then things become more exciting and somewhat more complex: the Service Details. This page has us specify details for the service associations to DBaaS – in my case the MyJCSDB instance set up as described in this article – and the storage container in the Storage Cloud Service for backup purposes. We also specify the name of this JCS instance, the cluster size and compute shape and the username and password for the administrator.
This is by far the most involved step in the whole provisioning process. If you know how to define these configuration details, you know pretty much all there is to know about provisioning JCS instances.
The next page in the wziard is for confirmation:
Press Create to actually start the behind the scenes provisioning process. The request is acknowledged and now the waiting starts.
The service console gives a little feedback about the progress of the instance creation process.
And some more
And more still:
Finally – after about 45 minutes – the service instance is ready. The load balancer, an admin server and two managed servers are available, accessible on three different public IP addresses
The last screenshot shows the popup menu in the service console for the new JCS instance, providing access to various consoles such as the WLS Admin console, the EM Fusion Middleware Control console and the Load Balancer console.
Below are the details for the WLSJCS12c instance of JCS in my identity domain:
The three compute nodes are listed – along with public IP addresses for the Admin Server compute node and the Load Balancer compute node. The service association to the DBaaS instance is clearly visible as well. The allocated IaaS resources – 22.5 GB of memory and 167 GB of storage – are indicated. Frankly, that is way more than I could have spared for this WLS instance on my laptop.
The content endpoint listed for the Load Balancer is a url to a sample application. By accessing the sample app through the load balancer running on the two managed services in the cluster we can verify the success of the JCS provision process.
At later stages, we can use this same URL as a ping-like call to test the health of the JCS instance and the WLS cluster.
In the EM Fusion Middleware Control console – accessible from the service console for our JCS instance – we can check on the sample-app application deployment, among many other things. The FMW Control is no different in the cloud than it is in on premises environments:
For kicks a screenshot from the Service Metrics console that provides insight in response times and heap (memory) usage.