Saturday, 4 June 2016

A Microservice Approach for Legacy Modernisation

Very large portion of the world’s business critical systems are considered to be ‘legacy’ –and so is the code underpinning them (ie COBOL, PASCAL, C, to name a few).  Although in many cases it is the case that these systems are robust, stable and fit for the main purpose they were originally built, they aren’t flexible and scalable enough to support emerging requirements mainly derived from a more demanding ‘always on the move’ and ‘always connected’ user.

These systems struggle to meet these demands mainly because of the ‘monolithic’ approach on which they were built and the complexity hidden in millions of lines of code that is only understood a very few hand-full of people that still remain active from the teams that several years ago developed these systems.

In almost an equal amount there have also been thousands of failed attempts to modernise these legacy systems. The ‘eating the elephant’ in one go approach certainly didn’t work, and the traditional SOA approach alone although worked till certain extend, it also fell short when it came down to addressing specific requirements around scalability and platform/service inter-dependencies.

In this presentation I talk about how a legacy modernisation framework based on Microservice Architecture (MSA) in conjunction with some other known SOA patterns (ie. ESB, API Gateway), can be applied to ‘eat the elephant one piece at the time’ but most importantly ‘without getting indigestion’.

I did this presentation at the AMIS Beyond the Horizon conference that took place near Amsterdam in June 2-3 2016. Thank you AMIS and Oracle ACE Director Lucas Jellema for the opportunity to present in what was a very unique and wonderful conference full of great people, knowledge and fun!

Friday, 13 May 2016

Converting ADLs to implement end to end JSON in SOA Suite 12.2.1 -PART I

There is no doubt that web [Rest] APIs have become extremely popular and its usage has gone well beyond just building APIs in support of mobile apps. We can see the adoption of resource-oriented architectures (ROA) by probably all SaaS vendors who provide out-of-the-box APIs as the means to connect and interact with their cloud applications. Take for example the Oracle Cloud. To discover and consume publicly available Oracle SaaS APIs, all one need to do is browse the Oracle API Catalog Cloud Service (which is publicly accessible) and just select the Swagger definition for any given API.

But (as you probably already know) the adoption of web APIs hasn't stopped there.  With the increased popularity of Microservice Architectures , initiatives such as Open Legacy ,  and node.js based frameworks like loopback and sails (to name a few), API-enabling system of records is becoming a lot easier.

This is putting a lot of pressure in software vendors to quickly modernise their integration suites to natively support the technology-stacks and patterns prevalent in these type of architectures. For example, if an organisations mobile application needs to interact with a system of record (on premise or the cloud) that already exposes a web API, the integration stack should be capable of supporting JSON over HTTP end-to-end without having to convert to XML back and forth. Not only is this impractical but introduces more processing burden to the core stack...

Luckily for many Oracle's customers and Oracle Fusion Middleware / Oracle PaaS practitioners like myself, with the latest release of Oracle SOA Suite (12.2.1) , one of the many new features introduced is the support for handing JSON end-to-end.  I don't want to understate the importance of this as with such feature it is possible to use BPEL for example to orchestrate several APIs (all in native JSON and also in-memory with the new SOA in-memory feature) and therefore deliver coarse grained business APIs that actually perform.

For me this represents an important milestone for Oracle SOA Suite as it shows the departure from traditional SOA tech-stack and into SOA 2.0 (as I like to call it) as the suite is now better suited to support the adoption of ROA, microservices, IoT, and so on. Having worked with SOA Suite since this is very exiting.

The catch

Unlike traditional SOAP services that make use of web service description language (WSDL) as the main mechanism to define a service interface (yes one can argue that there are different types like doc-literal, rpc-encoded and versions like 1.1, 2.0, broadly speaking they are similar and there is vast support for all of them), web APIs don't enjoy this mono-linguistic nature, in fact quite the opposite.

There is at least 8 different API description languages (ADL's) that am aware of. Some more popular than others but still in general all with substantial communities and vendor support:

Note: Suggest you go through this presentation for a good overview of the main ADL's

Oracle on the other hand didn't opt for endorsing or fully adopting any particular ADL. Instead it seems that conway's law came into action and different products currently support different ADLs.

Although I am sure that this inconsistency will go away in future releases, for us practitioners this sort of represents an immediate challenge. Even though all of the aforementioned do support REST/JSON in its purest sense, not being able to interpret an ADL automatically using an adapter basically means that one has to manually configure the URIs, resources, methods and parameters in a REST adapter in order to successfully consume the API.

Let's take for example the following Swagger ADL for the Oracle Field Service Cloud activities API (for which there isn't yet an out-of-the-box adapter in SOA Suite or ICS) :

