Contents

Overview

The Oracle WebLogic Server (WebLogic Server) and Helidon integration enables interaction between a Helidon microservice application and an application installed on WebLogic Server.

The following integrations are explained in this document:

  • The REST services integration allows WebLogic Server applications and Helidon microservices to communicate through RESTful Web Service invocations.

  • The JMS integration allows Helidon microservices to publish and consume messages from WebLogic JMS Server.

  • The WebLogic Web Services integration allows Helidon microservices to interact with WebLogic Server applications through SOAP (Simple Object Access Protocol) Web Service calls from Helidon to WebLogic Server.

  • The WebLogic Server and Helidon integration allows secure communication between a WebLogic cluster-hosted application and a Helidon microservice application by implementing Single Sign-on (SSO) authentication using Oracle Identity Cloud Service (IDCS).

  • XA Transactions integration with MicroTx allows Helidon and WebLogic Server applications to participate in a two-phase commit.

Integration between Helidon and WebLogic Server is possible over numerous protocols, most notably RESTful Web Services, SOAP Web Services, and JMS. Both Helidon and WebLogic Server support Single Sign-on (SSO) authentication using Oracle Identity Cloud Service (IDCS).

REST Services Integration

Overview

The REST services integration with Helidon enables bidirectional REST calls between Helidon and WebLogic Server. RESTful integration between WebLogic Server and Helidon MP is easy to develop and maintain because both runtimes support JAX-RS for serving and calling the RESTful resources. With the Jakarta EE support, you can create the same RESTful resource or client, which will work in both environments.

JAX-RS Server

The JAX-RS resource is a simple bean with annotated methods representing routes and HTTP methods under a specific path. Annotated methods are invoked when a particular REST endpoint is called. All the mapping and routing are done by the actual implementation of the JAX-RS standard according to the JAX-RS annotations.

JAX-RS Example Resource
@Path("/greet")
public class GreetResource {

    @Path("/hello")
    @GET 
    @Produces(MediaType.TEXT_PLAIN) 
    public Response getHello
    () {
        return Response.ok("Hello World!") 
                       .build();
    }
}
Copied
  • Path of the resource.
  • HTTP method.
  • Expected response content type.
  • Returns the text payload with status 200.

JAX-RS is a very powerful tool where you can register your message body writers, readers, filters, or exception mappers. In both Helidon and WebLogic Server, Eclipse Jersey is used as the JAX-RS implementation.

For information about creating and deploying the JAX-RS RESTful resources in Helidon, see JAX-RS applications.

For information about developing and deploying the JAX-RS resources on WebLogic Server, see the Developing and Securing RESTful Web Services for Oracle WebLogic Server documentation.

JAX-RS Client

JAX-RS provides a convenient client API for calling the RESTful resources. The client enables you to prepare and execute the RESTful request call with a simple builder pattern API.

JAX-RS Client Example
Client client = ClientBuilder.newClient();
String res = client
    .target("http://localhost:8080") 
    .path("/greet") 
    .request("text/plain") 
    .get(String.class);
Copied
  • Creates a new WebTarget with the default root URL.
  • Prepares the request to a particular context path.
  • Sets the expected response content type.
  • Executes the GET request and blocks until the response is received.
  • Parameter sets the expected response payload type, available body readers are used for parsing to the correct response payload type.

Again, you can register your own message body writers, readers, filters, or exception mappers.

For information about developing and deploying JAX-RS clients on WebLogic Server, see the Developing RESTful Web Service Clients for Oracle WebLogic Server documentation.

References

JMS Integration

Overview

WebLogic Server provides Java Message Service (JMS) and acts as a messaging broker that is accessible even from outside the cluster. To access the WebLogic JMS Server from outside, a client library is required. The Helidon JMS connector for reactive messaging can be configured to use the Weblogic thin T3 client for either consuming or emitting messages.

You can obtain the Weblogic thin T3 client in the server/lib directory (WL_HOME/server/lib/wlthint3client.jar) of any WebLogic Server installation.

