Oracle® Fusion Middleware: Understanding Oracle Weblogic Server 12.1.3 12C (12.1.3)
Oracle® Fusion Middleware: Understanding Oracle Weblogic Server 12.1.3 12C (12.1.3)
Oracle® Fusion Middleware: Understanding Oracle Weblogic Server 12.1.3 12C (12.1.3)
August 2015
This document provides an overview of Oracle WebLogic
Server 12.1.3 features and describes how you can use them to
create enterprise-ready solutions.
Oracle Fusion Middleware Understanding Oracle WebLogic Server 12.1.3, 12c (12.1.3)
E41937-04
Copyright © 2012, 2015, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it
on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,
any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users
are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and
agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and
adaptation of the programs, including any operating system, integrated software, any programs installed on
the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to
the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management
applications. It is not developed or intended for use in any inherently dangerous applications, including
applications that may create a risk of personal injury. If you use this software or hardware in dangerous
applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other
measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages
caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks
are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD,
Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced
Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content,
products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and
expressly disclaim all warranties of any kind with respect to third-party content, products, and services
unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its
affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of
third-party content, products, or services, except as set forth in an applicable agreement between you and
Oracle.
Contents
1 Introduction
1.1 Product Overview....................................................................................................................... 1-1
1.2 Programming Models................................................................................................................. 1-2
1.3 High Availability ........................................................................................................................ 1-3
1.4 Diagnostic Framework ............................................................................................................... 1-4
1.5 Security ......................................................................................................................................... 1-4
1.6 Client Options.............................................................................................................................. 1-4
1.7 Integration with Oracle WebLogic Suite ................................................................................. 1-4
1.8 Integration with Other Systems ................................................................................................ 1-5
1.9 Integration with Web Servers ................................................................................................... 1-5
1.10 WebLogic Server API Examples and Sample Application ................................................... 1-5
1.11 Upgrade........................................................................................................................................ 1-6
2 System Administration
2.1 Overview of WebLogic Server System Administration ........................................................ 2-1
2.2 Choosing the Appropriate Technology for Your Administrative Tasks ............................ 2-2
2.3 Summary of System Administration Tools and APIs ........................................................... 2-4
2.4 Roadmap for Administering the WebLogic Server System.................................................. 2-8
iii
3.1.3.5 Breadcrumb Navigation ............................................................................................. 3-5
3.1.3.6 System Status ................................................................................................................ 3-5
3.1.4 Using the Change Center ................................................................................................... 3-6
3.1.4.1 Undoing Changes ......................................................................................................... 3-6
3.1.4.2 Releasing the Configuration Lock ............................................................................. 3-6
3.1.4.3 How Change Management Works ............................................................................ 3-7
3.1.4.4 Dynamic and Non-Dynamic Changes ...................................................................... 3-7
3.1.4.5 Viewing Changes ......................................................................................................... 3-7
3.2 Using Fusion Middleware Control .......................................................................................... 3-7
3.2.1 Fusion Middleware Control Online Help ........................................................................ 3-8
iv
7.3.4 Coherence Deployment ...................................................................................................... 7-4
7.4 Roadmap for Deploying Applications in WebLogic Server ................................................. 7-4
v
12.1.3.3 Singleton Session Beans ............................................................................................ 12-3
12.1.4 Message-Driven Beans Implement Loosely Coupled Business Logic ...................... 12-3
12.2 EJB Anatomy and Environment ............................................................................................ 12-3
12.2.1 EJB Components ............................................................................................................... 12-4
12.2.2 The EJB Container............................................................................................................. 12-4
12.2.3 Embeddable EJB Container ............................................................................................. 12-5
12.2.4 EJB Metadata Annotations .............................................................................................. 12-5
12.2.5 Optional EJB Deployment Descriptors .......................................................................... 12-5
12.3 EJBs Clients and Communications ........................................................................................ 12-6
12.3.1 Accessing EJBs................................................................................................................... 12-6
12.3.2 EJB Communications........................................................................................................ 12-6
12.4 Securing EJBs ............................................................................................................................ 12-7
12.5 Roadmap for EJBs in WebLogic Server ................................................................................ 12-8
vi
Preface
This preface describes the document accessibility features and conventions used in this
guide—Understanding Oracle WebLogic Server 12.1.3.
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle
Accessibility Program website at
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Conventions
The following text conventions are used in this document:
Convention Meaning
boldface Boldface type indicates graphical user interface elements associated
with an action, or terms defined in text or the glossary.
italic Italic type indicates book titles, emphasis, or placeholder variables for
which you supply particular values.
monospace Monospace type indicates commands within a paragraph, URLs, code
in examples, text that appears on the screen, or text that you enter.
vii
viii
1
Introduction
1
This chapter provides an overview of Oracle WebLogic Server 12.1.3 features and
[2]
describes how you can use them to create enterprise ready-solutions.
This chapter includes the following sections:
■ Section 1.1, "Product Overview"
■ Section 1.2, "Programming Models"
■ Section 1.3, "High Availability"
■ Section 1.4, "Diagnostic Framework"
■ Section 1.5, "Security"
■ Section 1.6, "Client Options"
■ Section 1.7, "Integration with Oracle WebLogic Suite"
■ Section 1.8, "Integration with Other Systems"
■ Section 1.9, "Integration with Web Servers"
■ Section 1.10, "WebLogic Server API Examples and Sample Application"
■ Section 1.11, "Upgrade"
Introduction 1-1
Programming Models
other failures. New diagnostic tools allow system administrators to monitor and tune
the performance of deployed applications and the WebLogic Server environment itself.
You can also configure WebLogic Server to monitor and tune application throughput
automatically without human intervention. Extensive security features protect access
to services, keep enterprise data secure, and prevent malicious attacks.
Figure 1–1 shows how WebLogic Server fits into the overall Oracle Fusion Middleware
stack.
■ Enterprise JavaBeans (EJB) provide Java objects to encapsulate data and business
logic.
■ Remote Method Invocation (RMI) is the Java standard for distributed object
computing, allowing applications to invoke methods on a remote object locally.
■ Security APIs allow you to integrate authentication and authorization into your
Java EE applications. You can also use the Security Provider APIs to create your
own custom security providers.
■ WebLogic Tuxedo Connectivity (WTC) provides interoperability between
WebLogic Server applications and Tuxedo services. WTC allows WebLogic Server
clients to invoke Tuxedo services and Tuxedo clients to invoke EJBs in response to
a service request.
■ Coherence provides distributed caching and data grid capabilities for WebLogic
Server applications.
■ Overview of WebLogic Server Application Development describes developer tools
and best practices for coding WebLogic Server applications.
In addition, WebLogic Server supports applications developed using the Spring
Framework, an open source application framework for the Java platform. Developing
and Administering Spring Applications for Oracle WebLogic Server provides an overview
of Spring and WebLogic Server support for developing and deploying Spring
applications. It also gives examples of how to write Spring applications for WebLogic
Server. See also SpringSource at http://www.springsource.org/.
Introduction 1-3
Diagnostic Framework
■ Overload protection gives WebLogic Server the ability to detect, avoid, and
recover from overload conditions.
■ Network channels facilitate the effective use of network resources by segregating
network traffic into channels based on the type of traffic.
■ WebLogic Server persistent store is a built-in, high-performance storage solution
for WebLogic Server subsystems and services that require persistence. For
example, it can store persistent JMS messages or temporarily store messages sent
using the Store-and-Forward feature. The persistent store supports persistence to a
file-based store or to a JDBC-enabled database.
■ Store-and-forward services enable WebLogic Server to deliver messages reliably
between applications that are distributed across WebLogic Server instances. If the
message destination is not available at the moment the messages are sent, either
because of network problems or system failures, then the messages are saved on a
local server instance and are forwarded to the remote destination once it becomes
available.
■ Enterprise-ready deployment tools facilitate deployment and migration of
applications from the development phase to a production environment.
■ Production redeployment enables enterprises to deploy a new version of their
application without interrupting work in progress on the older version.
1.5 Security
The WebLogic Server security architecture provides a comprehensive, flexible security
infrastructure designed to address the security challenges of making applications
available on the Web. WebLogic security can be used standalone to secure WebLogic
Server applications or as part of an enterprise-wide, security management system that
represents a best-in-breed security management solution. See "Overview of the
WebLogic Security Service."
includes highly productive development tools based on Oracle JDeveloper and Oracle
Enterprise pack for Eclipse, and fully integrated management for large-scale
administration and operations with Oracle Enterprise Manager. Taken together, the
development, runtime and management capabilities of WebLogic Suite provide the
foundation for implementing mission-critical enterprise applications.
WebLogic Suite contains the following server-side components:
■ Oracle WebLogic Server
■ Oracle Coherence
Oracle Coherence enables organizations to predictably scale mission-critical
applications by providing fast and reliable access to frequently used data. By
automatically and dynamically partitioning data in memory across multiple
servers, Oracle Coherence enables continuous data availability and transactional
integrity, even in the event of a server failure.
WebLogic Server includes a Coherence container that simplifies the management
and deployment of Coherence clusters and Coherence-based applications.
■ Oracle TopLink
Oracle TopLink builds high-performance applications that store persistent
object-oriented data in a relational database. It successfully transforms
object-oriented data into either relational data or Extensible Markup Language
(XML) elements.
Oracle TopLink is an advanced, object-persistence and object-transformation
framework that provides development tools and run time capabilities that reduce
development and maintenance efforts, and increase enterprise application
functionality.
Oracle TopLink includes support for EJB 3.0 in Java EE and Java SE environments,
as well as support for EJB 2.n container-managed persistence (CMP). You can
integrate Oracle TopLink with a variety of application servers, including Oracle
WebLogic Server, OC4J, SunAS, JBoss, and IBM WebSphere.
Introduction 1-5
Upgrade
where ORACLE_HOME is the directory you specified as the Oracle Home when you
installed Oracle WebLogic. As they become available, you can also download
additional examples.
Along with the code examples, two versions of a complete sample application, called
Avitek Medical Records (or MedRec), are installed when you install the examples, as
described above.
The original MedRec (which was included in previous versions of WebLogic Server) is
a WebLogic Server sample application suite that concisely demonstrates all aspects of
the Java EE platform. MedRec is designed as an educational tool for all levels of Java
EE developers. It showcases the use of each Java EE component and illustrates best
practice design patterns for component interaction and client development. MedRec
also illustrates best practices for developing applications on WebLogic Server.
The Spring version of MedRec, called MedRec-Spring is MedRec recast using the
Spring Framework. If you are developing Spring applications on WebLogic Server, you
should review the MedRec-Spring sample application. In order to illustrate how
Spring can take advantage of the enterprise features of WebLogic Server, MedRec was
rearchitected to replace core Java EE components with their Spring counterparts. The
functionality in the original version of MedRec is reimplemented using Spring in
MedRec-Spring. Refer to the MedRec-Spring sample for details.
To launch MedRec, run startWebLogic.cmd or startWebLogic.sh script from ORACLE_
HOME/user_projects/domains/medrec, where ORACLE_HOME is the directory you
specified as the Oracle Home when you installed Oracle WebLogic Server.
To launch MedRec-Spring, run the startWebLogic.cmd or startWebLogic.sh script
from ORACLE_HOME/user_projects/domains/medrec-spring, where ORACLE_HOME is the
directory you specified as the Oracle Home when you installed Oracle WebLogic
Server.
1.11 Upgrade
Tools and documentation are provided to help you migrate applications implemented
on earlier versions of WebLogic Server to the current WebLogic Server environment.
See the Upgrading Oracle WebLogic Server.
This chapter provides an overview of system administration for the WebLogic Server
[3]
12.1.3 component of your development and production environments.
This chapter includes the following sections:
■ Section 2.1, "Overview of WebLogic Server System Administration"
■ Section 2.2, "Choosing the Appropriate Technology for Your Administrative Tasks"
■ Section 2.3, "Summary of System Administration Tools and APIs"
■ Section 2.4, "Roadmap for Administering the WebLogic Server System"
Table 2–3 describes APIs that you can use to create your own management utilities.
Table 2–4 (Cont.) Roadmap for Administering the WebLogic Server System
Major Task Subtasks and Additional Information
Managing server and ■ Configuring network resources
network communications
■ Configuring Web Server functionality
■ Using Oracle WebLogic Server Proxy Plug-Ins 12.1.3
Configuring system ■ Administering JDBC Data Sources for Oracle WebLogic Server
resources
■ Administering JMS Resources for Oracle WebLogic Server
■ Configuring WebLogic transactions
■ Configuring the WebLogic Tuxedo Connector
■ Configuring the persistent store
Configuring and deploying ■ Deploying Applications to Oracle WebLogic Server
applications
■ Configuring Web applications
■ Configuring XML resources
■ Configuring resource adapters
■ Understanding WebLogic Web Services for Oracle WebLogic
Server
Monitoring your domain ■ Configuring and Using the Diagnostics Framework for Oracle
WebLogic Server
■ Monitoring Oracle WebLogic Server with SNMP
■ Configuring Log Files and Filtering Log Messages for Oracle
WebLogic Server
■ Developing Java EE Management Applications for Oracle
WebLogic Server
■ Using the Monitoring Dashboard
Configuring server ■ Understanding cluster architectures
environments for high
■ Setting up WebLogic Server clusters
availability
■ Using session replication across clusters
■ Using Work Managers to prioritize application execution
■ Avoiding and managing overload
Understanding the ■ Using the WebLogic persistent store
WebLogic persistent store
■ Configuring custom persistent stores
■ Tuning the WebLogic persistent store
Troubleshooting ■ Viewing the WebLogic Server Error Message Catalog
■ Tuning Performance of Oracle WebLogic Server
■ Troubleshooting common problems with clustering
■ Administering Node Manager for Oracle WebLogic Server
Reference ■ Administration Console Accessibility Notes for Oracle WebLogic
Server
■ Command Reference for Oracle WebLogic Server
■ SNMP MIB for Oracle WebLogic Server
■ WLST Command Reference for WebLogic Server
■ MBean Reference for Oracle WebLogic Server
This chapter introduces and describes the Administration Console and Fusion
[4]
Middleware Control for WebLogic Server 12.1.3.
This chapter includes the following sections:
■ Section 3.1, "Using the WebLogic Server Administration Console"
■ Section 3.2, "Using Fusion Middleware Control"
where hostname is the DNS name or IP address of the Administration Server and
port is the listen port on which the Administration Server is listening for requests
3. When the login page appears, enter the user name and the password you used to
start the Administration Server (you may have specified this user name and
password during the installation process) or enter a user name that belongs to one
of the following security groups: Administrators, Operators, Deployers, or
Monitors. These groups provide various levels of access to system administration
functions in the WebLogic Server Administration Console.
Using the security system, you can add or delete users to one of these groups to
provide controlled access to the Console.
For information about using WLST, see Understanding the WebLogic Scripting Tool.
Changes to dynamic configuration attributes become available once they are activated,
without restarting the affected server or system restart. These changes are made
available to the server and run-time hierarchies once they are activated. Changes to
non-dynamic configuration attributes require that the affected servers or system
resources be restarted before they become effective.
If a change is made to a non-dynamic configuration setting, no changes to dynamic
configuration settings will take effect until after restart. This is to assure that a batch of
updates having a combination of dynamic and non-dynamic attribute edits will not be
partially activated.
Note that WebLogic Server's change management process applies to changes in
domain and server configuration data, not to security or application data.
This chapter describes WebLogic Server domains, logically related groups of resources
[5]
for Oracle WebLogic Server 12.1.3.
This chapter includes the following sections:
■ Section 4.1, "Understanding Domains"
■ Section 4.2, "Organizing Domains"
■ Section 4.3, "Contents of a Domain"
■ Section 4.4, "Roadmap for Understanding WebLogic Server Domains"
How you organize your Oracle WebLogic Server installations into domains depends
on your business needs. You can define multiple domains based on different system
administrators' responsibilities, application boundaries, or geographical locations of
the machines on which servers run. Conversely, you might decide to use a single
domain to centralize all Oracle WebLogic Server administration activities.
Depending on your particular business needs and system administration practices,
you might decide to organize your domains based on criteria such as:
■ Logical divisions of applications. For example, you might have one domain
devoted to end-user functions such as shopping carts and another domain
devoted to back-end accounting applications.
■ Physical location. You might establish separate domains for different locations or
branches of your business. Each physical location requires its own Oracle
WebLogic Server installation.
■ Size. You might find that domains organized in small units can be managed more
efficiently, perhaps by different system administrators. Contrarily, you might find
that maintaining a single domain or a small number of domains makes it easier to
maintain a consistent configuration.
For development or test environments, you can create a simple domain that consists of
a single server instance. This single instance acts as an Administration Server and
hosts the applications that you are developing. The wl_server domain that you can
install with Oracle WebLogic Server is an example of this type of domain.
Although the scope and purpose of a domain can vary significantly, most Oracle
WebLogic Server domains contain the components described in this section.
support for failover and load balancing. These features are available only in a cluster
of Managed Servers. For more information about the benefits and capabilities of an
Oracle WebLogic Server cluster, see "Understanding WebLogic Server Clustering" in
Administering Clusters for Oracle WebLogic Server.
■ XML entity caches and registry of XML parsers and transformer factories.
■ Messaging services such as JMS servers and store-and-forward services.
■ Persistent store, which is a physical repository for storing data, such as persistent
JMS messages. It can be either a JDBC-accessible database or a disk-based file.
■ Startup classes, which are Java programs that you create to provide custom,
system-wide services for your applications.
■ Work Managers, which determine how an application prioritizes the execution of
its work based on rules you define and by monitoring actual run-time
performance. You can create Work Mangers for entire Oracle WebLogic Server
domains or for specific application components.
■ Work Contexts, which enable applications to pass properties to a remote context
without including the properties in a remote call.
This chapter introduces WebLogic Server clusters, groups of server instances running
[6]
simultaneously and working together to provide increased scalability and reliability
for WebLogic Server 12.1.3.
This chapter includes the following sections:
■ Section 5.1, "Overview of WebLogic Server Clusters"
■ Section 5.2, "Relationship Between Clusters and Domains"
■ Section 5.3, "Relationship Between Coherence and WebLogic Server Clusters"
■ Section 5.4, "Benefits of Clustering"
■ Section 5.5, "Key Capabilities of Clusters"
■ Section 5.6, "Objects That Can Be Clustered"
■ Section 5.7, "Objects That Cannot Be Clustered"
■ Section 5.8, "Overview of Dynamic Clusters"
■ Section 5.9, "Roadmap for Clustering in WebLogic Server"
resources and services used by applications and server instances include machine
definitions, optional network channels, connectors, and startup classes.
You can use a variety of criteria for organizing WebLogic Server instances into
domains. For instance, you might choose to allocate resources to multiple domains
based on logical divisions of the hosted application, geographical considerations, or
the number or complexity of the resources under management. For additional
information about domains see Understanding Domain Configuration for Oracle WebLogic
Server.
In each domain, one WebLogic Server instance acts as the Administration Server—the
server instance which configures, manages, and monitors all other server instances
and resources in the domain. Each Administration Server manages one domain only. If
a domain contains multiple clusters, each cluster in the domain has the same
Administration Server. All server instances in a cluster must reside in the same
domain; you cannot "split" a cluster over multiple domains. Similarly, you cannot
share a configured resource or subsystem between domains.
Clustered WebLogic Server instances behave similarly to non-clustered instances,
except that they provide failover and load balancing. The process and tools used to
configure clustered WebLogic Server instances are the same as those used to configure
non-clustered instances. However, to achieve the load balancing and failover benefits
that clustering enables, you must adhere to certain guidelines for cluster configuration.
Complete the Installing and Configuring Oracle WebLogic Server and Coherence before
using these Fast Track procedures.
7.3.1.1 Auto-Deployment
When running in development mode, WebLogic Server automatically deploys
applications copied into the /autodeploy subdirectory of the domain directory.
Auto-deployment is a simple and quick method of deploying an application for testing
or evaluation. See "Auto-Deploying Applications in Development Domains" in
Deploying Applications to Oracle WebLogic Server.
[9This
] chapter describes WebLogic Java Database Connectivity (JDBC) data sources for
WebLogic Server 12.1.3.
This chapter includes the following sections:
■ Section 8.1, "Understanding JDBC Data Sources."
■ Section 8.2, "Understanding Generic Data Sources."
■ Section 8.3, "Understanding GridLink Data Sources."
■ Section 8.4, "Understanding JDBC Multi Data Sources."
■ Section 8.5, "Roadmap for WebLogic Server Data Sources."
This chapter describes the Java Messaging System (JMS) in WebLogic Server 12.1.3.
[10]
client can transparently communicate with any WebLogic JMS destination that is
hosted in the same cluster as the client's connection host.
■ JMS modules: contain configuration resources, such as standalone queue and topic
destinations, distributed destinations, and connection factories, and are defined by
XML documents that conform to the weblogic-jms.xsd schema. For more
information, see "What are JMS Configuration Resources?" in Administering JMS
Resources for Oracle WebLogic Server.
■ Client JMS applications: either produce messages to destinations or consume
messages from destinations.
■ JNDI (Java Naming and Directory Interface): provides a lookup facility for JMS
connection factories and destinations.
■ WebLogic persistent storage: a server instance's default store, a user-defined file
store, or a user-defined JDBC-accessible store for storing persistent message data.
[1This
] chapter introduces the WebLogic Server security service and methods for
securing your WebLogic Server 12.1.3 environments.
This chapter includes the following sections:
■ Section 10.1, "Java EE 6 Security Feature Support in WebLogic Server"
■ Section 10.2, "Overview of the WebLogic Server Security Service"
■ Section 10.3, "WebLogic Server Security Service Architecture"
■ Section 10.4, "Managing WebLogic Server Security"
■ Section 10.5, "Oracle Platform Security Services (OPSS)"
■ Section 10.6, "Security for Coherence"
■ Section 10.7, "Roadmap for Securing WebLogic Server"
[12This
] chapter offers an introduction to WebLogic Server Web services for Oracle
WebLogic Server 12.1.3.
This chapter includes the following sections:
■ Section 11.1, "Overview of Web Services"
■ Section 11.2, "Anatomy of a Web Service"
■ Section 11.3, "Web Service Standards"
■ Section 11.4, "Roadmap for Web Services"
file that any consumer can invoke to access the banking Web service. As a result, a
consumer does not have to know anything more about a Web service than the WSDL
file that describes what it can do.
A Web service client (or consumer)--such as, a desktop application or a Java Platform,
Enterprise Edition portlet-- invokes a Web service by submitting a request in the form
of an XML document to the Web service. The Web service processes the request and
returns the result to the Web service client in an XML document.
The Web service client can send a request in the form of a Simple Object Access
Protocol (SOAP) message. SOAP is an XML messaging framework designed to allow
heterogeneous applications to exchange structured information in a distributed
environment. In turn, the Web service processes the request and returns the response
in a SOAP message.
You can also develop Representational State Transfer (REST) Web services, or
"RESTful" Web services. REST describes any simple interface that transmits data over a
standardized interface (such as HTTP) without an additional messaging layer, such as
SOAP. REST provides a set of design rules for creating stateless services that are
viewed as resources, or sources of specific information, and can be identified by their
unique URIs. A client accesses the resource using the URI, a standardized fixed set of
methods, and a representation of the resource is returned. The client is said to transfer
state with each new resource representation.
To secure the message exchange, the Web service may require credentials to access the
service, for example a username and a password, or encrypt the response.
Note: The EJB 2.1 and earlier API required that Local and Remote
clients access the stateful or stateless session bean by means of the
session bean's local or remote home and the local or remote
component interfaces. These interfaces remain available for use with
EJB 3.x; however, the EJB 2.1 Remote and Local client view is not
supported for singleton session beans.
For more information see "Create EJB Classes and Interfaces" in
Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
factory. For more information, see "Configuring EJBs to Send Requests to an URL"
in Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
You can specify the attributes of the network connection an EJB uses by binding the
EJB to a WebLogic Server custom network channel. For more information, see
"Configuring Network Resources" in Administering Server Environments for Oracle
WebLogic Server.
[14This
] chapter describes monitoring, diagnosing, and troubleshooting in WebLogic
Server 12.1.3.
This chapter includes the following sections:
■ Section 13.1, "WebLogic Server Diagnostics Framework"
■ Section 13.2, "Logging Services"
■ Section 13.3, "SNMP Support"
■ Section 13.4, "Custom JMX Applications"
■ Section 13.5, "Java EE Management APIs"
■ Section 13.6, "Roadmap for Monitoring, Diagnosing, and Troubleshooting in
WebLogic Server"
specific events. For example, you can use WebLogic logging services to report error
conditions or listen for log messages from a specific subsystem.
By default, WebLogic logging services use an implementation based on the Java
Logging APIs. However, you can reconfigure WebLogic logging services to use Log4j
instead. In addition, WebLogic Server also provides the Server Logging Bridge, which
provides a lightweight mechanism for applications that currently use Java Logging or
Log4J Logging to have their log messages redirected to WebLogic logging services.
Applications can use the Server Logging Bridge with their existing configuration; no
code changes or programmatic use of the WebLogic Logging APIs is required.
Table 13–1 (Cont.) Roadmap for Monitoring, Diagnosing, and Troubleshooting in WebLogic Server
Major Task Subtasks and Additional Information
Using SNMP with WebLogic Server ■ WebLogic Server SNMP agents
■ Security for SNMP
■ MIB module for WebLogic Server
■ Monitoring custom MBeans
■ WebLogic Server notifications
■ SNMP proxies
■ WebLogic SNMP command-line utility
Creating JMX applications to manage WebLogic ■ Developing custom management utilities with JMX
Server
■ Developing manageable applications with JMX
■ Programming WebLogic deployment
Learning more about the Java EE Management APIs ■ JMO hierarchy
■ JMO object names
■ Optional features of JMOs
■ Accessing JMOs
■ Accessing the MEJB on WebLogic Server
■ WebLogic Server extensions
[15This
] chapter describes code examples and sample applications that offer several
approaches to learning about and working with WebLogic Server 12.1.3. These
examples and sample applications are available through performing a custom
installation and selecting to install the Server Examples.
This chapter includes the following sections:
■ Section 14.1, "Overview"
■ Section 14.2, "Conventions"
■ Section 14.3, "Java EE New Examples"
■ Section 14.4, "Java EE 6 Examples"
■ Section 14.5, "Additional API Examples"
■ Section 14.6, "Avitek Medical Records"
■ Section 14.7, "Derby Open-Source Database"
14.1 Overview
This section provides an overview of installing and using the WebLogic Server code
examples.
This section contains the following topics:
■ Section 14.1.1, "Installing the WebLogic Server Code Examples"
■ Section 14.1.2, "Starting the WebLogic Server Samples Domain"
■ Section 14.1.3, "Running the WebLogic Server Code Examples"
Note: By default, the examples server uses port 7001 to listen for
incoming connections. The MedRec server also uses the same listen
port by default, which means that you cannot run both domains at the
same time without changing one of the listen ports. If you want to run
both domains at the same time, use the Oracle WebLogic Server
Administration Console to change the listen port of the examples
server to something other than 7001, and then restart it. You can then
run the MedRec server using its default listen port at the same that
you run the examples server.
14.2 Conventions
The following conventions are used throughout the instructions for the WebLogic
Server code examples:
■ The instructions generally are for Windows command shells. If you are using a
UNIX or Linux-based shell, substitute / for \ in path names.
■ ORACLE_HOME represents the directory you specified as the Oracle Home when you
installed WebLogic Server; for example, C:\Oracle\Middleware\Oracle_Home.
■ WL_HOME represents the top-level installation directory for Oracle WebLogic Server.
The default path is ORACLE_HOME/wlserver. (However, you are not required to
install WebLogic Server in the Oracle Home directory.)
■ EXAMPLES_HOME represents the directory in which the WebLogic Server code
examples are configured. The default path is ORACLE_HOME\user_
projects\applications.
■ DOMAIN_HOME represents the directory in which the WebLogic Server sample
domains are configured. The default path is ORACLE_HOME\user_
projects\domains.
Source files for the code examples are separated from the domain configuration files,
just as they should be in a real-world scenario. They are installed in the EXAMPLES_HOME
directory.
The DOMAIN_HOME\wl_server directory contains the WebLogic Server examples
domain; it contains your applications and the XML configuration files that define how
your applications and Oracle WebLogic Server will behave, as well as startup and
environment scripts.
The EXAMPLES_HOME\wl_server\examples\build directory contains client and server
classes required by the examples and Derby database.
The WL_HOME\common\derby directory contains Derby, a demonstration database that
the examples are configured to use. It also contains scripts that start and stop the
database. For more information about Derby, see http://db.apache.org/derby.
■ Servlet 3.0: Use annotations for servlets, filters, and listeners, handle file uploads
with multipart files, and use asynchronous servlet and request handling,
programmatic security, and servlet Web fragments.
■ For a domain, you can view the value of the <domain-version> element in the
domain configuration file, config.xml. For example:
<domain-version>12.1.3.0.0</domain-version>
■ In general, the best practice is for all server instances within a domain to be at the
same Patch Set Update (PSU) and Interim or One-off Patch level during
steady-state operation. However, there may be cases where server instances are
required to run at different PSUs and Interim or One-off Patch levels within a
domain. The primary examples include:
– When applying PSUs, Interim or One-off Patches in rolling fashion across
server instances in the domain. In such cases, the maintenance should be
applied to the Administration Server first, so that the Administration Server is
at the same PSU and Interim or One-off Patch level (or higher) than its
Managed Servers. For information, see "About Rolling Upgrade" in Upgrading
Oracle WebLogic Server.
– When there are specific requirements to run Managed Servers within a
domain at different PSU and Interim or One-off Patch levels in steady-state
operation. In such cases, the Administration Server should be at the highest
PSU level, so that the Administration Server is at the same PSU level or higher
than all of the Managed Servers. If Managed Servers within a domain are
running with different Interim or One-off Patches, it will not be possible to
apply a consistent set of Interim or One-off Patches to the Administration
Server. Because this maintenance complexity may be difficult to manage, the
general best practice is to use the same PSU and Interim or One-off Patch level
across all servers in the domain.
■ Server instances within a cluster or domain can run on any hardware and
operating systems as long as the hardware and operating systems are listed on the
Oracle Fusion Middleware Supported System Configurations page on Oracle
Technology Network. However, note that running clustered Managed Server
instances on different hardware and operating systems may impact load balancing
and performance. In general, the best practice is to run all Managed Servers within
a cluster on the same hardware and operating system.
■ If the WebLogic domain is part of an Oracle Enterprise Manager Cloud Control
installation, additional requirements exist regarding the combinations of
hardware, operating system, and JVMs, that may be configured in the domain. For
more information, see Oracle Enterprise Manager Cloud Control Administrator's
Guide.
For more information about WebLogic domains, see Understanding Domain
Configuration for Oracle WebLogic Server (note especially the section "Domain
Restrictions," which provides additional details about domain compatibility).