Tag Archives: Eclipse

Helidon and the embracing of micro services

24 Wednesday Oct 2018

Posted by in development, General, Helidon, Oracle, Technology

≈ 4 Comments

Tags

, , , , , , , , , , , , , ,

XEYO9H51_400x400Oracle have announced another Open Source project called Helidon (Helidon.io) as a microservices platform built on top of Netty (which is built around a contemporary async model). If you look at the literature you’ll note two flavours one called SE which aligns to the programming characteristics or Node.js – asynchronous. The other is MP which aligns to the rapidly evolving J2EE MicroProfile which essentially follows a coding style along the lines of J2EE annotations.

Whilst it is perfectly possible to run Helidon based solutions in either profile natively, it is clearly geared up for running in any Docker+Kubernetes style environments such as Oracle Kubernetes Cloud (OKE) or even ACCS. Helidon website provides the means to quickly package your solution into Docker.

In both SE and MP forms the dependencies are hugely stripped back compared to the giants of WebLogic, GlassFish (now EE4J with the handover of J2EE to the Eclipse Foundation.

It does raise a number of questions what are the futures of WebLogic and Oracle support of EE4J (some answers here, but no Oracle specific)? WebLogic has never been the fastest to align to the latest J2EE standards (EE8 standard released last year should be become available sometime this year for WLS – see here), but today it is so central to many Oracle products it isn’t going to disappear, will it just end up slowly ebbing away? Which would be a shame, I have heard it said by Oracle insiders that if the removing the end of one component could be sorted then WebLogic could be easily be configured to have a small lightweight footprint.

The other interesting thing is what is happening to Open Source and what it might mean for the future.  Up until perhaps 3 or 4 years ago the use of open source you would think of software made available on of a small group of key sponsored organisations such as Apache, Linux Foundation, Eclipse which through its governance framework, provided levels of equality and process. As a result, levels of quality, trust crucially married to strong level of use and contribution that meant that to extrapolate Linus’ Law – bugs could be weeded out quickly and easily.  However with the advent of services like GitHub, whilst it has become easier to contribute and fulfil Linus’ Law. It also means that it is very easy to offer a solution that is Open Source. But, doesn’t necessarily garner the benefits of Linus’ Law and the other preconceptions we often have about Open Source such as it is/can be as good as a commercial solution. After all, throwing code into GitHub does not guarantee many eyes/contributors. Nor does it assure the governance, checks and balances that an Apache project, for example, will assure.

It is important to say that I am not against github, in fact, I am very much pro, and use GitHub myself to host utilities I make freely available (here). The important point is we have to be more aware of what open source actually means, in each context and can’t assume it is likely to have a strong community driving things forward, and critically dealing with bugs, and ensuring quality assurance processes are realized.

Helidon joins a number of other offerings in this space such as Micronaut (also built on Netty). Micronaut takes a different approach to Helidon by adopting a strong inversion of control/injection approach. In and in some respects feels a bit like the earlier versions of JBoss Application Server (now known as WildFly) which had a small footprint and made good use of Spring. This is in addition to Spark and Javalin. There is a good illustration of the different servers from Dmitry Kornilov shown below and the associated article can be seen here (who also happens to the Lead Engineer for Helidon).

helidon_landscape

Unlike Spark, Micronaut and a couple of others, Helidon only supports Java today rather than JDK based languages such as Kotlin and Groovy for example but is the only solution that can cover both the Micro Profile and Framework domains. It also has a challenge in terms of getting established, Spark has been around since 2015. Javalin appeared in May 2017. The J2EE Micro Profile standard is also driving a lot forward progress, so getting established will continue to get harder. Liberty, another Micro Profile solution is based on IBM WebSphere and Thorntail has links to WildFly (more here). We hope that it will make good headway with a Reactive engine in the form of Netty and avoiding IoC or introspection from the core should mean it will be very quick (particularly during startup) but it needs to show its value differentiation and importantly build a strong community contributing to it.

We hopefully will get the chance to further experiment with Helidon and write more about it here.

Java EE Development with Eclipse 2nd Edition

06 Tuesday Oct 2015

Posted by in Book Reviews, Books, Packt, Technology

≈ Leave a comment

Tags

, , , ,

I have just been told that the 2nd Edition of Java EE Development with Eclipse has now been published.  This is another book that I have supported as a technical reviewer.  Looking forward to receiving my print copy so I can see how my suggestions and feedback have carried through to the final copy.

You can see the book on the Packt site with  https://www.packtpub.com/application-development/java-ee-development-eclipse-second-edition  or Amazon here

 

IMG_2232

Here is the finished article!

Push Notifications with a Bit of Java

24 Saturday Jan 2015

Posted by in Java Cloud, Oracle, Technology

≈ Leave a comment

Tags

, , , , , , , , , , , , , , , , ,

So continuing from my previous posts:

We’re going to use the Prowl API and create the equivalent classic “Hello World” App using the push framework – but cutting out the need for Growl etc.  For this blog post we’re not going to use the Oracle Java Cloud as we need to see the code working locally and get ready to promote the code to the cloud.  Once we’ve got some code working we can look at setting up the Java Cloud environment, package and promote what we have here using our IDE into the cloud environment.

As we’re cutting Java code now – you can obviously use your own preferred IDE, I’m going to use JDeveloper 12c if for no other reason than it being a huge improvement on 11g (download here) and I’ve become somewhat disappointed with Eclipse.  Whilst talking about IDEs;  you should be aware that Oracle provide an Oracle Cloud SDK which integrates with a number of IDEs to make some of the interactions with the cloud straight forward.

The SDK provides Ant and Maven scripts to help the build and deploy process – so we will be using those later, plus command line tools to help manage other activities, a number of code examples and HTML documentation.  To setup the SDK you will need to unpack the file into a folder and add that folder into your PATH environment variables. The bundle includes a readme that contains just enough to show what is required to get unpacked and make the command line tools work.

To download from Oracle you will need to setup an Oracle Technology Network (OTN) account – so if you don’t have one now is the time to create one – there is no cost to this, we’re going to need

We could use the REST based API that is provided by the ProwlApp, but at least to start with we’re going to follow the approach using a library to make using the API very simple. By using the API provided on SourceForge (jProwlAPI). Using an API will allow us to show the use of 3rd party libraries in the cloud deployment but also follows some of the Oracle ideas of offering ‘adaptors’ to simplify integration.

So you need to download:

So with this downloaded we are going to:

Setup an new Maven based project (or copy my file structure into place and import) using a maven quickstart archtetype (org.apache.maven.archetypes:maven-archetype-quickstart) . We will probably need to modify this later to leverage the full cloud capable archetype. This will build your project environment and retrieve a bunch of plugins you might need.

Next lets take a peak inside of the jProwlAPI download. You’ll see an example bit of java that shows how to fire the API.  Rather than tinker with this we have created a small package and JUnit test as we would if writing a proper solution created with the maven archetype.

PushedHelloWorld directory structure

We also need to make the JProwlAPI jar file available to the project. So we use maven pattern, and create a folder called lib and copy the jar file into it. We then add the lib folder to project setup.

 

 

pushedhello-RunConfig

To be able to create the deployable artefact we need to load the jar file into the local repository, which we can do with a command line instruction (presuming maven is also available by your PATH variable).

mvn install:install-file -Dfile=./lib/JProwlAPI-0.5.jar -DgroupId=prowl -DartefactId=JProwlAPI -Dversion=12.1.3-0-0 -Dpackage=jar

We’ll come back to the command line in a bit, but within JDeveloper the code I have provided needs 1 change from yourself – replace the references to –YourAPIKey– in the run execute command and in the JUnit class with your own key.

JDEveloper 12c Run Config

In the the ProwlProcessor class I have included a man in method so we can just execute the class to see things working. So having done that we can then repeat by running the class via the JUnit test. You should see the same result. When we we’ve deployed or class to the cloud we can use the JUnit test to invoke the cloud.

ProwlProcessor - main method

The last step, within the IDE we have been compiling to get the class, but not creating a deployable jar file. We could do this with the IDE but we would also in a real development condition be creating artefacts via a Continuous Integration tooling which will effectively fire the maven command line like interface. So let’s do that to create the jar files, using the following command:

mvn clean package

You should then see a folder created if not already there and a jar file reflecting the values in the POM file, that we can see below.

JDeveloper 12C - view of a simple POM

So we have enough now we could in theory deploy a jar to a weblogic container and fire it from a Unit test. In the next post we’ll deploy and execute the unit test, and throw a crude front end into the mix.