Example of Installing the Thin T3 Client Artifact to the Local Maven Repository
mvn install:install-file \
-Dfile=<JAR_FILE_PATH>/wlthint3client.jar \
-DgroupId=wlthint3client \
-DartifactId=wlthint3client \
-Dversion=1.0
Copied

Maven Coordinates

To enable WebLogic Server JMS integration with Helidon, add the following dependencies to your project’s pom.xml file:

Dependencies for Reactive Messaging with the Thin T3 Client
<dependency>
   <groupId>io.helidon.microprofile.messaging</groupId>
   <artifactId>helidon-microprofile-messaging</artifactId> 
</dependency>
<dependency>
    <groupId>io.helidon.messaging.jms</groupId>
    <artifactId>helidon-messaging-jms</artifactId> 
</dependency>
<dependency>
    <groupId>wlthint3client</groupId>
    <artifactId>wlthint3client</artifactId> 
    <version>1.0</version>
</dependency>
Copied
  • Dependency for Reactive Messaging.
  • Dependency for the JMS connector.
  • Dependency for the manually installed WLS thin client.

Usage

After adding the Maven dependencies, configure the Helidon JMS connector, including the JMS environment properties and the JMS resources, such as the connection factory, destination, and destination type.

The following example shows the helidon-jms connector configuration in the application.yaml configuration file.

Example of the Messaging Configuration with JMS Connector and the Thin T3 Client
wls-username: weblogic
wls-password: welcome1
wls-admin-url: t3://localhost:7001 
wls-cluster-url: t3://localhost:7003,localhost:7005,localhost:7007 

mp:
  messaging:
    connector:
      helidon-jms:
        jndi:
           jms-factory: qcf 
           env-properties: 
              java.naming.factory.initial: weblogic.jndi.WLInitialContextFactory
              java.naming.provider.url: ${wls-admin-url}
              java.naming.security.principal: ${wls-username}
              java.naming.security.credentials: ${wls-password}

    incoming:
      from-wls-q:
        connector: helidon-jms
        jndi.destination: queuejndi 
        type: queue

    outgoing:
      to-wls-q:
        connector: helidon-jms
        jndi.destination: queuejndi 
        type: queue
Copied
  • Admin server t3 connection URL.
  • Example of the WebLogic Cluster t3 connection URL.
  • Connection factory name.
  • JMS environment properties to look up resources.
  • Destination with the jndi. prefix is evaluated as the JNDI name, simple destination is evaluated as a CDI syntax.

For information about reactive messaging configuration, see Reactive Messaging Configuration.

After you have configured the Helidon JMS connector, you can use Helidon Reactive Messaging for consuming and sending messages.

Consuming Messages from WebLogic JMS Server
@Incoming("from-wls-q")
public void receive(String msg) {
    System.out.println("Process JMS message as per business logic" + msg);
}
Copied
Producing Messages to WebLogic JMS Server
@Outgoing("to-wls-q")
public PublisherBuilder<String> produceToJms() {
    return ReactiveStreams.of("test1", "test2");
}
Copied

For more information about setting up the JMS integration between Helidon and WebLogic Server, see Integrating WebLogic JMS with Helidon.

References

Web Services Integration

Overview

Helidon MP and WebLogic Server Web Services integration enables the Helidon microservice application to communicate with the WebLogic Web Service deployed in WebLogic Server.

Maven Coordinates

You can obtain the Weblogic thin T3 client in the server/lib directory (WL_HOME/server/lib/com.oracle.webservices.wls.jaxws-wlswss-client.jar) of any WebLogic Server installation.

Example of Installing the Client Artifact to the Local Maven Repository
mvn install:install-file \
-Dfile=<JAR_FILE_PATH>/com.oracle.webservices.wls.jaxws-wlswss-client.jar \
-DgroupId=com.oracle.webservices.wls.jaxws-wlswss-client \
-DartifactId=com.oracle.webservices.wls.jaxws-wlswss-client \
-Dversion=1.0
Copied

Add the installed com.oracle.webservices.wls.jaxws-wlswss-client.jar client artifact, as part of the Maven dependencies:

<dependency>
    <groupId>com.oracle.webservices.wls.jaxws-wlswss-client</groupId>
    <artifactId>com.oracle.webservices.wls.jaxws-wlswss-client</artifactId>
    <version>1.0</version>
</dependency>
Copied

Usage

Use the clientgen WebLogic Web Services Ant task from the com.oracle.webservices.wls.jaxws-wlswss-client.jar file, installed earlier to generate the client artifacts that client applications use to invoke the WebLogic Web Services from the target/generated-sources folder.

Add the maven-antrun-plugin plug-in to execute the clientgen Ant task during the generate-sources build phase:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <id>ws-client-gen</id>
            <phase>generate-sources</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <target>
                    <property name="wsdl-file">file://${basedir}/DynamicWSImplService.wsdl</property>
                    <property name="compile_classpath"
                              refid="maven.compile.classpath"/> 
                    <taskdef name="clientgen"
                             classname="weblogic.wsee.tools.anttasks.ClientGenTask"
                             classpath="${compile_classpath}"/>
                    <clientgen wsdl="${wsdl-file}"
                               wsdlLocation="${wsdl-file}"
                               destDir="${project.build.directory}/generated-sources" 
                               packageName="com.example.wlssoap" 
                               generateRuntimeCatalog="false"
                               type="JAXWS"
                               copyWsdl="false"/>
                </target>
            </configuration>
        </execution>
    </executions>
</plugin>
Copied
  • Look for the weblogic.wsee.tools.anttasks.ClientGenTask on the project compile path.
  • Folder for the generated client classes; should be added as a source folder.
  • Name of the package for the new client classes.

Use the build-helper-maven-plugin plug-in to add /target/generated-sources with the generated client classes as an additional directory with sources.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>build-helper-maven-plugin</artifactId>
    <version>3.3.0</version>
    <executions>
        <execution>
            <id>add-source</id>
            <phase>generate-sources</phase>
            <goals>
                <goal>add-source</goal>
            </goals>
            <configuration>
                <sources>
                    <source>${pom.basedir}/target/generated-sources</source>
                </sources>
            </configuration>
        </execution>
    </executions>
</plugin>
Copied

Because the client classes are generating to the folder recognized by Maven as additional sources, client classes can be used directly from your business code.

Example

You can create the RESTful Web Service to invoke the WebLogic Web Service with the generated client classes, as shown in the following example:

@Path("/helidon-client")
@ApplicationScoped
public class HelidonWSEEClient {

    @Inject
    @ConfigProperty(name = "remote.wsdl.location")
    private String remoteWsdlLocation;

    @GET
    @Path("/getWLSWebserviceResult/subtract/{y}/from/{x}")
    @Produces(MediaType.APPLICATION_JSON)
    public JsonObject invokeWLSWebservice(@PathParam("x") int x,
                                          @PathParam("y") int y) {
        DynamicWSImplService testService = new DynamicWSImplService(); 
        DynamicWSImpl testPort = testService.getDynamicWSImplPort();
        ((BindingProvider) testPort).getRequestContext()
                .put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, remoteWsdlLocation); 

        int response = testPort.subtract(x,y);

        return Json.createObjectBuilder().add("ws-response", response).build();
    }
}
Copied
  • Generates the client classes used from the business code.
  • Overrides the JAX-WS URL from the WSDL document used for generating the client classes.
  • Calls the actual JAX-WS operation.

References

Single Sign-On on OCI Integration

Overview

The WebLogic Server and Helidon integration can be secured with IDCS over the OIDC protocol. The authentication provides:

  • Access to the IDCS configured client application deployed in the WebLogic cluster.

  • Access to the Helidon REST endpoints configured with IDCS.

  • Access to the WebLogic application endpoints from the Helidon REST endpoints.

Maven Coordinates

To enable IDCS support in Helidon MP, add the Maven dependency to the pom.xml file as shown in the following example:

<dependency>
    <groupId>io.helidon.microprofile.jwt</groupId>
    <artifactId>helidon-microprofile-jwt-auth</artifactId>
</dependency>
<dependency>
    <groupId>io.helidon.microprofile</groupId>
    <artifactId>helidon-microprofile-oidc</artifactId>
