From the course: Java EE 7: Web Services

Course project and architecture - Java EE Tutorial

From the course: Java EE 7: Web Services

Course project and architecture

- [Instructor] In order to understand the process to develop and deploy web services using our local development environment, let's review the project and its architecture in more detail. The case study for this project is a bug tracking application called Trackzilla. Users of this system log defects or enhancements called tickets against an application. Trackzilla exposes the ability to create, update, delete, and query applications and tickets via web services. During this course we will create RESTful APIs and SOAP-based web services to aid in this process. Let's look at the MySQL database. If you've installed MySQL Workbench, let's navigate there. So let's look at the Trackzilla schema here. There are two tables, TZA application and TZA ticket. I've provided the database creation scripts for these tables as a part of the exercise files. So notice up here in this query window you can add a SQL statement, execute it, and actually see the data in your database. Let's review the deployment process. Typically, a RESTful resource is bundled in a war file along with other classes and resources. The web services are developed in IntelliJ and packaged in a war file. This is defined in the pom.xml file. The war file can be deployed two different ways. First, the war file can be manually deployed to the server using the server administration console option called deployments. Or IntelliJ can be set up to automatically deploy the war file to the WildFly application server for you. This is simply done via a Runtime configuration setup to build and deploy artifacts. Now let's navigate to IntelliJ and look at the source code. So first let's look at the Maven POM file and see our dependencies. So we have a Java EE7 dependency on lines 11 through 14. We have the MySQL connector J dependency on lines 17 through 21. And we have the RESTEasy Jackson two provider on lines 22 through 27. Let's look at the code. Notice here we have the main package which is called Keysoft. And underneath that package there are domain models in the model folder, application, and ticket. So let's look at application. Application represents applications and they have ID, name, and description. And then there's ticket, it represents tickets and tickets are either bugs or enhancements tracked against an application and they have an ID, title, description and status. I've used the WildFly configuration here to launch the server and deploy the app and I do this all through IntelliJ. So now that the application's deployed and it's up and running, let's look at Postman and test a few of the APIs. So Java EE7, that is the Postman collection. And I've exported this collection and made it available for import. It's a part of the exercise files and it's called JavaEE7.postman_collection.json. And so here we're able to test out the APIs that we create. Now that you've been introduced to the Trackzilla case study, let's start building it.

Contents