On May 2, 2017, we announced a new open source project called Syndesis.io. Syndesis.io provides a low code environment for agile integration. We also demonstrated key capabilities at the Red Hat Summit 2017 keynote.
Building on our foundational work in Syndesis.io, we have expanded those capabilities into a new product and are happy to announce Red Hat Fuse Online as a technical preview.
Red Hat 3scale API Management Platform simplifies the integration between the APIcast gateway and Red Hat Single Sign-On through OpenID Connect (OIDC) for API authentication. Consequently, the new version enables API provider users to select and configure their API authentication process from the admin portal UI.
Eclipse MicroProfile, an open forum to collaborate on enterprise Java™ microservices, today announced the release of Eclipse MicroProfile 1.2.
Eclipse MicroProfile 1.2, which builds on the 1.1 version, updates the config API and adds the health check, fault tolerance, metrics, and JWT propagation APIs.
**This post was updated on September 26, 2018.**
If you Google the term “agile integration,” you’ll come up with about 30 million results, but they focus heavily on one area: continuous integration within agile development. That definition of agile integration is based on the build environment.
However, it is possible to have another definition for “agile integration,” one that looks at the platform architecture.
In this definition, “agile” doesn’t relate to the process or the infrastructure, but to the flexibility and adaptability–the agility–of the application architecture. Integration within this context has a more strategic role, as the architectural framework that defines the interoperability of services and with a focus on the application functionality.
Check out this e-book to learn more about Agile Integration: The Blueprint for enterprise architecture.
There are functional similarities between traditional integration and agile integration – like routing, connectivity, and orchestration capabilities. The difference between traditional enterprise application integration and agile integration is not in the tasks performed, but in the strategic perspective of those tasks. Put simply, integration can be viewed as a necessary but often limited part of the infrastructure (traditional) or it could be viewed as the core framework of the application architecture (agile).
If you’ve been following the news about Oracle’s new direction for Java EE, you’ll know that one of the motivations for changing the governance and process is to move Java EE forward in a more agile and responsive manner.
So it’s a good sign that within a month of initially announcing their intentions, Oracle (with help from IBM and Red Hat) have chosen the Eclipse Foundation as the future home for Java EE. You can read Oracle’s announcement here.
This is a pretty important, first, tangible step in moving Enterprise Java forward and it’s encouraging to see Oracle moving ahead at a rapid pace. Java EE is an established technology that many organizations depend on for their business critical applications. Java EE is also a large body of work with Technology Specifications, Reference Implementations and TCKs from multiple vendors and open source projects so there’s still a significant amount of work yet to happen – but this is a great start.
Oracle’s announcement to move Java EE to an Open Source foundation has already begun to energize the community, offering the opportunity to more quickly evolve the platform to meet modern workloads. The Eclipse Foundation will be significant enabler in that evolution and Red Hat fully supports Oracle’s decision. Eclipse already hosts many projects of a similar size and complexity as Java EE, and we’re confident that the many years of experience and expertise the Eclipse Foundation has with other Java technologies ensures that this will be a successful move.
MicroProfile is also an Eclipse Foundation project and Red Hat hopes this will make it easier to align Java EE and MicroProfile in the future. The MicroProfile project was started in June 2016 as a collaboration between Red Hat, IBM, Tomitribe, Payara and others in the Java community with the goal of making Enterprise Java more relevant to developers building cloud-native applications.
Red Hat is an Eclipse Foundation member and has worked with the Eclipse Foundation for many years on projects as diverse as JBossTools, IoT, Kapua, Vert.x and Che and we look forward to working with with Oracle, IBM, The Eclipse Foundation and others on the future of Java EE.
At this stage the future of Java EE looks brighter than it has for quite a while as Oracle, working with Red Hat, IBM, other vendors and the wider community to move the specifications, TCKs and overall innovation to an open source foundation. I think in general most people in the Java community see this as positive but there are a few naysayers, even more of them in other non-JVM areas. The common thread throughout is along the lines of “who cares these days?” or “it’s far quicker and easier to accomplish the same things with framework X or language Y, anyway.” I’m not going to try to address all of the concerns which have been raised because many of the comments I’ve seen have clearly been subjective and bordering on click bait. However, I’m writing this piece to reiterate some things I’ve said over the years and which remain just as relevant today, in my opinion
I want to start though by saying that in all of this I am trying to remain objective. Of course in my current role I and Red Hat have a vested interest in Java EE but if you’ve known me long enough over the years you’ll know that I’m also a scientist and as such I base my opinions on observations and facts born out by those observations. If a fact or piece of data goes against a theory then I don’t ignore it, I review and likely update or replace the theory to match the facts. I’ve changed my opinion on many things throughout my career and I’m sure I will do so again.
OK so back to Java EE. Does this move to open source help the wider community? Is Java EE still relevant or has it had its day like so many technologies before it? I’m not going to link to other things I’ve written on Java EE and its future over the years as they’re easily searchable through your favourite engine. But in short, many people forget that Java EE represents an evolution of essential middleware capabilities which many mission critical applications require. It’s had a lot of bad press since its inception, some of it accurate and some of it less so. I think one of its big failings is that, like my favourite topic of transactions, it has been used and misused in environments where it wasn’t really appropriate. No stack or framework is going to be applicable to every problem space and of course developers are going to get frustrated if they try it and find it wanting and failing as a result.
In Red Hat 3scale API Management, we can manage any HTTP(S)-based APIs – including REST and SOAP. With REST, it is particularly straightforward as individual URL paths usually map quite nicely to operations. By operations, we mean fine-grained tasks and services which providers may wish to a) get visibility into and b) apply control access to.
With SOAP, there is more of a challenge, as it is typical for multiple operations to share the same endpoint. Yet providers may still want to get the same visibility and control they get with SOAP as they get with REST.
I really dislike the term “legacy apps,” especially when it is used by vendors. It feels like they are calling my baby (i.e. my app) with a bad name. I love the quote by Martin Fowler, “All we are doing is writing tomorrow’s legacy software today.” I am certainly not advocating to stick to your old applications forever. All applications and systems have a life-cycle that goes from build to retire. Somewhere in between lies the stage of renewing the capabilities of the system, often named as modernization, enhancement, or rehab. This is the most important phase from the perspective of extending the life of the application and enhancing the long term value harvested from it.
In IT, each generational transition has called for modernizing and redesigning applications, business processes and IT infrastructure to exploit new technologies’ capabilities and efficiencies. App modernization isn’t carried out as a fashion statement or status symbol but for hard business reasons. Regardless of the era, the benefits of a periodic app overhaul include better performance, more features, greater usability, and higher reliability.
On June 13, 2017, SmartBear joined the Eclipse MicroProfile project, an open source community specification for Enterprise Java microservices. As someone interested in microservices, why is this news important?
Microservices and microservice architectures have been in vogue now for a couple of years and IT organizations are rushing to implement (or re-factor) their applications using these new ways of architecting and developing solutions because they are digital transformation enablers (together with CI/CD and containers, among others) that allow them to deliver solutions to the business at faster speeds than ever before. In addition, Java is still ranked as #1 or #2 in programming language use and Enterprise Java, in the form of Java EE specification and implementation, has been used to implement enterprise-grade applications for many years by developers, who can now apply their vast Enterprise Java experience to the implementation of microservices. The Eclipse MicroProfile open source project fulfills the need in the market for a specification for microservices for Enterprise Java that can mature and evolve commensurately with digital business requirements. Eclipse MicroProfile, as a specification for Enterprise Java microservices, leverages some of Java EE, such as CDI, JAX-RS, JSON-P (no need to recreate the wheel), and adds new APIs1 (config, fault tolerance, security, health check, metrics, etc.) for a complete specification to implement enterprise-grade microservices in Java.
As microservices are leveraged across business applications, consumed across organizational/departmental boundaries, or offered for external consumption (outside the firewall), their management can become unwieldy. Microservices enabling technologies, such as Red Hat OpenShift Container Platform, provide an integrated registry (OpenShift Container Platform can integrate with external registries as well) that ameliorates this situation. Another management option for microservices is an API management solution. The only entry/exit point in/out of a microservice is its API and an API management solution can manage APIs by applying policies (security, management, throttling, load balancing, etc.) to them, keeping track of them in an internal catalog and giving insight into their usage. This is why there is a strong synergy between API Management and microservices.
SmartBear Software, the company behind the popular Swagger/OpenAPI framework for defining and creating RESTful APIs, has a long history open source API testing and development tools. There are many REST API description languages in the market, such as RAML, WADL, API Blueprint, WSDL 2.0, but Swagger/OpenAPI is widely recognized as the most popular open source framework for defining and creating RESTful APIs and has become the market de-facto standard, which means that any successful API-related solution must be either based in or provide support via translation to Swagger. As an example, a very successful API management solution is Red Hat 3scale, which supports Swagger/OpenAPI.
The success of any new technology hinges a lot on the ecosystem that surrounds it (or that it is part of). If it is diverse and rich in options then the technology will thrive and adoption will follow. By definition, microservices and microservices architecture encompass a large ecosystem of programming languages (they are language and technology agnostic, in fact), such as Java, Java EE, Go, PHP, Python, and platforms, such as Red Hat JBoss Enterprise Application Platform and Red Hat OpenShift Application Runtimes (RHOAR). However, a variety of microservices-enabling open source technologies have also come about in recent years, like WildFly Swarm, Vert.x, Node.js, OpenAPI, MicroProfile, Istio. So, the microservices ecosystem is growing and will continue to grow as businesses continue their digital transformation.
As mentioned above, there is a strong synergy and relationship between API management and microservices and SmartBear joining MicroProfile is bringing OpenAPI, the most popular REST API description language, into the MicroProfile ecosystem.
For more information on JBoss EAP, please see: https://developers.redhat.com/products/eap/download
For more information on RHOAR, please see: https://developers.redhat.com/blog/2017/07/06/openshift-application-runtimes
For more information on Red Hat 3scale, please see:
https://www.redhat.com/en/technologies/jboss-middleware/3scale/get-started
1 – New APIs are currently Work-In-Process or part of Eclipse MicroProfile roadmap