</dependency>
<dependency>
    <groupId>io.helidon.security.providers</groupId>
    <artifactId>helidon-security-providers-idcs-mapper</artifactId>
</dependency>
Copied

Usage

To set up the integration between the WebLogic cluster applications and the Helidon application with Oracle Identity Cloud Service (IDCS), see Integrating Oracle WebLogic Cluster and Helidon Applications for SSO on OCI Using IDCS.

Configure the Helidon application to use IDCS as an identity manager:

idcs:
  url: ${IDCS_URI}:443
  client-id: "${IDCS_CLIENT_ID}"
  client-secret: "${IDCS_CLIENT_SECRET}"

wls:
  service:
    url: http://localhost:7001/wls-service

security:
  providers:
    - abac:
    - oidc:
        server-type: "idcs" 
        client-id: ${idcs.client-id}
        client-secret: ${idcs.client-secret}
        redirect: true 
        identity-uri: ${idcs.url}
        frontend-uri: "http://localhost:${server.port}"
        logout-enabled: true
        post-logout-uri: /
        propagate: true 
        outbound:
          - name: "propagate-token"
            hosts: [ "localhost" ] 

    - idcs-role-mapper:
        multitenant: false
        oidc-config:
          client-id: ${idcs.client-id}
          client-secret: ${idcs.client-secret}
          identity-uri: ${idcs.url}
Copied
  • Configure the OCID security provider to work with IDCS.
  • Enable redirect to the IDCS SSO login page.
  • Propagate the JWT token obtained from IDCS after logging in to the subsequent JAX-RS calls.
  • Hosts called by the JAX-RS client for which the JWT token can be used.

Helidon will redirect the clients accessing the protected JAX-RS resources to the IDCS login page. After a successful login, Helidon negotiates the JWT bearer token and maps the user’s roles to the current security context.

@Path("/helidon")
@ApplicationScoped
@Authenticated
public class HelidonResource {

    @Inject
    @ConfigProperty(name = "wls.service.url")
    private URI wlsServiceUri;

    @Inject
    private JsonWebToken jwt; 

    @Authenticated 
    @GET
    @RolesAllowed({"secret_role"}) 
    @Produces(MediaType.APPLICATION_JSON)
    public JsonObject getDefaultMessage(@Context SecurityContext secCtx) {
        var user = secCtx.userName();
        var isInRole = secCtx.isUserInRole("secret_role"); 
        var bearerToken = jwt.getRawToken(); // Manually access raw bearer token

        // Bearer token is propagated automatically no manual action is needed with JAX-RS client
        JsonObject response = ClientBuilder.newClient()
                .target(wlsServiceUri) 
                .request()
                .buildGet()
                .invoke(JsonObject.class);

        return Json.createObjectBuilder()
                .add("user", user)
                .add("is_secret_role", isInRole)
                .add("wls-response", response)
                .build();
    }
}
Copied
  • JWT token negotiated by Helidon with IDCS after successful login.
  • JAX-RS resource method accessible only by the authenticated users.
  • Roles a user needs to be authorized to use; roles are provided by idcs-role-mapper.
  • JAX-RS client call. The JWT token is added automatically when token propagation is configured.

While the JWT token can be injected directly and used in the JAX-RS resource for subsequent calls to the WebLogic IDCS protected resources, with proper configuration of the outbound token propagation, the token can be propagated automatically.

References

XA Transactions Integration

Overview

XA (eXtended Architecture) is a specification for distributed transactions. Helidon and WebLogic Server applications can participate in a single XA transaction, thanks to MicroTx (Oracle Transaction Manager for Microservices). MicroTx ensures consistency of XA transactions across WebLogic Server applications, Helidon microservices, and the JDBC resources deployed in both Helidon and WebLogic Server.

Note

At this time, MicroTx Free is offered for evaluation purposes only.

For information about downloading MicroTx, see Prerequisites.

Maven Coordinates

Add the following Maven dependencies to the pom.xml file, as shown in the following example:

<!-- MicroTx -->
<dependency>
     <groupId>com.oracle.tmm.jta</groupId>
     <artifactId>TmmLib</artifactId>
     <version>22.3.2</version>
</dependency>
<!-- Oracle UCP --> 
<dependency>
    <groupId>com.oracle.database.jdbc</groupId>
    <artifactId>ojdbc8</artifactId>
    <version>21.3.0.0</version>
</dependency>
<dependency>
    <groupId>io.helidon.integrations.cdi</groupId>
    <artifactId>helidon-integrations-cdi-datasource-ucp</artifactId>
</dependency>
Copied
  • Dependencies needed for XA with Oracle UCP

This dependency is used to refer to the MicroTx library that is installed using the following command:

mvn install:install-file -Dfile=<MICRO_TX_BINARIES_EXTRACTED_PATH>/lib/java/TmmLib-22.3.2.jar \
-DpomFile=<MICRO_TX_BINARIES_EXTRACTED_PATH>/lib/java/TmmLib-weblogic-22.3.2.pom
Copied

Usage

The MicroTx library looks for the tmm.properties configuration file on the application classpath.

oracle.tmm.TcsUrl = http(s)://<MICRO_TX_K8S_SERVICE_NAME>:<MICRO_TX_SERVICE_PORT>/api/v1 
oracle.tmm.TcsConnPoolSize = 15
oracle.tmm.CallbackUrl = http://<HELIDON_APP_K8s_SERVICE_NAME>:<HELIDON_APP_K8s_SERVICE_NAME>/<HELIDON_APP_CONTEXTPATH> 
oracle.tmm.TransactionTimeout = 60000
oracle.tmm.PropagateTraceHeaders = false
oracle.tmm.xa.Rmid = HELIDON-TX-RM-ID-FOR-MICROTX-TESTS
Copied
  • The MicroTx coordinator URL.
  • Refers to the Helidon Teller Application call-back URL along with the context path.
  • The Unique Id of the Resource Manager(RM). Make sure to replace the id value with the RM used in the application.

Each property can be overridden by its upper case snake case environment variable variant. For example: ORACLE_TMM_TCS_URL="https://microtx-service.local/api/v1";

Configure XA UCP datasource with Helidon UCP CDI extension.

oracle:
  ucp:
    jdbc:
      PoolXADataSource:
        localOrcl:
          URL: jdbc:oracle:thin:@127.0.0.1:1521/orcl
          connectionFactoryClassName: oracle.jdbc.xa.client.OracleXADataSource
          user: <db-username>
          password: <db-password>
Copied

Register the XA capable datasource with MicroTx.

@ApplicationScoped
public class MicroTxInitBean {

    @Inject
    @Named("localOrcl")
    private XADataSource localOrclDataSource;

    private void init(@Observes @Initialized(ApplicationScoped.class) Object event) {
        TrmConfig.initXaDataSource(localOrclDataSource); 
    }
}
Copied
  • Registers the XA data source with MicroTx at CDI container startup time.

MicroTx will use it for obtaining the XA capable connections.

@Inject
@TrmSQLConnection
private Connection connection; 

@POST
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public Response transfer(Transfer transfer){
    UserTransaction ut = new oracle.tmm.jta.TrmUserTransaction(); 
    try{
        ut.begin(true); 
        // business logic
        PreparedStatement statement = connection.prepareStatement("UPDATE fee SET amount=amount+? where account_id=?");
        statement.setDouble(1, transfer.getTransferFee());
        statement.setString(2, transfer.getFrom());
        if(statement.executeUpdate() <= 0){
            ut.rollback(); 
            return Response.status(500, "Fee deposit failed").build();
        }
        ut.commit(); 
        return Response.ok(transfer).build();
    } catch (Exception e){
        ut.rollback(); 
        return Response.status(500, "Fee deposit failed").build();
    }
}
Copied
  • Injects the XA capable connection managed by MicroTx.
  • Initializes TrmUserTransaction to demarcate transaction boundaries in the application code.
  • If your application only initiates the transaction and does not participate in the transaction, begin with false.
  • Rolls back the transaction.
  • Commits the transaction.

References