Edit Symbol List
Enter up to 25 symbols separated by commas or spaces in the text box below. These symbols will be available during your session for use on applicable pages.
Don't know the stock symbol? Use the
Symbol Lookup tool.
Alphabetize the sort order of my symbols
Investing just got easier…
Sign up now to become a NASDAQ.com member and begin receiving instant notifications when key events occur that affect the stocks you follow.Access Now X
Red Hat, Inc. (RHT)
August 10, 2011 12:00 pm ET
Kerri Catallozzi -
Issac Roth -
Bryan Che -
Mark Little - CEO of Spire Medical.
Previous Statements by RHT
» Red Hat Management Discusses Q1 2012 Results - Earnings Call Transcript
» Red Hat's CEO Discusses Q4 2011 Results - Earnings Call Transcript
» Red Hat, Inc. F1Q11 (Qtr End 05/31/2010) Earnings Call Transcript
Developers should be writing code, not dealing with the complexities of infrastructure, monitoring software, configuration software and application management, and they certainly shouldn't have to become skilled in the art and voodoos of database administration or the varied nuances of each and every infrastructure cloud.
Removing the complexity, we made great progress in that goal. Today, a developer can develop and deploy an application on the OpenShift cloud in under 10 seconds. And if the need arises, the auto scaling built in to OpenShift enables the application to take advantage of the elastic scalability offered by the cloud.
For the last 15 years, Red Hat has been developing the open source infrastructure and middleware that powers most major clouds and tens of thousands of enterprises globally. So building and running the OpenShift service draws right from Red Hat's core strengths of scalable, secure, reliable enterprise architecture, and it's been fun as well.
Our industry is going through an inflection point, with applications no longer being solely written for deployment on private networks and desktops. Today's developers need to be skilled in development, deployment, security, multi-tenancy and management of applications on the public cloud. By taking advantage of OpenShift, they'll leverage Platform-as-a-Service capabilities that solve these very problems, and they will have a partner in Red Hat who holds dearly collaborative development of open source and all the freedoms it affords as a core corporate tenet.
Removing complexity, the speed to deploy apps in seconds, developers are also very passionate about their preferred language, which is why at launch, we supported PHP, Ruby and Python, all very popular languages for web applications. Since launch, we also added Perl to improve our support for LAMP development. But some of the most demanding enterprise applications are written in Java, with one of the powerful aspects of Java being its adherence to a uniform standard for application interoperability and platform independence.
Today, Red Hat has reached another milestone in OpenShift with a full support for the JBoss Application Server, and not just JBoss but the next generation built around the Java EE 6 standard, an industry first in bringing standards to the public cloud, making it easier for enterprises to migrate their Java applications to the cloud and giving developers even more choice. Now developers can choose their language: Ruby, PHP, Python, Perl or Java.
Mark Little leads the JBoss engineering team for Red Hat, and he's now going to take you through more of the details.
Thanks, Bryan. So I'm going to, as Bryan said, talk about the integration that we've been doing with AS 7.0 and OpenShift, Express and Flex. I'm going to start though by laying some groundwork on what AS 7 really is, at least in terms of Java Enterprise Edition 6.
So if we go to my first slide. So enterprise middleware is not a new thing. It's not like it suddenly came on the scene when Java was introduced back in 1996. Enterprise middleware can trace its heritage back at least 4 decades through the likes of DCE and CORBA and beyond that into bespoke vendor-specific implementations.
However, as Bryan pointed out, a lot of critical applications today are built on Java and are built on the Java EE standard. And EE 6 is the latest version of that standard. It was ratified by the open standard group, the Java community process late last year, and it's an important milestone. It's taken pretty much 11 years to get to EE 6. As I said, it is an open standard amongst a range of middleware vendors and obviously ourselves included.
It includes a lot of solid improvements in the core standard, building on EE 5 and previous versions of J2EE, but it also adds lots of nice new capabilities that are very critical, we believe, to improving developer productivity and as we'll see, critical to our offering in the cloud. And these include things like JAX-RS, which is the standard now for developing REST-based services in Java; CDI, which is Context and Dependency Injection; and Bean Validation. EE 6 has had very wide input from larger open source communities, not just ourselves, and the whole EE effort has been improving in terms of seeking much, much wider input than has been the case in previous versions. And in fact, several JSRs, predominately the ones that we ourselves have been running, have been worked entirely in the open, so not behind-closed-doors as was once the case.
Now EE 6 introduces something that we should spend a little bit of time just talking about, which is the concept of profiles, and this is a standard approach to what's often called the slimming problem. So if we go to the next slide. The reason I need to talk briefly about slimming is because, as you'll see in a couple of slides time, we've actually used this in our integration with OpenShift.
So one of the common perceived problems with Java EE in the past has been what's sometimes referred to as bloating, where there are an awful lot of capabilities that are needed by a certain set of enterprise applications like transactions, messaging security, et cetera, that may not be needed by other applications. Some apps may only be interested in messaging. They may only be interested in messaging and transactions and not security. But unfortunately, the way in which the J2EE standard was developed, you really -- if you wanted to be compliant with that standard, you have to provide everything to an end user, and this ended up with many people finding that they were being asked to use or deploy things that they really did not need.