Identify two supported methods of deploying a JMS module to a domain.
A.
Create a module by using the administration console.
B.
Load a module into the WebLogic database.
C.
Include a module file within a web application archive.
D.
Include a module file within an enterprise application archive.
E.
Define a module within an existing JDBC module.
Explanation:
A: Main Steps for Creating Packaged JMS Application Modules
Follow these steps to configure a packaged JMS module:
If necessary, create a JMS server to target the JMS module to, as explained in “Configure JMS
Servers” in the Administration Console Online Help.
Create a JMS system module and configure the necessary resources, such as queues or topics,
as described in “Configure JMS system modules and add JMS resources” in the Administration
Console Online Help.
The system module is saved in config\jms subdirectory of the domain directory, with a “-jms.xml”
suffix.
Copy the system module to a new location, and then:
Give the module a unique name within the domain namespace.
Delete the JNDI-Name attribute to make the module application-scoped to only the application.
Add references to the JMS resources in the module to all applicable J2EE application
component’s descriptor files, as described in Referencing a Packaged JMS Application Module In
Deployment Descriptor Files.
Package all application modules in an EAR, as described in Packaging an Enterprise Application
With a JMS Application Module.
Deploy the EAR, as described in Deploying a Packaged JMS Application Module.D: JMS application modules can be packaged as part of an Enterprise Application Archive (EAR),
as a packaged module. Packaged modules are bundled with an EAR or exploded EAR directory,
and are referenced in the weblogic-application.xml descriptor.
The packaged JMS module is deployed along with the Enterprise Application, and the resources
defined in this module can optionally be made available only to the enclosing application (i.e., as
an application-scoped resource). Such modules are particularly useful when packaged with EJBs
(especially MDBs) or Web Applications that use JMS resources. Using packaged modules
ensures that an application always has required resources and simplifies the process of moving
the application into new environments.
Reference: Packaging JMS Application Modules In an Enterprise Application
“A” and “D” are correct answer.
C and D. You can deploy applications either as archived files or as exploded archive directories.
A and D
JMS module in a WAR is not be posible.
https://docs.oracle.com/cd/E23943_01/web.1111/e13738/overview.htm#JMSAD132
JMS modules are application-related definitions that are independent of the domain environment. You create and manage JMS resources either as system modules or as application modules. JMS system modules are typically configured using the Administration Console or the WebLogic Scripting Tool (WLST), which adds a reference to the module in the domain’s config.xml file. JMS application modules are a WebLogic-specific extension of Java EE modules and can be deployed either with a Java EE application (as a packaged resource) or as stand-alone modules that can be made globally available.
The main difference between system modules and application modules comes down to ownership. System modules are owned and modified by the WebLogic administrator and are available to all applications. Application modules are owned and modified by the WebLogic developers, who package the JMS resource modules with the application’s EAR file.
A,D