If you clicked in the above you'll notice that tons of resources and methods are available (82 methods and 13 resources approximately). So imagine having to manually enter all of these in JDeveloper to configure the SOA Suite 12.2.1 REST adapter.. Yes possible but by any means practical. Far from it.

The solution

There is however a work around to this and its called API-Transformer

Developed by APIMATIC , API transformer is an online tool for converting ADL's and it supports the most popular formats (including all of the aforementioned ADLs):

Best of all is the fact that API transformer is also an API on its own right. Meaning that one could use this public API to build some sort of automation to facilitate the conversion between the Oracle supported formats.


APIs are great but the technologies and standards around it are still evolving. However the industry doesn't seem intimidated by this as the adoption of APIs continue to increase exponentially. Meaning that we practitioners are left having to deal with the complexity of adopting evolving paradigms without jeopardising the benefits that can be gained from their adoption. Luckily there are tons of open solutions out there that can be used to work around some of these complexities and API transformer is a good example of such.

In part II of this article I will show step by step how to consume an API defined in Swagger 2.0 from SOA Suite 12.2.1. For this I will transform the Swagger ADL to WADL, import it into a composite application using JDeveloper and the REST adapter and then implement end to end JSON to expose a generic API.

Sunday, 23 August 2015

Oracle API Management Implementation 12c Book Overview

Digital transformation is at the core of every business strategy regardless of what type of business an organisation is in. Companies that embark on a on a digital transformation journey are able to create innovative and disruptive solutions that are capable of delivering a much richer, unified and personalised user experience, at a lower cost. They are able to engage the customer in a seamless fashion through many channels such as mobile apps, responsive websites and social media. Organisations that adopt innovative digital business models gain considerable competitive advantage over those that don’t.

Why transform digital?

The fundamental driver for digital transformation is the ability to unlock key information assets and business functionality, which is often hidden inside an organisation’s enterprise systems and in SOA based web services which are only internally accessible. To materialise these assets, organisations need to build web based Application Programming Interfaces (APIs) that not only provide standard, lightweight web access to these assets but also do so in a secured and controlled fashion. The lightweight nature and ease of use of these web APIs, ensure that they soon become the main mechanism for accessing information and functionality that is needed to build mobile applications, responsive websites and other cloud based solutions.

Why API Management

API management is the discipline that governs the software development lifecycle of APIs. It defines the tools and processes needed to build, publish and operate APIs including the management of the community of developers around it.

API Management

Oracle API Management 12c Implementation is a complete and comprehensive guide to implementing API management in an enterprise. The book explains in great details how API management relates to other disciplines such as SOA governance and DevOps. It explains how and where SOA governance and API management converge giving rise to Application Services Governance (ASG). Very importantly, it uses real life case studies and many examples to show how to successfully define and implement a single and robust API management strategy with the Oracle API management solution.

Application Services Governance

The book starts by describing all of the fundamental concepts around API management and related disciplines such as SOA Governance and DevOps in order to dispel the confusion surrounding these topics.

All of these concepts are then put into practice by the elaboration of a realistic case study of an organisation, which had previously succeeded in the implementation of a SOA governance solution, and now needs to extend this with API management. During the elaboration of the case study it is explained:
  • The business requirements that lead to the identification of API management as a potential solution
  • All of the steps taken to define a API management strategy
  • Definition and execution of an API readiness assessment and gap analysis: in terms of people, tools and technology
API Management Strategy

  • Product evaluation and selection explaining why Oracle is the answer
APIM ProductSelection
  • API management implementation roadmap
API Management Implementation
The book goes on to show the steps required to implement the following API Management Reference Architecture using Oracle API Management solution (Oracle API Catalog, Oracle API Manager and Oracle API Gateway) to solve the specific business needs described in the use cases.

API Management Reference Architecture

In summary what you will learn from this book:
  • API Management, its concepts, goals and objectives
  • The differences and similarities between API Management and SOA Governance; where and how these two disciplines converge into Application Services Governance (ASG)
  • Application Service Governance (ASG) and how to define an ASG governance framework 
  • Elaboration of an API management strategy including: identification of business drivers, API management readiness assessment, gap analysis, creation of a digital reference architecture and elaboration of an implementation roadmap 
  • Definition and execution of an API readiness assessment and gap analysis: in terms of people, tools and technology
  • Product selection criteria and evaluation - Why Oracle API Management?
  • Implementation of Oracle API Catalog (OAC) including topics such as OAC bootstrapping and harvesting using the shell and ANT harvester scripts and also from JDeveloper, OAC console, user creation and management, API metadata, API discovery and also how to extend the functionality of OAC using the REX API
  • Understand how to manage a set of APIs. Explain the general challenges of API Management 
  • Implementation of Oracle API Manager (OAPIM) including creation, publishing, management and deprecation of APIs, API runtime monitoring, API key generation, API subscriptions and API community management with the OAPIM portal
  • Understand the challenges for organizations looking to expose APIs to the external world. Identify common scenarios in this regard and how to solve them
  • Implementation of Oracle API Gateway (OAG) including creation of policies with different filters, OAuth authentication, LDAP configuration, REST/SOAP conversations and API deployment and testing
  • Definition of an Oracle API management deployment topology 
  • Installation and configuration of Oracle API Catalog (OAC), Oracle API Manager (OAPIM) and Oracle API Gateway (OAG)
The target audience for the book is Enterprise Architects, Solution Architects, Technical Architects and SOA and API consultants who want to successfully implement API Management using the Oracle API Management Solution products.

The book is now available for pre-order from the Packt website:

Tuesday, 18 August 2015

Installing MAF 2.1.2 and MCS Lab Utility on Mac (OS X Yosemite 10.10.4)

During the OFM Summer Camp for Mobile Cloud Service (MCS) it was all going very smooth. In fact too good!! until I had to set up MAF 2.1.2 in JDevleoper and configure the utility provided in the lab (maf-mcs-utility- At this point nothing worked…The fact that I use Mac didn’t make things easier either as most people were on Windows and the lab sort of assumed the same….. So after at least 6 hours banging my head against the wall I finally found a solution.

Word of Caution
I initially tried to make this work in an existing Jdeveloper 12.1.3 soaquickstart installation. I tried to set up MAF 2.1.2 in this environment (following the docs steps) and it got to the point that I was getting all sort of weird errors (many related to MDS not loading and others around compilation). So at this point I decided to do a full clean install of everything (including Java).
Below the steps:

  1. Uninstall JDK 1.8 or JRE 1.8 (if you don’t have a JDK installed yet) by following these instructions
    1. JDK uninstalling steps:
    2. JRE uninstalling steps:
  2. Download JDK 1.7 from:
  3. Download JDK 1.8 (for later use) from:
  4. Download JDeveloper 12.1.3 from:
  5. Install Xcode from
    1. If Xcode is already installed make sure SDK is installed by clicking on Xcode Menu > Preferences > Download
    2. If no simulator is installed, click on the latest simulator to install it
  1. Double click on jdk-7uxx-macosx-x64.dmg to install JDK 1.7
    1. Open a command prompt and check that it was properly installed by running java -version
  2. Open a command prompt and change directory to the folder where jdevsuite121300.jar was downloaded to.
    1. Then execute: java -jar jdevsuite121300.jar
    2. Follow steps as indicated. Make sure to take note of the Oracle inventory and Oracle home paths as you might need them later
    3. Also if you’re planning to run different installations of Jdeveloper, use a distinctive Oracle home (i.e. fmw1213-maf212)
  3. Open Jdeveloper and click on the menu Help > Check for Updates
  4. Tick on “Official Oracle Extensions and Updates” and click Next
  5. Tick on “Mobile Application Framework” then click Next
  6. Click on “I Agree” then click Next and finish
  7. Don’t restart JDevleper when prompt. Instead close it
  8. Now install JDK 1.8 by double clicking on jdk-8u51-macosx-x64.dmg
  9. Open Jdeveloper
  10. When prompted to enter JDK 1.8 enter the path which usually is "/Library/Java/JavaVirtualMachines/jdk1.8.051.jdk/Contents/Home" and click Ok
  11. Right click on ViewController from the projects window then select “Project Properties” then click on Libraries and Classpath. Make sure that the Java SE version is "MAF JDK 1.8 Compact 2 Profile”. If this is not the case chances are you will hit issues. You may try the following solution but there is no guarantee it will work
  12. Go to and click on “Downloads” to get file
  13. Unzip
  14. Open Jdeveloper (if not already opened)
  15. Using Jdeveloper open file <path where unzipped>/maf-mcs-utility-
  16. Click on the menu Jdeveloper > Preferences and then Mobile Application Framework > iOS Platform
    1. Click on the Browse icon and search for the folder "Automatically Add to iTunes” note that in my case it appeared as "/Users/luisweir/Music/iTunes/iTunes Media/Automatically Add to iTunes.localized” for some reason
  17. Click on menu Run Click on menu Build > Clean all
  18. Right click on ViewController and then click Run > iOS Simulator
  19. Hopefully the Simulator Window will open!! if it doesn’t, well, good luck finding a solution (and if you do, kindly add it to this blog for others to learn from it)
Lastly for instructions on how to set up the MAF Samsung emulator on Mac follow these instructions:

Thursday, 9 April 2015

A Word About Microservice Architectures and SOA

In this article I will talk about my first conclusions and my point of view regarding Microservice Architectures. As there is still quite a lot of confusion and debate out there on this topic, I will try to describe with my own words what Microservice Architecture is, how does it differ from typical Service Oriented Architectures (SOA) and what design principles and practices governs it.
What is a Microservice Architecture?
In the article written by Fowler and Lewis, Microservice Architecture is described as following::

Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies

The article overall it’s a fantastic piece of work (really suggest you read it). The way Microservice Architectures it’s defined opens up a few pandora boxes (in a good way I think) which I will talk about subsequently.
First of all, if you are familiar with SOA and it’s guiding principles this will seem very familiar (read for example: or Yet, if you noticed the highlighted texts, it’s not quite the same as what we are used to in traditional SOA. The truth is, wether we accept it or not, SOA architectures evolved around the adoption of certain design patterns (such as Enterprise Service Bus (ESB), canonical schemas, centralised contracts, -see for more) and the use of SOA specific infrastructures to build and deploy services and APIs became the approach of choice (note that the service vs API topic it’s not discussed in this post. For my view on this read
From my perspective, I would define Microservice Architecture’s as both 1) a design pattern and 2) a discipline for delivering services and APIs. To elaborate further based on my conclusions I can highlight the following guiding principles:

  • Delivering business focused and lightweight services/APIs that are truly design, built, deployed and executed independently of each other (meaning that in terms of infrastructure dependencies, they share very little)
  • Strong focus on people collaboration and communication as the main mechanism in the adoption of best practices and standards rather than common set of strict guidelines and standards that constraint the way services are define, built, deployed and maintained
  • DevOps (config management, deployment automation, CI, Continuous Delivery) as a fundamental building block rather than a value add
  • Scalability should be easy as services are very lightweight and stateless (The same service can run in many servers and DevOps makes the deployment process automatic and easy)
  • Doesn’t encourages the use of monoliths to deploy services (a monolith is for example an application server or an ESB). Services should run almost as demons
One can argue that SOA architectures can also satisfy the listed requirements as SOA it’s really an architecture paradigm that can be realised in different ways. I personally think this myself and I would regard Microservice Architecture as a SOA design pattern, however as per my previous point, comparing it with traditional SOA architecture’s there is a difference.

Microservices vs SOA
To make my point more clearer, I created the following diagram to compare the system layers in a traditional SOA infrastructure to a Microservice one:

Microservices Vs SOA System Layers
As it’s visible in the diagram, there are many similarities between the two, however there are three key differences, two of which are very obvious but one that is not  (there are more that you can deduce from the digram and all the links I’ve provided):

  • First of all, traditional SOA implementations have been built around the use of monoliths ( or as Microservices calls it: Monolithic Architecture pattern -read
  • In a Microservice Architecture on the other hand, services and APIs are built and deployed without almost any dependency on an underlying application server or application. This means that services run as processes of the OS and share very little in terms of underpinning application infrastructure. This is because in Microservices (as per the highlighted text in Fowler’s / Lewis's definition) services and APIs should ideally run independent from each other. Another good article for this is
  • The third one -not obvious, is around composition of services. Traditional SOA promotes the use of orchestration (i.e. BPEL) whereas Microservices encourages the use of choreography. The fundamental difference here is that in Orchestration you need an “orchestra director” that defines and manages the interaction logic between all services (basically the BPEL code that executes or even in SOA composites, the SCA file like composites.xml that dictates at runtime how components interact). Choreography is different. Is a design time mechanism to model service interactions and behaviours but then once a service is built and deployed they should “know what to do”. Think of it as a protocol. A good analogy: "Dancers dance following a global scenario without a single point of control" (

The following forum thread also provides a good point of view on the commonalities and differences of the two
Now that I’ve described some of the key differences, I want to make it more obvious by showing a piece of code for a service built following the Microservice Architecture pattern. The snipped is based on Node.JS (  Express (a lightweight app for Node - Do note that Microservices can b built in any technology (i.e. Java) so long that the guiding principles are adhered to. 

var express = require('express');
var app = express();
app.get('/wines', function(req, res) {
   res.send([{name:'wine1'}, {name:'wine2'}]);
app.get('/wines/:id', function(req, res) {
   res.send({, name: "The Name", description: "description"});
console.log('Listening on port 3000...');

(full example on
As it’s visible, this simple REST API is fully self-contained. It not only defines the resources that the API will provide and the HTTP verbs to use, but also defines the port the API will listen to. This basically means that this API will be self-contained and running in it’s own process. Fascinating isn’t it?
In regards to people, Microservice Architectures encourages the creation of multi-disiplinary teams that are organised around the capabilities that specific micro services will support, rather than creating different teams based upon for example the different technologies and layers involved in the creation of a single microservice. As per Conway’s law, the systems you build will be a reflection the organisation and communications structures you followed ( I’ve about this in In addition it is encouraged to have strong communication and collaboration mechanisms as this becomes the preferred way to share best practices and standard documents written ages go and available in somewhere in a forgotten content management system.
Furthermore DevOps/Contionus Delivery in Microservices really is a must-do rather than a value add. At the end of the day, DevOps main objective is to bridge the gap between development and operations team therefore delivering high degree of agility into the main software development lifecycle (SDLC) stages. For automation aspects of DevOps, below a nice diagram that can serve as inspiration on what tools can be used for each phase.

DevOps Tools
Microservice Architecture is NOT a silver bullet! - ESBs are still needed
I personally think ESB’s still have a role to play to bridge application integration gaps in large enterprises as “choreography” alone all become streamy challenging in such large landscapes. The need for a robust tool to handle message routing, complex transformation, enrichment, throttling, and virtualisation tasks is still very valid and needed. The truth is that large organisations have many systems, many of which are commercial of the shelf (COTS), others are legacy, and others bespoke. Solving this integration challenge its not an easy tasks and a combination of technologies and architectural approaches is usually needed.

ESB based SOA
I can see this same issue occurring with Microservices as inevitably the number of microservices will grow exponentially and without a doubt governance will become challenging. This is the reason why SOA Governance and API management tools exist. it is one choice to define the right governance model (strict or lose). Also common problems such as visibility, lack or reusability, dependency management, amongst other will still be there in micro services. Therefore leveraging SOA governance and API management tools such as service and API catalogs and enterprise repositories will add a lot of value in they will help solve some of the common governance challenges.
I personally think that Microservice Architectures add most value when use for the right use case. For example, to build systems and applications with a very well define system boundary. Not necessarily to address all of the integration needs in an organisation. In other words, I don’t think Microservice Architecture is a silver bullet. I see it as another very good pattern that can be used when it applies, but as everything if overuse, challenges will come for sure.

Coexistance of SOA and MIcroservices
Another excellent use case where Microservice Architectures can apply nicely is around Internet of Things (IoT) and Machine to Machine (M2M). This is because by default devices are constrained by default on it’s hardware capacity and although at the moment focused is mainly in sensors, there is a lot of value in also having devices expose functionality and data via lightweight APIs (using protocols like MQTT or AMQP). This will allow devices to either interact amongst them (and this can be modelled using choreography languages like WS-CDL for example) or take part in a broader IoT ecosystem where the device can take part in a broader business process.
Microservices for IoT
I definitely see a lot of benefits and value adds in Microservice Architectures. I like the fact that there is very clear boundary between services not only logically but also physically. I never liked the fact that if an ESB goes down all services running in it also get affected…For this reason I think that major SOA and ESB’s vendors will embrace the Microservice Architectures way and might end up extending existing tools somehow to support or partly support this paradigm  or creating additional tools into their suites to support the creation of micro services.
Microservices Bus
Finally I think that some of the forgotten specifications such as WS-CDL ( will get traction again as they do have a role to play in the Microservices world, or at least that is what I would like to think.

Hope you enjoyed the article :)

Sunday, 9 November 2014

Oracle API Catalog 12c Full Overview

Oracle has recently released Oracle Enterprise Repository (OER) 12c and Oracle API Catalog (OAC) 12c.I am particularly exited on the latter as it aims to simplify management of APIs and promises to be able to create catalog of your services and APIs rapidly. Furthermore, although OER 12c maintains the same richness as in OER 11g, this product is targeted to advance users that are in need to address more complex governance requirements whereas OAC it’s a light-weight version of OER however tailored to address specific use cases of API management such as cataloguing, discovering and rating APIs.
This blog is about my first impression when installing, configuring and using Oracle API Catalog. In the blog I provide all steps I followed to achieve these tasks and at the end I provide a summary of my experience and feedback of the product.

Installation Pre-requisites

  • Download Weblogic Server 12.1.3 and OER 12.1.3 software binaries from following link (note that OAC uses same OER installer)
  • You will need an Oracle Database installed (you may also download database from previous link). If you already have an environment with an Oracle Database available you can check supported versions from following link
  • Ensure you have installed JDK 7.0 Update 55 or later. You can download it from the following link:
  • Oracle API Catalog Home Page and Installation Guide:


Firstly install Oracle Database and Weblogic Server as per instructions.
Then continue with installation of OAC 12c as per following instructions:
Following key screenshots taken during installation of Weblogic Server and OAC and also some tips:
Installing Weblogic
- Launching Weblogic 12.1.3 installer
- Click Next and choose your FMW home (I’ve used /u01/fmw2 as I have SOA Suite 12c under /u01/fmw)
- Click Next and select “Fusion Middleware Infrastructure”
- Click Next and un-select option to get updates if this is a local or demo environment, then click Next and click Yes
- Click Install and then Finish if all goes well, otherwise check the logs for issues and retry
Installing OER binaries (OAC uses same installation binaries)
- Launch OER installer
- Click Next and select previously created FMW home (in my case /u01/fmw2) and click Next
- Click Next, Next again and then Install
- If all goes well click Finish, otherwise check the logs for issues and retry
Install Patches for RCU and Weblogic
- Instructions in following link  , below summary:
- Go to Oracle Support and download patch 18791727 (RCU COMPONENT FOR OER OAC)
- Run Opatch
- Check that it succeeds and if so apply Opatch for Weblogic
- Go to Oracle Support and download patch 18718889 (WEB SERVICES RUNNING ON WLS FAIL WHILE MAINTAINING SESSION)
- Run Opatch
- Check that it succeeds
- Run ./opatch lsinventory to ensure all patches were applied successfully
- Run <FMW_HOME>/oracle_common/bin/
- Click Next, then select “Create Repository” and “System Load and Product Load” and click Next
- Enter DB details and click Next and then Ok. Then select which schemas you wish to create. In my example I created schemas for both OER and OAC (ensure you use the right prefex. In my case I used “DEV” but you may used any other depending on what environment you are installing). Then click Next and Ok again
- Enter password for the schemas and click Next, check that all schemas are correct and click Next and then Ok twice
- Click Create
- Click Close if all goes successfully, otherwise check logs and try again
Extend Domain
- <FMW_HOME>/oracle_common/bin/
- Select “Create a new domain” and ensure you provide a meaningful name to the domain, i.e. oac_domain (this will not cause installation to fail but in future it might create confusion around what the domain contains and purpose of it). Then click Next
- Select the template for “Oracle API Catalog" and click Next. Don’t try select OER and OAC template simultaneously as it will won’t allow you!! I tried this too!
- Enter the admin credentials for Weblogic server and click Next
- Select Production if you want more robust security or Development if you wish credentials to be loaded from Use default JDK (you may change this setting in a real production environment)
- Enter the DB details and credentials for the OAC schema and click Next
- Test connection and if successful click Next
- Select “Administration Server” and “Managed Servers, Clusters and Coherance” and click Next. Specially ensure you don’t miss Admin Server!!
- Select “All Local Addresses” so admin server listens to all IPs available in the server. Also ensure you change admin server port if you have other environments installed in your machine. Then click Next
- Do the same for oac_server1. Select “All Local Addresses” and ensure port it’s not already used then click Net
- Click Next twice (as am doing a demo environment I have no need set up a cluster and pinned servers to a machine)
- Click Create
- If Domain creation is successful click Finish
- Start Admin Server and then oer_server1
- Check the following link for best practices on stopping and starting Weblogic admin and manage servers:
- Check post-installation steps for running OER diagnostic tool:


UI Look & Feel

Ok so finally the fun start!! we’ve done the installation and everything seemed to have gone smooth. Now let’s have a look at the UI:
- Once servers have  started open following url: http://localhost:8111/oac
- Enter default credentials (admin / weblogic1) then it will ask you to change credentials
- Home page looks very clean and nice. I can see that there aren’t as many options as OER and there is no “Asset Home Page” so I won’t be able to create/add assets from here. There isn’t an option either to create/modify Asset Types. OAC only support one asset type which is APIs.
- There are 2 other main pages: MyAPis and Admin
- The Admin page looks very similar to OER and the security model around users it’s similar to OER however there is no concept of “Projects” as there was in OER 11g.  I think this is a good thing as Projects could confuse non-experts users. If you are not familiar with this model, below is how OER 11g user security model looked like. In red entities that don’t apply for OAC so it should give a good idea of how users and departments can be configured

Harvesting API Assets

- Harverster is available under <FMW_HOME>/oer/tools. Unlike OER 11g, no need to unzip ! just configure HarvesterSettings.xml and start using it!
- Let’s configure HarvesterSettings.xml to connect to OER
- Run ./ as following to encrypt password in HarvesterSettings.xml
- Now let’s harvest a REST API by running “./ –file “<REST WSDL URL>”
Note: Harvester has several features available including harvesting OSB services and SOA Composite applications. For more detail info read the following page:

Discovering APIs

Now let’s go back to the OAC home page and let’s see if our API is registered.
- By default APIs harvested are not registered as “Published hence they don’t appeared in the home page. So to find the API select “All APIs” from dropdown menu as per below and click on search icon
- Now the harvested API (WADL file) appears in the search results. Click on the API to see more details
- On this page you can see all metadata associated with the API. Let’s edit the API by clicking the pencil icon
- Now from here we can change the status of API. From Active Status dropdown select “Published” and click save. Now API should show up in home page
- Yep, now is there.
- If you want to rate the API and add comments, you need to add the API to MyAPIs. To do this click again on API and then click on Folder icon
- Then go to the “My APIs” page, and from there click on the Comments icon. A popup will appear, from there rate your API and add your comments
- Go back to home page and you will see your 5 star API :)


  • Installation is comprehensive and I like the fact that RCU is part of Weblogic binaries. Although you had to apply 2 patches before you can run RCU and extend domain it’s pretty straight forward and well documented. In total it took me between 1hr and 1 1/2 hr to do core installation (bearing in mind that I used an environment with a DB already installed and I had already downloaded all binaries and patches needed)
  • Tools (in <FMW_HOME>/oer/tools) are already unzipped which makes it a bit easier to configure harvester
  • Encrypting password can be done directly against password in HarvesterSettings.xml which is very straight forward to do
  • Harvesters is the same as OER. So executing harvester is very straight forward and easy. Best of all a lot of the information available in my SOA Governance book for 11g will still be useful for OER 12c and OAC
  • Harvester supports REST APIs published with WADL files
  • OAC UI’s are very lean, user friendly and intuitive. There isn’t as many pages as OER and it is not possible to add assets or create/modify asset types from the console. However I think this is a good thing to keep the complexity low and focused at only cataloging APIs asset types
  • The “MyAPIs” screen I found very cool. Also the ability to rate the APIs and submit comments / reviews I think will be extremely useful is OAC is used for example as an external catalog for “customers of the APIs” to rate and comment on APIs
  • Admin page seems similar to OER however simplified as OAC has no concept of “Projects” (which I think is a very good thing). Also only basic access settings are available unlike OER where you can configure CAS (Custom Access Settings). Also other features such as Compliance Templates are also not available. Again this is not a bad thing as it adds to the point of keeping it simple
  • My recommendation to implementers and companies looking to adopt governance but that don’t yet have mature processes or tools, to start off by using OAC and as their SOA adoption and governance mature then incrementally start planning for a more complex governance implementation using OER 12c
  • All in all, OAC is the killer OER app. Installation process it’s smooth (even patching process is simple), UI is very clean, functionality is “fit for purpose” and harvester is as feature rich as one available in OER.