Developing and deployment web services in Weblogic 14c

Daniel S. Blanco
5 min readOct 21, 2021

Today we are going to see how to create web services (both SOAP and REST), which must be deployed in an enterprise application container. Specifically in Weblogic 14c. In appearance, it is something simple, but it is also true that being a server owned by Oracle and not Open Source, sometimes it is a little tricky to find information. So we hope to clarify a bit its basic operation through this post.

We must remember that this type of server comes with a set of libraries that implement the Java and Jakarta EE specifications. This is one of the reasons why they are heavier than a simple servlet container. Apart from the fact that they include much more functionality associated with these specifications.

Therefore, when creating an application that we are going to deploy in Weblogic or another type of enterprise application container, we only need to indicate which APIs it implements. With the benefit that it is not necessary to add these implementations since they are already included in the server. This will simplify our pom.xml a lot. Where we indicate the APIs as provided scope a no need to include implementations. Following we can see an example of pom.xml for WebLogic 14c with the APIs included.

For the creation of the web services we do not really need so many libraries, but this list can serve us as a reference. For the SOAP service, we will need the jaxws-api library and for the REST service, we will need the javax.ws.rs-api library.

The main idea is that both services are very basic and work practically the same. The only difference being the annotations that will allow to being generated as SOAP or REST services.

We will start first with the oldest one, the SOAP service. The class that implements our service must have the @WebService annotation. To which we can indicate the name of the service. And each of the methods that we want to expose must have the @WebMethod annotation, to which we can also indicate the associated names. Example:

Once the service is deployed, we will be able to access its automatically generated WSDL through the following URL: http://localhost:7001/weblogicWS/BookSoapService?wsdl.

Now we will see how to make the REST service. For it, we will have to add at the class level the annotation @Path and indicate the main route of access to this service. This step is not completely necessary, since we can put directly this annotation to each method, but by putting it at the class level we avoid repeating part of this path. Then for each method, and depending on the operation to be performed, we must indicate the annotation associated with the HTTP method to be used. It can be @DELETE, @GET, etc. Furthermore, there are other annotations that can help us to obtain the information that travels in the call. Such as @CookieParam, @HeaderParam, @PathParam, or @QueryParam.

Once the service is deployed, we can invoke it through the following URL: http://localhost:7001/weblogicWS/resources/book/1.

And once we have developed our web services, we are going to see how to deploy them. To do this, the first thing to do is to start up the server. This we can do it downloading it and installing it in our machine, through this link. Or, as it is usual nowadays and for development tests, we can get it up as a Docker instance. The latter will be the method we will see.

But in order to use a docker instance of the server we will need to perform the following steps:

  • Create an account on Oracle.com Network.
  • Access to the Oracle Container Registry page, log in with the account created in the previous step and accept the user license. If you do not see this license directly, access one of the images and it will appear on the top right.
  • Log in to the Oracle Hub using the command: docker login container-registry.oracle.com.
  • Download the desired image via the command: docker pull container-registry.oracle.com/middleware/weblogic:${TAG}. You can see the different tags here.

Now that we have downloaded the image, we need to mount a volume that allows us to indicate where our domain.properties file is located. This configuration file will mainly allow us to set the username and password. This can do it, through a command similar to this one:

docker cp weblogicWS.war wl14c:/tmp/weblogicWS.war

As we mentioned before, we can do it in several ways:

  • If we paste the file in the folder /u01/oracle/user_projects/domains/base_domain/autodeploy the file will be deployed automatically.
  • If we paste it into another folder through the Administration console page and the Deploy option after clicking the Install button. We will be able to select the path and file that we have copied previously and install it after selecting some options of deployments.
  • We can also deploy it through the weblogic.Deployer utility. Note that this option is not available in the development version.
docker exec -it wl14c sh
$ cd /u01/wlsdomain/base_domain/bin
$ . setDomainEnv.sh
$ java weblogic.Deployer -adminurl t3://localhost:7001 -user user1 -password welcome1 -name weblogicWS -targets base_domain -deploy /tmp/weblogicWS.war

Finally, we are going to show you how to configure the Oracle repository if you want to use it. To do this we must first have an Oracle.com Network access user, it can be the same one we use to download the images from the Oracle hub.

This user must be configured associated to the server in the settings.xml file located in the path: ~/.m2/settings.xml. As shown below:

nota bene: the password is encrypted. We’ve already seen how to do it, in this post.

And then we must add the Oracle repositories. These can also be indicated globally in the settings.xml file or specifically in each of the pom.xml of the projects that are going to use it.

And this is all, folks. Although we have not done much, we had to authenticate ourselves in Oracle and configure several aspects for the correct development and deployment of our applications. We have also compiled how to perform a complete process to do it on a Weblogic server. If you want to see the code of the application, as always, you have it here.

--

--