Skip Headers
Oracle® Cloud Using Oracle Java Cloud Service
Release 12.2

Part Number E27039-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

4 Developing Applications for Oracle Java Cloud Service

This section describes the types of applications Oracle Java Cloud Service (Java Cloud Service) supports. Think of each Java Cloud Service instance as a deployment target for applications using a set of Java Enterprise Edition (Java EE) 5, Java EE 6, and Oracle WebLogic Server capabilities.

Topics:

See Also:

Appendix A, "Java Cloud Service Features and Implementation Considerations" for information about supported and unsupported capabilities

About Oracle WebLogic Server and Oracle Application Development Framework Support

Think of each Java Cloud Service instance as a deployment target for applications using a set of Java EE release 5, Java EE release 6, and Oracle WebLogic Server capabilities. Note that Java Cloud Service only supports the following Oracle WebLogic Server and Oracle Application Development Framework releases:

Note:

All references in this document to WebLogic Server capabilities and ADF specific capabilities refer only to the releases specified in the previous list.

Understanding Application Infrastructure and Java Environment

As a Platform as a Service (PaaS) solution, the focus of Java Cloud Service is to automate the back-end infrastructure (that is, the operating system, virtual machine, Java EE container, and Java Cloud Service settings) as well as the provisioning and configuration process. Therefore, the infrastructure of the Java Cloud Service runtime is not directly exposed to its service users. In other words, Java Cloud Service is not an Infrastructure As A Service (IaaS) solution. However, certain aspects of the infrastructure can be managed through the My Services interface of the Java Cloud Service as follows:

Managing Application Security

This section describes how to secure Java EE and ADF applications targeted for a Java Cloud Service instance.

Topics:

See Also:

About Built-in Authentication

All Java EE and ADF web applications deployed to a Java Cloud Service instance are automatically secured. When users access an application deployed on Oracle Cloud the default authentication mechanism requests the following information:

  • User ID - The user name within the identity domain.

  • Password - A user password.

  • Identity Domain - The name of the identity domain to which the application being accessed has been deployed.

  • Data Center - The name of the data center associated with the user's identity domain.

Once logged in, users are authenticated for applications. By default (that is, if no specific configurations are defined), only users that have been authenticated through SSO can access a deployed application, but this includes users from any identity domain. A specific authentication method can be configured in the web.xml file, and it can vary from being publicly accessible to restricted to users within the same identity domain. (For more information about setting up proper access to applications, see "Updating web.xml" and Getting Started with Oracle Cloud.)

To learn more, see "Managing Service Users" in Getting Started with Oracle Cloud.

About Java EE Application Security

When securing a Java EE web application, you can specify application roles and security constraints within the application deployment descriptors or the application code. Application roles are mapped to enterprise roles defined within the Java Cloud Service's identity domain using the Identity Console. Implicit mapping is based on the role name. To learn more, see "Managing Service Users" in Getting Started with Oracle Cloud.

Topics:

Updating weblogic.xml

You map Java EE roles created using the Identity Console by updating the weblogic.xml file. In the weblogic.xml file, all identity role mapping elements must use the prefix <identity-domain-name>. Consider the following example:

...
<wls:security-role-assignment>
<wls:role-name>sales</wls:role-name>
<wls:principal-name>myidentitygroupfoo.WestCoastSales</wls:principal-name>
</wls:security-role-assignment>
...

In the previous example, the identity domain name is myidentitygroupfoo. (However, note that when WestCoastSales was created using the Identity Console, the identity domain name was not specified.)

Updating web.xml

Applications targeted to a Java Cloud Service instance can choose to participate in a Single Sign-On (SSO) with other applications deployed to services within the same identity domain. In order to enable SSO participation, applications must use a CLIENT-CERT authentication method as specified through their deployment descriptor's <auth-method> element and illustrated through the following web.xml deployment descriptor snippet:

…
<login-config>
  <auth-method>CLIENT-CERT</auth-method>
</login-config>
<security-role>
  <role-name>sales</role-name>
</security-role>

Applications using a BASIC or FORMS based authentication can also be deployed to a Java Cloud Service instance. However, such applications will not participate in SSO. Instead, their authentication will be local to the application.

All deployed applications without any explicit security elements in web.xml are set with default protection that allows anonymous access to any Oracle Cloud user. To prevent undesired access to your applications, you must set a proper user authentication method in the web.xml file.

