UKOUG Midlands Tech Summit
20 Wednesday Feb 2019
Posted in General
Monthly Archives: February 2019
On Line Training – API Driven Architecture
15 Friday Feb 2019
Posted in General, Oracle, Packt, Technology
In January we presented our 1st online training, looking at API Design and use of Apiary and Swagger. Things went well until near the end where for some reason voice and video dropped for no apparent reason. Our coordinator Lindsay kept the recording going and soon as we reconnected I continued the session and went through the Q&A.
So if you missed the end of the training, please do check back with the recording.
If you missed the training – we’ll be rerunning in March – go here.
For those on the training will have seen at the start of the training links to my social media profile, so happy to try to respond to any further questions.
We are also scheduled to run the session again in a month or so.
One of the questions received during the session I thought worth mentioning was when would Apiary support Open API 3.0. Well according to their blog very soon, looking forward to it as the OAS 3 does look a little cleaner.
Making Scripts Work with IDCS Deployed PaaS
09 Saturday Feb 2019
Posted in API Platform CS, APIs & microservices, General, Oracle, Technology
A while back I made some utilities I developed to help with managing the API Platform. At the time we didn’t have access to an IDCS based environment, so credentials worked using basic auth (I.e. user name and password). But with environments managed by IDCS tokens are used.
As a developer with a Java background I have to admit to liking Groovy over Python for scripting, not to mention for the API Platform groovy is part of the gateway deployment and SDK. Meaning it is readily available in its 2.x form (3.x is relatively recent and aligning to the latest Java idioms). We haven’t tested against Groovy 3.0
Thank you to Andy Knight for sharing with us some Java code which I adapted to be pure Groovy (removing external dependencies for processing JSON). The result is a script that can be taken can be taken and worked into other scripts (which is what we have done for our previously provided scripts – Understanding API Deployment State on API Platform, Managing API Policy Versioning in Oracle API Platform, Documenting APIs on the Oracle API Platform). But this script can be used to get a token and display it on the command line or write it to file. Writing tokens to files is generally not good practise, but as a temporary measure when working on developing scripts arguably a managed risk.
The script can be found at https://github.com/mp3monster/API-Platform-Utils/tree/master/getToken and all the details on using the script can be obtained by passing -h as a parameter. The important thing is to understand how to obtain the Client ID and Client Secret, the details of which are described at https://docs.oracle.com/en/cloud/paas/api-platform-cloud/apfad/find-your-client-id-and-client-secret.html
Oracle Developer Meetup – London Feb 19
05 Tuesday Feb 2019
Posted in Dev Meetup, development, General, Helidon, Oracle, Technology
Tags
developer, GitHub, Helidon, meetup, micro profile, Microservices, open tracing, Oracle, signatures
Last night was the first Oracle Developer Meetup in London for 2019. We were very fortunate to have Tomas Langer fly over to talk about the new micro container/framework being developed as an open-source solution by Oracle.
Tomas, opened by explaining the evolution of the micro-profile being championed by the Eclipse Foundation who are now the guardians of J2EE also known as Jakarta and how the J2EE and Micro-Profile standards compare (in simplistic terms – micro-profile is J2EE stripped back to be simple and support what is typically needed in a micro-service world).
The presentation then went onto compare Helidon SE and Helidon MP (micro-profile). What was really pleasing is that with a couple of exceptions everything that Helidon MP can do, can be done in the SE edition, the difference being that for SE you have to implement more code, rather than the auto-magic of annotations, but in return you have a Reactive Java platform with a development paradigm which relates to JavaScript Express.
In addition to talking about what can be done, Tomas described the kinds of features being developed, this includes:
- Bringing micro-profile support up to the very latest specification,
- More reactive persistence technologies support,
With the scene set, Tomas then worked through a series of live code scenarios starting with a clean slate and building Hello World in both the SE & MP models illustrating the differences in approach. This was then built upon to add the following capabilities:
- Tracing (using Zipkin leveraging the Open Tracing Standard)
- Dynamic configuration
- Security (including Signatures)
- Fault Handling (just MP)
You can get the complete example which uses Helidon in both configurations from Tomas GitHub.
In addition to Helidon itself on GitHub, there are resources provided include rich documentation and examples of each key feature. Plus a Slack community, that if you contact any of the Helidon team will get you invited allowing you to discuss with the development team how to do things along with other developers using Helidon.
Tomas can be contracted via @Langer_Tomas. Helidon project also has its own Twitter account – Helidon Project
Helidon itself can be found at:
I have previously blogged on Helidon at Exploring Helidon – Part 1
API Caching with the Oracle API Platform
01 Friday Feb 2019
Posted in API Platform CS, APIs & microservices, General, Oracle, Technology
Tags
API, API-CS, cache-control, caching, Coherence, ehcache, forceResponse, Helidon, IETF, Oracle, proxy, Redis, RGC
We have been developing some advanced custom API policies for a client and in the process picked up on a few insights that didn’t even make into the API book. One of these policies is to provide an optimization around caching of API calls. The rest of this blog will talk about the tricks we have specifically applied to link an API Gateway to a caching mechanism and why.
Before I go into the details, I’d like to thank the Oracle product management team and particularly Glenn Mi at Oracle for their support getting through the deeper undocumented elements of the capabilities of the API Platform SDK.
Caching Options
Caching comes in may forms, and is motivated by varying reasons and not always the wanting the same behaviours. When getting into the subject of caching it is surprising how polarised people’s view points can be about which cache strategies are correct. The following diagram illustrates the diversity of caches that could appear in an end to solution solution.
Bringing together a caching technology in the Reverse Proxy model and an API Gateway makes a lot of sense. Data being provided to API consumers needs to be protected whether it comes from a cache or an active back-end system. At the same time you also want to exploit an API Gateway to provide analytics on API traffic, so any caching needs to be behind the gateway. But, if In front of an application layer then we can reduce the application workload.
When it comes to caching technology to partner with the gateway, there are a number of options available from Coherence to ehCache, memcache and Redis. We have avoided Coherence, whilst the gateway currently runs on a WebLogic server, we don’t want to need to unduly distort the performance profile and configuration of the Gateway by forcing a cache onto that server. In addition to which as Coherence is a licensed addition to WebLogic it raises difficult questions about licensing when deploying gateways (with gateways licensed based on logical groupings and API volumes but Coherence is licensed by OCPU). We also know that Oracle is moving towards having a micro-gateway which may mean we see the gateway engine moved onto something like Helidon (but this last point is my speculation).
We have elected to use Redis for several reasons –
- Available as a PaaS service with several cloud providers (AWS & Azure) so no setup or management effort but can also be deployed on-premises,
- Has an out of the box deployment that means cached entities can have a time to live (TTL) rather than needing to implement separate processes to expire cached values,
- The ability to make it scale through clustering,
- Cost
This caching model also allows us to optionally allow application development teams to push into the cache directly results. So rather than waiting on TTL the cache can be refreshed directly or even primed, rather than having to create fake requests to prime a cache.
