Java EE moves to Eclipse

Posted on:

Rich Sharples, Senior Director of Product Management, Red Hat

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.

The future of Java EE

Posted on:

Mark Little

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.

Continue reading “The future of Java EE”

Integrating SOAP based Web Services into Red Hat 3scale API Management

Posted on:

Tom Corcoran. Solution Architect at Red Hat.

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.

Continue reading “Integrating SOAP based Web Services into Red Hat 3scale API Management”

There is no magical OFF switch for legacy apps

Posted on:

Syed Rasheed, Senior principal product marketing manager, Red Hat

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.

Continue reading “There is no magical OFF switch for legacy apps”

Swagger/OpenAPI for Enterprise Java microservices

Posted on:

Cesar Saavedra, technical marketing manager, Red Hat, Inc

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

Low Latency API Management for Microservices framework Light-4-J – with Red Hat 3scale

Posted on:

Kavitha Srinivasan, Middleware Specialist Solutions Architect, Red Hat, Inc.

Tom Corcoran. Solution Architect at Red Hat.

In an earlier blog, we wrote about how very low latencies in Java-based microservices can be achieved through our plug-in wrapper. That solution was general in nature, applicable to any API service.

In this blog, we show that the plug-in wrapper is applicable to a specific microservices framework – the open source microservices framework Light-4-J. In particular, we took an implementation of a microservices chaining tutorial, built upon it, and applied our Java plug-in wrapper API management component to it.

As we stated in our first blog, this approach may be well used for a particular use-case, i.e. internal API traffic, typically microservice to microservice. Services exposed to external parties, outside the DMZ, can continue to use the API gateway deployment for its routing and security capabilities. And indeed this differentiates Red Hat 3scale from other vendors in that both the plug-in deployment and the gateway deployment are feasible.

Figure 1 – Plug-in approach: API Management intelligence and configuration are decoupled from traffic enforcement and reporting

Continue reading “Low Latency API Management for Microservices framework Light-4-J – with Red Hat 3scale”

Data and Architecture: Business Capability Future State How-To, Pt. 2

Posted on:

Jason Daube

Robert Amico

Scott Seim

The Future-State Business Capability Model How-To  is a series to help IT and architecture practitioners think about a few key steps to build a future-state business capability model to influence business and technology senior leaders and executive decision makers. Part 1 ran last week and looked at the first two steps to creating a strategy-defined project planning model: understanding the goals of the organization and determining the architectural scope model to use. This post explores the steps to actually defining and implementing your planning model. 

Step 3: Define the plan to develop your future state capability model

    1. Determine if your organization requires a current state capability model. If your organization does not have a current state capability model, this may be an easier exercise to initiate dialogue and understand the concept.
    2. Identify how the corporate goals and strategy are applicable to the future state lifecycle. If required, translate the corporate goal to the applicable lifecycle. For example, a Corporate Revenue Goal can be translated into order transaction volume, number of newly hired associates, number of marketing campaigns or new product launches.
    3. Determine your standard definitions to categorize your capabilities.  For example, Core vs. Differentiate is a foundational interpretation. Determine what capabilities are “core” (something required to keep our business running) vs “differentiating” (something that has a direct impact on our growth).  This is a helpful reference for modeling: CEB’s Business Architecture Handbook.

Continue reading “Data and Architecture: Business Capability Future State How-To, Pt. 2”

Red Hat Fuse a Certified Enterprise Integration Solution for SAP

Posted on:

Lis Strenger, Internet of Things marketing manager, Red Hat, Inc.

We are pleased to announce that Red Hat Fuse has recently completed the SAP certification process for BOR API Certification and Red Hat Fuse is now a SAP certified solution.

Red Hat Fuse is an open source, lightweight enterprise service bus (ESB). It delivers a robust, cost-effective, and modular integration platform that lets enterprises easily connect their disparate applications, services, or devices in real time. An integrated enterprise is able to provide better products and innovative services to its customers. A flexible architecture coupled with popular and proven integration tools enables Red Hat Fuse to integrate everything, everywhere.

Red Hat Fuse provides a certified enterprise integration solution with SAP, enabling Camel routes running in Red Hat Fuse to retrieve all business objects from the SAP business object repository (BOR), the metadata and documentation of their business application programming interfaces (BAPIs), and to invoke all the methods of a BAPI. In addition it provides a certified solution for invoking non-BAPI remote function modules (RFMs). The performance of Red Hat Fuse is certified to maintain multiple connections to SAP, handle the transfer of large amounts of data and to handle multiple concurrent calls to BAPI methods. In addition, Red Hat Fuse is certified to properly process any Unicode characters passed in remote function calls.

Continue reading “Red Hat Fuse a Certified Enterprise Integration Solution for SAP”

Red Hat JBoss Enterprise Application Platform 7.1 Beta Availability

Posted on:

Cesar Saavedra, technical marketing manager, Red Hat, Inc

The beta release of Red Hat JBoss Enterprise Application Platform 7.1 (JBoss EAP) is now available. JBoss EAP is Red Hat’s middleware platform, built on open standards and compliant with the Java Enterprise Edition 7 specification. JBoss EAP supports a modular structure that provides service enabling only when required, improving startup speed. Included in this minor release are a broad set of updates to existing features. In addition, the beta release provides new functionality in the areas of security, management, HA, and performance, such as a new additional security framework that unifies security across the entire application server, CLI and web console enhancements, and load balancing profile, respectively. Also included are additions to capabilities related to the simplification of components such as a new additional EJB Client library, HTTP/2 support, and the ability to replace the JSF implementation. With these new capabilities, customers can continue to reduce maintenance time and effort, simplify security, and deliver applications faster and more frequently, all with improved efficiency.

Here are some highlights of the JBoss EAP 7.1 Beta release:

Continue reading “Red Hat JBoss Enterprise Application Platform 7.1 Beta Availability”

Data and Architecture: Business Capability Future State How-To, Pt. 1

Posted on:

Jason Daube

Robert Amico

Scott Seim

Does your organization need to improve strategic investments and prioritize investments? Do you feel confident in the objectivity of your investment and spend decisions? Are you constrained with annual budget allocations and have to make tough decisions year-over-year with running the business work or “keeping the lights on” versus transformational projects?

Establish a process to integrate an environment of many complex organizational capabilities to simplify and inform specific business outcomes through a future-state business capability model.

Portfolio Planning Prioritization 1.0 (in our blog series) features a way to prioritize investments from a “bottoms-up” perspective, as featured in the figure. The prioritization model identifies current or upcoming projects based on strategic drivers (key elements that align to organizational strategy, key portfolio data, and business value/outcomes) and detractors (elements that reduce value based on longer time periods, cost, and organizational readiness). Although this model is a good way to make data-driven prioritization decisions for the portfolio, it does assume that the organization has identified the critical must-have business capabilities needed to advance the business.

Continue reading “Data and Architecture: Business Capability Future State How-To, Pt. 1”