The following are supported authentication configurations:

  • Fully secured application. This method is highly recommended. This configuration allows choosing which portion of the application is protected by SSO.

    In web.xml the auth-method element must be set to the value CLIENT-CERT as noted in the example below:

    <login-config>
            <auth-method>CLIENT-CERT</auth-method>
            <realm-name>default</realm-name>
    </login-config>
    

    You must also define the section of the application that needs to be protected by SSO. In the following configuration, all the URL patterns for the application are protected:

    <security-constraint>
            <display-name>name</display-name>
            <web-resource-collection>
                <web-resource-name>name</web-resource-name>
                <url-pattern>/*</url-pattern>
            </web-resource-collection>  
    </security-constraint>
    

    Only the URL patterns covered by a security constraint in a web-resource-collection element will prevent users from different identity domains, and external non-authenticated users. from accessing the application. All the directories that are not specified as a URL pattern will be accessible by SSO authenticated users (even if they are anonymous). Multiple security-constraint elements are allowed in web.xml.

    All applications participating in SSO must have a unique value specified for cookie-path in weblogic.xml, as follows:

    <session-descriptor>
            <cookie-path>myapp</cookie-path>
    </session-descriptor>
    

    Note:

    Specific application security configuration for SSO is highly recommended to enhance the security of your applications and prevent unwanted user access.
  • Public application. An application that completely requires public access without an SSO challenge must just include an empty <login-config/> element in web.xml.

  • Partially secured application. A partially secured application is one that has login-config and auth-method specified but the security collection elements do not cover all the sections of the application. This means the portions of the URL patterns that are not covered by any security-collection element are public. (This is a primary use case.)

About ADF Application Security

When securing a Java ADF application, you can specify application roles and security permissions within ADF application's jazn-data.xml file. Application roles are mapped to enterprise roles defined within the Java Cloud Service's identity domain. Implicit mapping is based on the role name. To learn more, see "Managing Service Users" in Getting Started with Oracle Cloud.

Updating the jazn-data.xml File

For all ADF applications which use ADF security, you must modify the jazn-data.xml file to ensure that the application roles within it are prefixed with <identify-domain-name>.<service-name> prior to deployment. Note that the names of all identity domains, users, and roles must be spelled in lowercase in the jazn-data.xml file. The following is an example jazn-data.xml file.

This example assumes that application roles have been defined through the Identity Console and mapped to the JavaUsers role.

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
<jazn-data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/jazn-data-11_0.xsd">
 
  <policy-store>
    <applications>
      <application>
        <name>SimpleSecureApplication</name>
        <app-roles>
          <app-role>
            <name>trialaagy.customer</name>
            <class>oracle.security.jps.service.policystore.ApplicationRole</class>
            <members>
              <member>
                <name>trialaagy.a</name>
                <class>weblogic.security.principal.WLSUserImpl</class>
              </member>
            </members>
          </app-role>
          <app-role>
            <name>trialaagy.staff</name>
            <class>oracle.security.jps.service.policystore.ApplicationRole</class>
            <members>
              <member>
                <name>trialaagy.a</name>
                <class>weblogic.security.principal.WLSUserImpl</class>
              </member>
            </members>
          </app-role>
          <app-role>
            <name>trialaagy.supplier</name>
            <class>oracle.security.jps.service.policystore.ApplicationRole</class>
            <members>
              <member>
                <name>trialaagy.b</name>
                <class>weblogic.security.principal.WLSUserImpl</class>
              </member>
            </members>
          </app-role>
        </app-roles>
        <jazn-policy>
          <grant>
            <grantee>
              <principals>
                <principal>
                  <name>authenticated-role</name>
                  <class>oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl</class>
                </principal>
              </principals>
            </grantee>
            <permissions>
              <permission>
                <class>oracle.adf.share.security.authorization.RegionPermission</class>
                <name>oracle.view.pageDefs.productsPageDef</name>
                <actions>view</actions>
              </permission>
            </permissions>
          </grant>
          <grant>
            <grantee>
              <principals>
                <principal>
                  <name>trialaagy.supplier</name>
                  <class>oracle.security.jps.service.policystore.ApplicationRole</class>
                </principal>
              </principals>
            </grantee>
            <permissions>
              <permission>
                <class>oracle.adf.share.security.authorization.RegionPermission</class>
                <name>oracle.view.pageDefs.stockPageDef</name>
                <actions>view</actions>
              </permission>
            </permissions>
          </grant>
        </jazn-policy>
      </application>
    </applications>
  </policy-store>
</jazn-data>

About Web Services

Applications deployed on Java Cloud Service can invoke externally exposed web services that are either non-secured or secured (for example, using WS-Security). For deployed applications which invoke a secured external web service, Java Cloud Service supports the following Oracle Web Services Manager (OWSM) policy:

oracle/wss_username_token_over_ssl_client_policy

For more information on supported policies, see "Predefined Policies" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

To use OWSM policies, you must attach them at design time:

About Third Party Framework Support

Oracle makes no specific claims about a definite list of third party libraries that should work within a Java Cloud Service environment. In general, an application's use of most third party frameworks should work within Java Cloud Service, so long as:

Using Integrated Development Environments

Use the Resources page to access links to additional tools that enable you to directly interact with your Java Cloud Service instance, including JDeveloper, Eclipse, and NetBeans.

You can download these tools and the Oracle Java Cloud Service SDK from: http://www.oracle.com/technetwork/topics/cloud/downloads/

Topics:

About Oracle JDeveloper

Oracle JDeveloper is a free integrated development environment that simplifies the development of Java-based SOA and Java EE applications. JDeveloper offers complete end-to-end development for Oracle Fusion Middleware and Oracle Fusion Applications with support for the full development life cycle.

Supported Versions:

Oracle JDeveloper 11.1.1.6.0

Documentation:

The documentation for using JDeveloper to develop for and deploy to Java Cloud Service is available in JDeveloper. Select Help > Table of Contents and search for Cloud.

More Information:

For product information, links to documentation, user community, and more, see:

http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html

About NetBeans

NetBeans is a free, open-source Integrated Development Environment (IDE) for software developers. All the tools needed to create professional desktop, enterprise, web, and mobile applications with the Java platform, as well as with C/C++, PHP, JavaScript and Groovy.

Supported Versions:

NetBeans 7.2 + Update

Documentation:

The official NetBeans documentation will contain information on using the IDE's Java Cloud Service integration capabilities.

For information about NetBeans content and Oracle Cloud integration, see:

http://netbeans.org/kb/docs/web/oracle-cloud.html

More Information:

For product information, links to documentation, user community, and more, see:

http://www.netbeans.org

About Oracle Enterprise Pack for Eclipse

Oracle Enterprise Pack for Eclipse (OEPE) provides tools that make it easier to develop applications using specific Oracle Fusion Middleware technologies and Oracle Database. For Oracle Cloud, OEPE provides direct deployment to Oracle Java Cloud Service, integrated whitelist scanning to check for errors before deployment, integration into the Java Service Console, and log viewers to check on the status of the application.

Supported Versions:

OEPE 12.1.1.1.1

Documentation:

You can find the documentation for the Enterprise Pack for Eclipse integration with the Java Cloud Service at:

http://docs.oracle.com/cd/E27086_04/help/oracle.eclipse.tools.cloud.doc/html/index.html

More Information:

For product information, links to documentation, user community, and more, see:

http://www.oracle.com/technetwork/developer-tools/eclipse/overview/index.html

Preparing Java EE Applications for Java Cloud Service Deployment

To deploy a Java EE application to a Java Cloud Service instance, you must follow the guidelines described in this section.

Topics:

Deploying Applications Using Java EE or ADF Application Security

If an application uses Java EE or ADF application security for securing part or all of its pages (either programmatically or through its deployment descriptors), you must modify the application to refer to the appropriate application roles as described in "About Java EE Application Security" and "About ADF Application Security".

Deploying Applications Using a JDBC Data Source

If the application is using a JDBC data source for database access, then all references to the JDBC data source must be modified to use the Java Naming and Directory Interface (JNDI) name of the data source assigned within the Java Cloud Service instance. This JNDI name is equivalent to the name given to the Database Cloud Service instance at provisioning time.

For example, if the name of the Database Cloud Service service instance is foo, then the JNDI name of the Database Cloud Service instance will also be foo. Therefore, foo is the name that should be used in all references to the data source within the application.

Deploying an ADF Application

If you are deploying an ADF application, you must modify its weblogic.xml deployment descriptor to use the <exact-match> element as described in the following example.

<library-ref>
        <library-name>jsf</library-name>
        <specification-version>1.2</specification-version>
        <exact-match>true</exact-match>
    </library-ref>

Note:

This library reference is added automatically if an ADF application is deployed from JDeveloper to a Cloud server.

If the application needs to be deployed to both on-premise environments as well as a Java Cloud Service instance, and if the on-premise environments use different role names and data source JNDI names, then use the WebLogic Server release 10.3.6 deployment plans feature when deploying the application to the on-premise environments. This approach will support the configuration differences between the on-premise environment and the Java Cloud Service instance.

To learn more, see "Using a Deployment Plan: Overview" in Oracle Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server.

Understanding On-Premise and Java Cloud Service Portability

To create an on-premise Java EE environment that is comparable to a Java Cloud Service instance, you must:

  1. Install WebLogic Server 10.3.6. No other version of WebLogic Server is supported as an on-premise environment for Java Cloud Service.

  2. Create a domain as follows:

    • If the application you are deploying is not an ADF application and does not use any web services security (using OWSM), use the plain wls.jar WebLogic Server domain configuration template.

    • If the application you are deploying is using ADF or web services (by either exposing or invoking them) which must be protected through OWSM security policies, use the plain wls.jar as well as the JRF and OWSM domain configuration templates.

      Tip:

      You can apply the JRF and OWSM domain configuration templates through the WebLogic Server configuration wizard. To accomplish this, use the version of the configuration wizard packaged with Oracle JDeveloper release 11.1.1.6 or ADF download.
  3. Deploy the deployment archives listed in Table 4-1 as shared libraries to the domain. Note that in Table 4-1, MW_HOME refers to the Middleware Home directory you used when you installed WebLogic Server.

    Tip:

    During deployment, you must use the exact deployment names specified in Table 4-1.

    Table 4-1 Java Cloud Service Deployment Archive Names

    Application Type Deployment Archive Path Deployment Name

    Uses JAX-RS 1.1 REST interfaces

    MW_HOME/wlserver_10.3/common/deployable-libraries/jersey-bundle-1.9.war
    

    jax-rs

    Uses JSF 2.0 for web application components

    MW_HOME/wlserver_10.3/common/deployable-libraries/jsf-2.0.war
    

    jsf


  4. Create a single XA enabled JDBC data source using the Oracle JDBC Thin driver connected to an on-premise Oracle Database 11g release 1 (11.1) data source. Give the data source the same name as the Database Cloud Service instance associated with your target Java Cloud Service.

To move an application (represented by a set of EAR/WAR files) between an on-premise environment and JCS instances (or vice-versa), you must ensure that their database and Identity Management user repository content is also moved appropriately.

To move database data from on-premise to Database Cloud Service instances associated with JCS instances:

  1. Ensure that your schema tables are created within the target Database Cloud Service instance. To do this you can use either the database service's SQL Workshop interface (see the SQL Workshop section in Using Oracle Database Cloud Service) or SQL Developer (see the SQL Developer section in Using Oracle Database Cloud Service).

    You can also have the schemas created upon application deployment if using EclipseLink JPA by using the following snippet within your application's persistence.xml descriptor:

    <property name="eclipselink.ddl-generation" value="create-tables"/>
    
  2. Follow the instructions for using the SQL Workshop Data Upload Utility (see Using Oracle Database Cloud Service) to import your bulk data from on-premise to the target Database Cloud Service instance.

To move database data from Database Cloud Service instances associated with JCS instances to on-premise schemas:

  1. Follow the instructions in the section about exporting data in Using Oracle Database Cloud Service to import your bulk data from on-premise to the target Database Cloud Service instance.

To move user repository data from on-premise user repositories to the identity domain associated with a JCS instance:

  1. Export data from your on-premise identity repository into a single file in CSV format (see Using Oracle Database Cloud Service).

About Java Cloud Service Whitelist

For technical and security reasons, a small number of specific APIs are prevented from executing in Oracle Cloud. Applications using these APIs are not deployable because they will not pass the whitelist phase of the Java Cloud Service deployment process. Java Cloud Service SDK includes a whitelist tool that enables you to check whether an application is in violation of the Java Cloud Service whitelist. To learn more, see "About Installing the Java Cloud Service SDK".

Note:

The Java Cloud Service "whitelist" is actually the result of what are sometimes called blacklist and whitelist checks. It may be helpful to think of Java Cloud Service whitelist validation as simply a compatibility check.

Understanding Java Cloud Service Whitelist Criteria

Whitelist violations result when applications use functionality from the following areas.

  • Java SE

    • Java non-blocking IO

    • Java Networking

    • Executing a new Process

    • Direct SQL connection

      Tip:

      Java Cloud Service supports database connections through an associated data source.
    • Java media

    • Java Mail

    • Java Compiler

    • Java RMI

    • Java Native Interface (JNI)

    • Java Desktop accessibility

    • JDK Log Management

      Tip:

      You can use JDK loggers to log the messages.
    • CORBA API (org.omg.**)

    • Overriding Java Security Manager

  • Java EE

    • Remote EJB

    • Java Messaging Service

    • Remote JMX Management

See also "Unsupported Features and APIs".

About the Java Cloud Service Deprecation Policy

The following describes the deprecation policy for Java Cloud Service: