JavaEE and WildFly Module 1 course extract – Introduction

JavaEE and WildFly Module 1 course extract – Introduction


(upbeat electronic music) – [Voiceover] Welcome to
the JavaEE training course. I’m Matt Greencroft, one of the trainers at Virtual Pair Programmers, and I’ll be taking you
through this first module on Enterprise Java with Wildfly, which is approximately five
and a half hours of training. By the end of this module, we’ll have built together
a fully functionining production standard end-to-end system. We’ll have a client which
connects to a server, which talks to a database. I plan to produce two further
modules in this course. In the second module, we’ll be looking at other more modern ways to communicate between
a server and a client using web services. We’ll also look at using message queues in the second module. Then in Module 3, we’ll
be looking at using JavaEE to create web pages and we’ll also cover how to secure your JavaEE applications. Before I go any further, I should say that this
is the second iteration of Virtual Pair Programmers’
JavaEE training. We created the first version
of this course using JavaEE 6 and that version used
an application server called GlassFish. Now although at the time
of writing this course, the latest verson of JavaEE is JavaEE 7, almost all of the original course is still valid and still works. However, we decided to replace
it with this new version as there are a couple of
techniques that have changed in the latest version. But more importantly the
newer versions of GlassFish have some rather horrible bugs in them, which led to some real
difficulties for our students. So in this version of the course, we’ve chosen to work with a different application
server called WildFly. But if you’ve already studied the previous version of this course, then you’ll find that most
of the content is identical. There’s very little that has changed in this version of JavaEE. Everything we do in the course will be to professional standards. We’ll be using a very
simple set of requirements for our project just to keep things easy. But we’ll be creating fully functioning production-quality code so that you’ll be gaining
the skills you need to work on real live
developmment projects. Although we’ll be using WildFly as our application server on this course, all of the course is also
suitable for other servers, such as WebSphere or GlassFish. Before we start, I just need
to check that you’re okay with the prerequisites for this course. I’m assuming that you
have reasonable knowledge of standard Java. You’ll need to be comfortable
with writing classes, creating objects and
the basic Java syntax. If you’ve studied our Java
fundamentals training, then you’ll certainly
have all that you need. In later chapters we’ll
be working with a database and we’ll be using JPA, the Java Persistence API. We have a full course all about JPA here at Virtual Pair Programmers, and I’ve only touched on
the basics in this course. So if you’re not familiar with JPA, well, firstly don’t worry, you’ll be able to follow this course, and then maybe take the
JPA course later on. I’ve not assumed any knowledge
of JPA for this course. We also use a build script in this course, but again I’ve not assumed any
knowledge of build scripts, but we do have a Java build tools course here at Virtual Pair Programmers that you might want to study to learn more about this topic later on. Now we have worked really hard as we prepared this course to produce what I hope is going
to be an error-free course. But naturally a few mistakes
might creep in along the way so please do regularly check
the webpage for this course at virtualpairprogrammers.com. You’ll see a link there for
the errata for this course, which I’ll update with any known problems. In a moment I’ll explain how this first module is structured. But before that, I think
it might be sensible to talk about what JavaEE is and how it differs from standard Java. Towards the end of the 1990s, Java became popular as
a programming language for writing server side systems. That includes, for example, creating logic to control
complex web applications, and the server side of
client-server applications. In fact, if you’re going to develop a server application today, then you really will be choosing between either Java or Microsoft’s .Net platform. There are other server technologies. You can create websites
in all sorts of languages, and some of the JavaScript frameworks have been written to
create server applications. But most larger
applications will be written in either .Net or Java. So this course is all about
writing programs in Java to run on a server. As you’ll see the Java that we’ll write is the same Java that we
use in everyday programming. We’ll still be creating classes and we’ll still be using the so-called standard
edition Java libraries. All the syntax is the same for loops, if statements, interfaces,
classes and so on. But we’re going to need more than that to be able to write server side programs. We’re going to need a
server to run our code and we’re going to need that server to provide certain services to us. So what does a server
need to be able to do? Well, first and foremost,
for many projects the obvious answer will be it
needs to provide a database. We’re going to need to store our data in some kind of persistent
storage mechanism. Now to do that, we’re
going to need software. Obviously, we’ll need a database, but we’ll also going to need some kind of bridge to the database so that we can write Java code that will be able to insert data into database tables and to
query the database and so on. If we assume that we’re going to be writing an application for the web, as we will be in the third
module of this course, then we’re going to need
some kind of software to serve the webpages. We’ll need a web server. When we’re dealing with
transactions on the database, we’re going to need software
to support that as well. This is a called transaction manager. Now don’t worry if you don’t
know what transactions are or why we need software to do this. This is going to be explained
in detail in a later chapter. But it’s sufficient to say for the moment that transaction management
is quite a complicated job that the server needs to do. We might also need to secure
a server side application so that users need to log in
before they can do anything. This kind of feature isn’t present in the standard Java libraries
that you might be used to. So we’re going to need
some software on our server to do this for us. For many years now software
vendors such as Oracle and IBM have been providing software packages called application servers. It’s a slightly misleading term really. An application server
isn’t a piece of hardware, it’s a software product. What an application server does is it provides exactly the services that I’ve just described, a database, a web server, a transaction manager, a security system, and actually many more features as well. Now for many projects, an application server might be overkill. Certainly some application
servers are very expensive. Some projects could serve me well just use a basic web server. But many projects and
especially corporate projects will like the fact that
application servers are big and can handle a wide
variety of requirements. Also most application server vendors also provide support, consultancy, and insurance against problems, which big companies often appreciate. So an application server provides a variety of software tools and services that we can use when we’re
writing server side software. That’s great, but this did
lead to a serious problem through the late 1990s as many different software vendors were producing these application servers. Every vendor had a different feature set and every vendor had a
different set of APIs. By the way, if you haven’t
heard of the term API before, this stands for application
programming interface. It just means the interface
to a set of libraries. As a Java developer, we’re very familiar with
the standard Java API. That’s where we get the objects like string and array list from. Well, when working on
an application server, they would provide a
whole new set of libraries that you would have to learn the API for. But that meant that if I was working on an application server from IBM, say, I’d have to learn the IBM API. But then if I moved
companies onto a new project and they were using an
application server from Oracle, then I’d like have to learn
a whole new different API. Now this would be okay if there was just one
big vendor dominating and everyone in the Java
community used that one server. That’s the position that
Microsoft programmers are in. But the Java community recognized that this vendor lock-in
was a very bad thing, and that could eventually lead
to Java failing altogether. So the vendors got together and formed a new standard
for application servers. The idea would be that if a vendor wanted to produce an application server, and they wanted the Java
community’s stamp of approval, then they would have to do two things. They would have to implement
a specific feature set, so they would as a minimum provide, say, a web server, a transaction manager, a security system, and so on, but perhaps more importantly, they would also have to
provide a standard API for developers to use these features. So now Java programmers
could learn just one API and then they’d be able to
move from application server to application server
without having to learn a whole heap of new libraries. This standard was called J2EE, otherwise known as Java
2 Enterprise Edition. Remember that I’m talking
about the late 1990s here. You might remember that Java in those days was officially called Java 2. The Enterprise Edition
means, well to be honest, it doesn’t really mean anything. For me, a better term
would’ve been server edition because that’s what it is. It’s a set of libraries to enable us to write server side code. Enterprise is really one of
those corporate jargon terms that doesn’t mean very much. Now since then things have
moved on a little bit. The 2 has gone out of fashion, so officially the topic
we’re studying is JavaEE, the Java Enterprise Edition. The latest version at the time of recording this course is version 7, and that’s what this
course will be covering. So JavaEE is quite a strange thing. It’s not a new language. It’s not a new form of Java
that you have to pay for. It’s just a set of libraries
that allow us to write code that will run on any
compliant application server. But that does mean that in
order to write JavaEE code, you do need an application server. In the next chapter, we’re going to download, install, and configure one of
these application servers. We’ll be using what I believe is currently the most popular application server, which is WildFly from JBoss. I’m going to be using
Eclipse on the videos, but you can use any development
environment you like. I won’t be relying on any special tools. I’m going to do everything by hand so that we understand
everything that we need to know. In Chapter 3, we’ll learn all about Enterprise Java Beans or EJB. We’re going to build on
the work in this chapter throughout the course
so you’re going to learn that EJBs are central to JavaEE. In Chapter 4, we’ll study JNDI. This will allow us to access the server from clients all over the world. Knowledge of JNDI is useful
in a lot of different areas of Enterprise Java. We’ll build our first
client in this chapter, and we’ll create a
connection to the server. In Chapter 5, we’ll need
another chapter on EJB. This advanced chapter will
give you a good understanding of how EJBs are used in real projects. We’ll learn about local and remote EJBs and stateful beans. Chapter 6 goes a little further in how EJBs can be connected together using context and dependency injection. Then in Chapter 7 we’ll start to use databases for the first time. In this chapter, we’ll
introduce the JPA library, or the Java Persistence API. Chapter 8 shows you how to
use JPA on the WildFly server, and this is a big part of the course because really from here
you’ll start to build a more serious architecture. Chapter 9 talks about transactions. This is one of the few
chapters on the course where there’s a lot of theory, a lot of talking, and not much code. But there are lots of
very important things you’ll need to know here. Chapter 10 continues with the same topic. This time we’ll be looking at
rollbacks on a JavaEE server, what to do when things go wrong. Before we start Chapter
2 I want to just mention our case study that we’ll be
working through in this course. We’re going to be building a simple employee management system. In this module all the system will be is a way of recording information about our company’s employees. We’ll have features to add, edit, and delete an employee, for example. I’m keeping the case study simple so that we can concentrate on
the code that we’re writing. But this is going to be a great
template for many projects that you’ll be creating as you continue developing JavaEE code. So let’s get started. I’ll see you in Chapter 2 where we’ll obtain and install
our application server. (update electronic music)

Leave a Reply

Your email address will not be published. Required fields are marked *