ESB is good for routing messages to multiple destinations. It is also good for doing transformations that have little to no business rules. The footprint is much smaller and incurs minimal overhead therefore the performance is much better.
BPEL is used for bringing together multiple services. There is much more functionality and allows implementation of complex business logic.
Oracle BPEL can be used for integration code but its not designed/optimised for it.. Oracle BPEL is a Business Process Execution Language and as such its optimised for managing and coding business processes, whereas an ESB is quite simply a highly efficient intergration product. Its principle objective is to join two different services together quickly, efficiently and bi-directional.
Specifically an ESB moves data via
Connects services via different adaptors (WebServices, FTP,File,JDBC etc) and protocols (HTTP,JMS)
Enriches and transform data using XSL & domain value mapping lookups
Routes messages based on data in the message payload and/or header
and finally and often overlooked feature is that an ESB
Virtualises services, quite simply adds a facade layer to your infrastructure...
Its also worth noting that doing integration work with Oracle ESB is not only quicker to "build" but its also quicker in its execution. I've been told by some collegues in the US that an integration process in ESB product is approx twice the speed of same process in Oracle BPEL..
So to recap
Use ESB when
You want a really low cost solution
Only need connectivity, simple transformations and routing
Use BPEL+ESB when
You need to code complex business logic
Integration with Workflow
Complex transforms potentially involving the database
Have Long running processes which may or may not be stateful.
The best practices around using BPEL and ESB together are as follows:
- BPEL takes care of the stateful, long running, orchestration steps
- BPEL operates on the canonical definitions of your business objects - such that
your BPEL process is clean (minimal transformations, assigns) with the focus on
the basic business logic and related compensatory error-handling logic
whereas,
- ESB virtualizes endpoints that BPEL is orchestrating
- ESB does the heavy lifting of transformations to and from the canonical definition to
endpoint definitions of the business objects
With an appropriately layered SOA architecture, one would look at ESB as a
repository of services that BPEL orchestrates. At deployment time, this layered
approach provides you the flexibility to dedicate servers to individual
tiers (BPEL and ESB) and thereby maximize the resource usage for your
particular use case.
BPEL data transformations enrich and perform complex changes whereas ESB can perform only simple transformations.
• Exception handling can be done in BPEL.
• ESB does not have the Sensors which can be used to monitor the activities that can send actions to Business Activity Monitoring (BAM) or database/jms.
• BPEL can use Business rules, Human Workflow and Notifications.
• Primarily BPEL is used for Orchestration, data enrichment and also for Human interaction whereas ESB is used for Store and forward transport of data.
Saturday, February 25, 2012
SOA Interview Questions
What is SOA?
SOA stands for service oriented architecture. Before we define SOA lets first define a service. In real world service is what we pay for and we get the intended service. For instance you go to a hotel and order food. Your order first goes to the counter and then it goes to the kitchen where the food is prepared and finally the waiter serves the food.
So in order to order a item from a hotel you need the three logical departments / services to work together (counter, kitchen and waiter).
In the same manner in software world these services are termed as business services. They are self contained and logical. So let's first define a business service, SOA definition will be just an extension of the same.
Definition of business service: - It's a logical encapsulation of self contained business functionality.
For instance figure 'order system' shows a simple ordering system which is achieved by different services like payment gateway, stock system and delivery system coming together. All the services are self contained and logical. They are like black boxes. In short we do not need to understand the internal details of how the business service works. For the external world it's just a black box which takes messages and serves accordingly. For instance the 'payment gateway' business service takes message 'check credit' and gives out output does the customer have credit or not. For the 'order system' business service 'payment gateway' service is a black box.
Now let's revise some bullet points of SOA before we arrive to a definition of SOA.
. SOA components are loosely coupled. When we say loosely coupled means every service is self contained and exist in alone logically. For instance we take the 'payment gateway' service and attach it to a different system.
. SOA services are black boxes. In SOA services hide there inner complexities. They only interact using messages and send services depending on those messages. By visualizing services as black boxes services become more loosely coupled.
. SOA service should be self defined: - SOA services should be able to define themselves.
. SOA Services are maintained in a listing: - SOA services are maintained in a central repository. Applications can search the services in the central repository and use them accordingly.
. SOA components can be orchestrated and linked to achieve a particular functionality. SOA services can be used/orchestrated in a plug and play manner. For instance figure 'Orchestration' shows two services 'Security service' and 'Order processing service'. You can achieve two types of orchestrations from it one you can check the user first and then process order or vice-versa. Yes you guessed right using SOA we can manage work flow between services in a loosely coupled fashion.
So let us define SOA.
SOA is a architecture for building business applications using loosely coupled services which act like black boxes and can be orchestrated to achieve a specific functionality by linking together.
(I) In SOA do we need to build systems from scratch?
No. If you need to integrate or make an existing system as a business service, you just need to create loosely coupled wrappers which will wrap your custom systems and expose the systems functionality in generic fashion to the external world.
(I) Can you explain business layers and plumbing layers in SOA?
In SOA we can divide any architecture in two layers. The first which has direct relevance to business as it carries out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server etc. This division is needed to identify a service. Consider the figure 'Simple order system'. It has various components which interact with each other to complete the order system functionality.
The simple order system can be divided in to two layers (see figure 'business and plumbing layer' one which is business related and second which is more technical related. You can see the plumbing layer consisting of data access layer , AJAX , yes more of technical stuff.
Figure: - Business layer and plumbing layer
(I) what's the difference between services and components?
Services are logical grouping of components to achieve business functionality. Components are implementation approaches to make a service. The components can be in JAVA, C#, C++ but the services will be exposed in a general format like Web Services.
(A) Can you describe the complete architecture of SOA?
Figure 'Architecture of SOA' shows a complete view of a SOA. Please note this architecture diagram is not tied up with implementation of Microsoft, IBM etc. It's a general architecture. Any vendor who implements SOA needs to fulfill the below SOA components. How they do it is completely their own technological implementation.
Figure: - Architecture of SOA
The main goal of SOA is to connect disparate systems. In order that these disparate system work they should messages to each other. ESB (Enterprise service bus) acts like a reliable post office which guarantees delivery of messages between systems in a loosely coupled manner. ESB is a special layer which delivers messages between applications. In the figure we have shown a huge plump pipe. It's not hardware or some wire etc. It's a group of components/software which helps you to send and receive messages between the disparate applications. Do not try to code your own ESB, you can think of buying one from Microsoft, IBM, Oracle, progress etc.
SOA registry is like a reference database of services. It describes what each services do, where are they located and how can they communicate. It's a central reference of meta-data for services.
SOA workflow allows us to define work flow using the services in SOA registry. We will read more about BPM in the further questions.
Service broker reads the work flow and takes services from the SOA registry and ties them together. Service brokers are normally middleware like EAI (Enterprise application Integration) products. You can get a list of decent EAI from Sun, Microsoft, and IBM etc.
Process manager is nothing but the collection of SOA registry, SOA workflow and service broker.
SOA supervisor is traffic cop ensuring that services do not have issues. It deals mainly with performance issues of the system so that appropriate service levels are met. If any of the services have performance problems it sends messages to the proper infrastructure to fix the issue.
Note: - The above explanation is of general architecture for SOA. Any vendor (Microsoft, IBM, SUN etc) who gives solution for SOA should have the above components in some or other manner. As this is a Software architecture book, we will not be covering specific vendor implementation. We would advise the reader to map the same to their vendor products for better understanding.
(I) Can you explain a practical example in SOA?
(I) What are ends, contract, address, and bindings?
These three terminologies on which SOA service stands. Every service must expose one or more ends by which the service can be available to the client. End consists of three important things where, what and how:-
. Contract (What)
Contract is an agreement between two or more parties. It defines the protocol how client should communicate with your service. Technically, it describes parameters and return values for a method.
. Address (Where)
An Address indicates where we can find this service. Address is a URL, which points to the location of the service.
. Binding (How)
Bindings determine how this end can be accessed. It determines how communications is done. For instance, you expose your service, which can be accessed using SOAP over HTTP or BINARY over TCP. So for each of these communications medium two bindings will be created.
Below figure, show the three main components of end. You can see the stock ticker is the service class, which has an end hosted on www.soa.com with HTTP and TCP binding support and using Stock Ticker interface type.
Figure: - Endpoint Architecture
Note: - You can also remember the end point by ABC where A stands for Address, B for bindings and C for Contract.
(I) Are web-services SOA ?
SOA is a thinking, it's an architectural concept and web service is one of the technical approach to complete it. Web services are the preferred standards to achieve SOA.
. In SOA we need the services to be loosely coupled. A web service communicates using SOAP protocol which is XML based which is very loosely coupled. It answers the what part of the service.
. SOA services should be able to describe themselves. WSDL describes how we can access the service.
. SOA services are located in a directory. UDDI describes where we can get the web service. This nothing but implementation of SOA registry.
oracle soa bpel interview questions
1. Is Oracle SOA same as Oracle Fusion Middleware
Oracle Fusion Middleware is a collection of standards-based software products that spans a range of tools and services from J2EE and developer tools, to integration services, business intelligence, collaboration, and content management. Oracle Fusion Middleware offers complete support for development, deployment, and management.
Oracle SOA Suite is an essential middleware layer of Oracle Fusion Middleware. It provides a complete set of Service Infrastructure components for designing, deploying, and managing composite applications
2. What is SOA Governance
Service-Oriented Architecture (SOA) governance is a concept used for activities related to exercising control over services in an SOA
3. How to increase performance increase in bpel (Db Adapter/file adapter)
We can increase the performance by writing indexes and sequences.
(Or) Go to application server --- >Configurations ----- > Change Xml file
4. Predefined errors in BPEL?
Custom errors
Timed out errors
BPM errors
Validation Errors
5. Is it possible to use MS SQL Server as dehydration store with SOA Suite ?if yes how?
Yes it is possible.
To automatically maintain long-running asynchronous processes and their current
state information in a database while they wait for asynchronous callbacks, you use a database as a dehydration store.
Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. This feature increases both BPEL process reliability and scalability. You can also use it to support clustering and failover.
6. What are the various elements in WSDL?
Various elements are:
Types, messages, operation, port, bindings and Services.
Types– a container for data type definitions using some type system (such as XSD).
Message– an abstract, typed definition of the data being communicated.
Operation– an abstract description of an action supported by the service.
Port Type–an abstract set of operations supported by one or more endpoints.
Binding– a concrete protocol and data format specification for a particular port type.
Port– a single endpoint defined as a combination of a binding and a network address.
Service– a collection of related endpoints.
7. Why do we need to have messages in WSDL, aren't operations and types enough to describe the parameters for a web service
Messages consist of one or more logical parts. Each part is associated with a type from some type system using a message-typing attribute. The set of message-typing attributes is extensible.
•The element describes the data being exchanged between the Web service providers and consumers.
• Each Web Service has two messages: input and output.
•The input describes the parameters for the Web Service and the output describes the return data from the Web Service.
•Each message contains zero or more parameters, one for each parameter of the Web Service's function.
•Each parameter associates with a concrete type defined in the container element.
So describing the parameters cannot performed by operations and types this is the main need of Messages
8. What is structure of SOAP message?
The structure of a SOAP message: A SOAP message is encoded as an XML document, consisting of an element, which contains an optional element, and a mandatory element. The element, contained within the , is used for reporting errors.
The SOAP envelope
The SOAP is the root element in every SOAP message, and contains two child elements, an optional and a mandatory .
The SOAP header
The SOAP is an optional sub-element of the SOAP envelope, and is used to pass application-related information that is to be processed by SOAP nodes along the message path.
The SOAP body
The SOAP is a mandatory sub-element of the SOAP envelope, which contains information intended for the ultimate recipient of the message.
The SOAP fault
The SOAP is a sub-element of the SOAP body, which is used for reporting errors.
With the exception of the element, which is contained in the of a SOAP message, XML elements within the and the are defined by the applications that make use of them, although the SOAP specification imposes some constraints on their structure. Figure shows the main elements of a SOAP message.
Asynchronous vs. Synchronous BPEL process
This article explains the difference between an asynchronous and a synchronous process.
I have tried to explain the difference with the help of a simple example below:
Suppose there are two processes SynchronousBPELProcess and AsynchronousBPELProcess. As the name suggest former one is a synchronous and later one is an asynchronous BPEL process. Also there is a third process which we’ll call as Client. The Client invokes the above processes.
Case 1: Client invokes SynchronousBPELProcess.
1. Client invokes SynchronousBPELProcess.
2. SynchronousBPELProcess gets instantiated and starts its operations while Client waits for the response from the SynchronousBPELProcess.
3. SynchronousBPELProcess completes its operations and sends a response back to Client.
4. Client continues and completes its processing.
Case 2: Client invokes AsynchronousBPELProcess
1. Client invokes AsynchronousBPELProcess.
2. AsynchronousBPELProcess gets instantiated and starts its operations while Client also continues to perform its operations.
3. AsynchronousBPELProcess completes its operations and callback the Client with the response message.
Here we noticed that if a synchronous process is invoked, the operations of this process has to be completed first and only then the client is able to resume its operations while in the case of asynchronous both the process continues to perform their operations.
Fig1: An image showing bpel diagram of an asynchronous and a synchronous process.
What makes the difference?
Synchronous Process:
The synchronous process defines one two way operation port to receive the request and send the response. Using the invoke activity the client invokes the Synchronous BPEL process on this port and waits to receive the response on the same port. As soon as the client receives the response from the BPEL process it continues with its flow. On the BPEL process side, the Synchronous BPEL process gets instantiated on receiving the client request and sends back the reply using the reply activity on the same port on which the Client is waiting.
Asynchronous Process:
In the asynchronous process two one way operations ports are defined to receive the request and send the response. On the client side, the client uses the invoke activity to invoke the asynchronous BPEL process and continues with its flow. It uses the receive activity to receive the response later in the flow. The asynchronous BPEL process receives the request on one of the ports and sends back the reply from another port (callback port). To send the response the asynchronous BPEL process invokes the client on the callback port using the callback activity.
Fig 2: An image showing the wsdl of an asynchronous and a synchronous process.
Fig 3: An image showing a call to asynchronous and synchronous process.
We also find different operation names like initiate, onResult and process in the .bpel file. These are just labels to differentiate between sync and async processes.
* A port is nothing but a method with input and output. So a two way operation port has an input and an output while a one way operation port has only input or output.
SOA stands for service oriented architecture. Before we define SOA lets first define a service. In real world service is what we pay for and we get the intended service. For instance you go to a hotel and order food. Your order first goes to the counter and then it goes to the kitchen where the food is prepared and finally the waiter serves the food.
So in order to order a item from a hotel you need the three logical departments / services to work together (counter, kitchen and waiter).
In the same manner in software world these services are termed as business services. They are self contained and logical. So let's first define a business service, SOA definition will be just an extension of the same.
Definition of business service: - It's a logical encapsulation of self contained business functionality.
For instance figure 'order system' shows a simple ordering system which is achieved by different services like payment gateway, stock system and delivery system coming together. All the services are self contained and logical. They are like black boxes. In short we do not need to understand the internal details of how the business service works. For the external world it's just a black box which takes messages and serves accordingly. For instance the 'payment gateway' business service takes message 'check credit' and gives out output does the customer have credit or not. For the 'order system' business service 'payment gateway' service is a black box.
Now let's revise some bullet points of SOA before we arrive to a definition of SOA.
. SOA components are loosely coupled. When we say loosely coupled means every service is self contained and exist in alone logically. For instance we take the 'payment gateway' service and attach it to a different system.
. SOA services are black boxes. In SOA services hide there inner complexities. They only interact using messages and send services depending on those messages. By visualizing services as black boxes services become more loosely coupled.
. SOA service should be self defined: - SOA services should be able to define themselves.
. SOA Services are maintained in a listing: - SOA services are maintained in a central repository. Applications can search the services in the central repository and use them accordingly.
. SOA components can be orchestrated and linked to achieve a particular functionality. SOA services can be used/orchestrated in a plug and play manner. For instance figure 'Orchestration' shows two services 'Security service' and 'Order processing service'. You can achieve two types of orchestrations from it one you can check the user first and then process order or vice-versa. Yes you guessed right using SOA we can manage work flow between services in a loosely coupled fashion.
So let us define SOA.
SOA is a architecture for building business applications using loosely coupled services which act like black boxes and can be orchestrated to achieve a specific functionality by linking together.
(I) In SOA do we need to build systems from scratch?
No. If you need to integrate or make an existing system as a business service, you just need to create loosely coupled wrappers which will wrap your custom systems and expose the systems functionality in generic fashion to the external world.
(I) Can you explain business layers and plumbing layers in SOA?
In SOA we can divide any architecture in two layers. The first which has direct relevance to business as it carries out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server etc. This division is needed to identify a service. Consider the figure 'Simple order system'. It has various components which interact with each other to complete the order system functionality.
The simple order system can be divided in to two layers (see figure 'business and plumbing layer' one which is business related and second which is more technical related. You can see the plumbing layer consisting of data access layer , AJAX , yes more of technical stuff.
Figure: - Business layer and plumbing layer
(I) what's the difference between services and components?
Services are logical grouping of components to achieve business functionality. Components are implementation approaches to make a service. The components can be in JAVA, C#, C++ but the services will be exposed in a general format like Web Services.
(A) Can you describe the complete architecture of SOA?
Figure 'Architecture of SOA' shows a complete view of a SOA. Please note this architecture diagram is not tied up with implementation of Microsoft, IBM etc. It's a general architecture. Any vendor who implements SOA needs to fulfill the below SOA components. How they do it is completely their own technological implementation.
Figure: - Architecture of SOA
The main goal of SOA is to connect disparate systems. In order that these disparate system work they should messages to each other. ESB (Enterprise service bus) acts like a reliable post office which guarantees delivery of messages between systems in a loosely coupled manner. ESB is a special layer which delivers messages between applications. In the figure we have shown a huge plump pipe. It's not hardware or some wire etc. It's a group of components/software which helps you to send and receive messages between the disparate applications. Do not try to code your own ESB, you can think of buying one from Microsoft, IBM, Oracle, progress etc.
SOA registry is like a reference database of services. It describes what each services do, where are they located and how can they communicate. It's a central reference of meta-data for services.
SOA workflow allows us to define work flow using the services in SOA registry. We will read more about BPM in the further questions.
Service broker reads the work flow and takes services from the SOA registry and ties them together. Service brokers are normally middleware like EAI (Enterprise application Integration) products. You can get a list of decent EAI from Sun, Microsoft, and IBM etc.
Process manager is nothing but the collection of SOA registry, SOA workflow and service broker.
SOA supervisor is traffic cop ensuring that services do not have issues. It deals mainly with performance issues of the system so that appropriate service levels are met. If any of the services have performance problems it sends messages to the proper infrastructure to fix the issue.
Note: - The above explanation is of general architecture for SOA. Any vendor (Microsoft, IBM, SUN etc) who gives solution for SOA should have the above components in some or other manner. As this is a Software architecture book, we will not be covering specific vendor implementation. We would advise the reader to map the same to their vendor products for better understanding.
(I) Can you explain a practical example in SOA?
(I) What are ends, contract, address, and bindings?
These three terminologies on which SOA service stands. Every service must expose one or more ends by which the service can be available to the client. End consists of three important things where, what and how:-
. Contract (What)
Contract is an agreement between two or more parties. It defines the protocol how client should communicate with your service. Technically, it describes parameters and return values for a method.
. Address (Where)
An Address indicates where we can find this service. Address is a URL, which points to the location of the service.
. Binding (How)
Bindings determine how this end can be accessed. It determines how communications is done. For instance, you expose your service, which can be accessed using SOAP over HTTP or BINARY over TCP. So for each of these communications medium two bindings will be created.
Below figure, show the three main components of end. You can see the stock ticker is the service class, which has an end hosted on www.soa.com with HTTP and TCP binding support and using Stock Ticker interface type.
Figure: - Endpoint Architecture
Note: - You can also remember the end point by ABC where A stands for Address, B for bindings and C for Contract.
(I) Are web-services SOA ?
SOA is a thinking, it's an architectural concept and web service is one of the technical approach to complete it. Web services are the preferred standards to achieve SOA.
. In SOA we need the services to be loosely coupled. A web service communicates using SOAP protocol which is XML based which is very loosely coupled. It answers the what part of the service.
. SOA services should be able to describe themselves. WSDL describes how we can access the service.
. SOA services are located in a directory. UDDI describes where we can get the web service. This nothing but implementation of SOA registry.
oracle soa bpel interview questions
1. Is Oracle SOA same as Oracle Fusion Middleware
Oracle Fusion Middleware is a collection of standards-based software products that spans a range of tools and services from J2EE and developer tools, to integration services, business intelligence, collaboration, and content management. Oracle Fusion Middleware offers complete support for development, deployment, and management.
Oracle SOA Suite is an essential middleware layer of Oracle Fusion Middleware. It provides a complete set of Service Infrastructure components for designing, deploying, and managing composite applications
2. What is SOA Governance
Service-Oriented Architecture (SOA) governance is a concept used for activities related to exercising control over services in an SOA
3. How to increase performance increase in bpel (Db Adapter/file adapter)
We can increase the performance by writing indexes and sequences.
(Or) Go to application server --- >Configurations ----- > Change Xml file
4. Predefined errors in BPEL?
Custom errors
Timed out errors
BPM errors
Validation Errors
5. Is it possible to use MS SQL Server as dehydration store with SOA Suite ?if yes how?
Yes it is possible.
To automatically maintain long-running asynchronous processes and their current
state information in a database while they wait for asynchronous callbacks, you use a database as a dehydration store.
Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. This feature increases both BPEL process reliability and scalability. You can also use it to support clustering and failover.
6. What are the various elements in WSDL?
Various elements are:
Types, messages, operation, port, bindings and Services.
Types– a container for data type definitions using some type system (such as XSD).
Message– an abstract, typed definition of the data being communicated.
Operation– an abstract description of an action supported by the service.
Port Type–an abstract set of operations supported by one or more endpoints.
Binding– a concrete protocol and data format specification for a particular port type.
Port– a single endpoint defined as a combination of a binding and a network address.
Service– a collection of related endpoints.
7. Why do we need to have messages in WSDL, aren't operations and types enough to describe the parameters for a web service
Messages consist of one or more logical parts. Each part is associated with a type from some type system using a message-typing attribute. The set of message-typing attributes is extensible.
•The element describes the data being exchanged between the Web service providers and consumers.
• Each Web Service has two messages: input and output.
•The input describes the parameters for the Web Service and the output describes the return data from the Web Service.
•Each message contains zero or more parameters, one for each parameter of the Web Service's function.
•Each parameter associates with a concrete type defined in the container element.
So describing the parameters cannot performed by operations and types this is the main need of Messages
8. What is structure of SOAP message?
The structure of a SOAP message: A SOAP message is encoded as an XML document, consisting of an element, which contains an optional element, and a mandatory element. The element, contained within the , is used for reporting errors.
The SOAP envelope
The SOAP is the root element in every SOAP message, and contains two child elements, an optional and a mandatory .
The SOAP header
The SOAP is an optional sub-element of the SOAP envelope, and is used to pass application-related information that is to be processed by SOAP nodes along the message path.
The SOAP body
The SOAP is a mandatory sub-element of the SOAP envelope, which contains information intended for the ultimate recipient of the message.
The SOAP fault
The SOAP is a sub-element of the SOAP body, which is used for reporting errors.
With the exception of the element, which is contained in the of a SOAP message, XML elements within the and the are defined by the applications that make use of them, although the SOAP specification imposes some constraints on their structure. Figure shows the main elements of a SOAP message.
Asynchronous vs. Synchronous BPEL process
This article explains the difference between an asynchronous and a synchronous process.
I have tried to explain the difference with the help of a simple example below:
Suppose there are two processes SynchronousBPELProcess and AsynchronousBPELProcess. As the name suggest former one is a synchronous and later one is an asynchronous BPEL process. Also there is a third process which we’ll call as Client. The Client invokes the above processes.
Case 1: Client invokes SynchronousBPELProcess.
1. Client invokes SynchronousBPELProcess.
2. SynchronousBPELProcess gets instantiated and starts its operations while Client waits for the response from the SynchronousBPELProcess.
3. SynchronousBPELProcess completes its operations and sends a response back to Client.
4. Client continues and completes its processing.
Case 2: Client invokes AsynchronousBPELProcess
1. Client invokes AsynchronousBPELProcess.
2. AsynchronousBPELProcess gets instantiated and starts its operations while Client also continues to perform its operations.
3. AsynchronousBPELProcess completes its operations and callback the Client with the response message.
Here we noticed that if a synchronous process is invoked, the operations of this process has to be completed first and only then the client is able to resume its operations while in the case of asynchronous both the process continues to perform their operations.
Fig1: An image showing bpel diagram of an asynchronous and a synchronous process.
What makes the difference?
Synchronous Process:
The synchronous process defines one two way operation port to receive the request and send the response. Using the invoke activity the client invokes the Synchronous BPEL process on this port and waits to receive the response on the same port. As soon as the client receives the response from the BPEL process it continues with its flow. On the BPEL process side, the Synchronous BPEL process gets instantiated on receiving the client request and sends back the reply using the reply activity on the same port on which the Client is waiting.
Asynchronous Process:
In the asynchronous process two one way operations ports are defined to receive the request and send the response. On the client side, the client uses the invoke activity to invoke the asynchronous BPEL process and continues with its flow. It uses the receive activity to receive the response later in the flow. The asynchronous BPEL process receives the request on one of the ports and sends back the reply from another port (callback port). To send the response the asynchronous BPEL process invokes the client on the callback port using the callback activity.
Fig 2: An image showing the wsdl of an asynchronous and a synchronous process.
Fig 3: An image showing a call to asynchronous and synchronous process.
We also find different operation names like initiate, onResult and process in the .bpel file. These are just labels to differentiate between sync and async processes.
* A port is nothing but a method with input and output. So a two way operation port has an input and an output while a one way operation port has only input or output.
Thursday, February 23, 2012
Configuring SSO for OBIEE 11g
http://docs.oracle.com/cd/E23520_01/doc.311/e20664/chapter_10.htm
Configuring OSSO SolutionThis chapter provides step-by-step instructions for configuring OSSO as the single sign-on solution for OSL. You can find complete explanation of the OSSO Solution in "Chapter 10 Configuring Single Sign-On in Oracle Fusion Middleware" in the Oracle® Fusion Middleware Security Guide 11g Release 1 (11.1.1) at
http://download.oracle.com/docs/cd/E12839_01/core.1111/e10043/toc.htm
10.1 Installing Oracle Single Sign-On and Oracle Delegated Administration Services
There are no 11g Release 1 (11.1.1) versions of Oracle Single Sign-On and Oracle Delegated Administration Services. However, both Oracle Single Sign-On and Oracle Delegated Administration Services Release 10g (10.1.4.3.0) are certified for use with Oracle Internet Directory 11g Release 1 (11.1.1).
You can find related information in "Chapter 10 Installing Oracle Single Sign-On and Oracle Delegated Administration Services Against Oracle Internet Directory" in the Oracle® Fusion Middleware Installation Guide for Oracle Identity Management 11g Release 1 (11.1.1) at
http://download.oracle.com/docs/cd/E12839_01/install.htm
10.2 Configuring SSO for Learning Tool
To configure SSO for Learning Tool, perform the steps in the subsequent sections.
10.2.1 Installing HTTP Server
Install web server to be used as a front end to the Oracle WebLogic Server. In this guide, we use Oracle HTTP Server (OHS) 11g, which is available after the installation of Web Tier Utilities 11.1.1.2.0.
10.2.2 Configuring mod_wl_ohs
If you select the option “Associate Selected Components with WebLogic Domain” during the installation of Web Tier Utilities, you are able to manage the web server using Enterprise Manager (EM).
This section demonstrates the configuration of mod_wl_ohs using EM. However, it is also possible to do the same configuration by manually editing the configuration files.
To configure mod_wl_ohs from EM, perform the following:
1.Select the OHS instance on the left panel.
2.Select Oracle HTTP Server > Administration > mod_wl_ohs Configuration on the right panel.
Figure 10-1 Configuring mod_wl_ohs
3.Enter the value for WebLogic Host, WebLogic Port, and Locations. Figure 10-2 shows a sample setup for Learning Tool Admin and Learning Tool.
Figure 10-2 Sample mod_wl_ohs configuration for LT Admin
This configuration will effectively be added to the mod_wl_ohs.conf file of this OHS instance. You can also manually modify this file without using the EM.
Note:
If you install Web Tier Utilities, you can locate mod_wl_ohs.conf file at:
For example:/Oracle_WT1/instances/instance1/config/OHS/ohs1/
For example:
WebLogicHost yourservername.com
WebLogicPort 7002
SetHandler weblogic-handler
Figure 10-3 Sample mod_wl_ohs configuration for LT
This configuration will effectively be added to the mod_wl_ohs.conf file of this OHS instance. You can also manually modify this file without using the EM.
For example:
WebLogicHost yourservername.com
WebLogicPort 7002
SetHandler weblogic-handler
10.2.3 Registering OHS mod_osso with OSSO Server
To register OHS mod_osso with OSSO server, perform the following:
1.Execute the ssoreg.sh tool, which can be found in/sso/bin, where is the directory to which Oracle Single Sign-On is installed.
Note:
The directory where you want to store the result config file must be created beforehand.
$cd/sso/bin
$export ORACLE_HOME=
$./ssoreg.sh -oracle_home_path -site_name LearningToolAdmin -config_mod_osso TRUE -mod_osso_url http://: -update_mode CREATE -remote_midtier -config_file /temp/osso_admin.conf
$./ssoreg.sh -oracle_home_path -site_name LearningTool -config_mod_osso TRUE -mod_osso_url http://: -update_mode CREATE -remote_midtier -config_file /temp/osso_lt.conf
where:
and are the host name and port of the web server configured as a front end to provide access to the Learning Tool Admin application.
and are the host name and port of the web server configured as a front end to provide access to the Learning Tool application.
2.Copy this file to the web server instance location.
For example:
/Oracle_WT1/instances/instance1/config/OHS/ohs1/osso/osso_admin.conf
/Oracle_WT1/instances/instance2/config/OHS/ohs2/osso/osso_lt.conf
10.2.4 Configuring mod_osso to Protect Web Resources
To configure mod_osso to protect web resources, perform the following:
1.Enable mod_osso from EM.
Select the OHS instance on the left panel and select Oracle HTTP Server > Administration > Server Configuration on the right panel.
Figure 10-4 Configuring mod_osso
Check the check box for mod_osso and click Apply.
Figure 10-5 Enabling mod_osso
2.Configure mod_osso.
Go to the Advanced Server Configuration. The Advanced Server Configuration screen enables to directly edit the configuration files. From the list, select mod_osso.conf and click Go.
Figure 10-6 Setting up Advanced Server Configuration
Edit the content of this file, see Figure 10-7.
Figure 10-7 Editing Content of mod_osso
You can also manually edit the content of this file without using EM. Below is the sample configuration done for Learning Tool Admin and Learning Tool.
Sample configuration for Learning Tool Admin:
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/osso/osso_admin.conf
require valid-user
AuthType Osso
Sample configuration for Learning Tool:
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/ ${COMPONENT_NAME}/osso/osso_lt.conf
OssoHTTPOnly Off
require valid-user
AuthType Osso
Note:
The configuration directive OssoHTTPOnly must be turned off in the web server configured as a front end to provide access to the Learning Tool application. This is to allow the audio applet in the Learning Tool application to be able to read the OSSO cookies.
10.2.5 Setting Up Providers for OSSO in a WebLogic Domain
Oracle recommends the following Authentication providers:
•OSSO Identity Asserter
•OID Authenticator
•DefaultAuthenticator
To add providers to your WebLogic domain for OSSO Identity Assertion, perform the following:
1.Log in to the WebLogic Administration Console.
2.OSSO Identity Asserter:
Go to Security Realms > Default Realm Name (Example: myrealm) and click Providers.
Select New under the Authentication Providers table.
Enter a name for the new provider, select its type, and click OK.
◦Name: OSSO Identity Asserter
◦Type: OSSOIdentityAsserter
Note:
For OSSOIdentityAsserter to appear in the list, you must copy ossoiap.jar to/lib.
The ossoiap.jar is available in/oracle_common/modules/oracle.ossoiap_11.1.1 in the computer where an Oracle Fusion Middleware products such as Oracle Identity Management, Oracle SOA Suite, or Oracle WebCenter is installed.
Click the name of the newly added provider.
On the Common tab, set the appropriate values for common parameters and set the Control Flag to SUFFICIENT and then save the settings.
3.Default Authentication Provider:
Go to Security Realms > Default Realm Name (Example: myrealm) and click Providers.
Click DefaultAuthentication Provider.
Set the Control Flag to OPTIONAL and click Save.
4.OID Authenticator:
The instructions to create this provider are provided in Section 8.5, "Configuring OID as Security Provider".
If the OID Authenticator is configured successfully, you can change the Control Flag to SUFFICIENT.
5.Reorder Providers:
◦OSSO Identity Asserter (SUFFICIENT)
◦OID Authenticator (SUFFICIENT)
◦DefaultAuthenticator (OPTIONAL)
6.Save all configuration settings and restart the Oracle WebLogic Server for the changes to take effect.
10.2.6 Configuring web.xml for the OSSO Identity Asserter
Update the in web.xml for the application to support SSO as follows:
1.Modify the web.xml, which is located at
[OSL Home directory]/LearningTool/Configuration/LearningTool/DeploymentDescriptors/ for Learning Tool and at [OSL Home directory]/LearningTool/Configuration/Admin/DeploymentDescriptors/ for Learning Tool Admin to update the login-config as follows:
CLIENT-CERT
myRealm
2.Run the Configurator to update the EAR files as explained in Section 9.3, "Running the OSL Learning Tool Configurator".
10.3 Configuring SSO for OBIEE
To configure SSO for OBIEE, perform the following steps in the subsequent sections:
10.3.1 Installing HTTP Server
Install web server to be used as a front end to Oracle WebLogic Server. In this guide, use Oracle HTTP Server 11g which is available after the installation of Web Tier Utilities 11.1.1.2.0.
10.3.2 Configuring mod_wl_ohs
If the ear/war file is deployed onto a WebLogic Server, perform similar steps as Section 10.2.2, "Configuring mod_wl_ohs" to configure mod_wl_ohs.
Figure 10-8 Configuring mod_wl_ohs
10.3.3 Registering OHS mod_osso with OSSO Server
To register OHS mod_osso with OSSO Server, perform the following:
1.Execute the ssoreg.sh tool, which can be found in/sso/bin, where is the directory in which Oracle Single Sign-On is installed.
Note:
The directory where you want to store the result config file must be created beforehand.
$cd/sso/bin
$export ORACLE_HOME=
$./ssoreg.sh -oracle_home_path -site_name Student_Reporting -config_mod_osso TRUE -mod_osso_url
http://: -update_mode CREATE -remote_midtier -config_file /temp/osso_bi.conf
where:
and are the host name and port of the web server configured as a front end to provide access to the OBIEE application.
2.Copy this file to the web server instance location.
For Example:
/Oracle_WT1/instances/instance3/config/OHS/ohs3/osso/osso_bi.conf
10.3.4 Configuring mod_osso to Protect Web Resources
Perform similar steps as explained in Section 10.2.4, "Configuring mod_osso to Protect Web Resources" to configure the mod_osso as follows:
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/ ${COMPONENT_NAME}/osso/osso_bi.conf
Header unset Pragma
OssoSendCacheHeaders off
require valid-user
AuthType Osso
10.3.5 Creating Oracle BI Server Impersonator User
Follow this procedure to create the impersonator user in the BI Server repository.
1.Open the BI Server repository file (.rpd) using BI Administration Tool.
2.Select Manage > Security to display the Security Manager.
3.Select Action > New > User to open the User dialog box.
4.Enter a name and password for this user.
For example:
Name = Impersonator
Password = secret
5.In the Group Membership portion of the dialog box, check the Administrators group to grant the user created as member to this group.
6.Click OK to create the user.
10.3.6 Adding the Impersonator Credentials to Oracle BI Presentation Services Credential Store
Perform this step to add the impersonator credentials to Oracle BI Presentation Services credential store.
1.Navigate to the OracleBI_HOME/web/bin directory.
$export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/OracleBI_HOME/web/bin$./cryptotools credstore -add -infile/web/config/credentialstore.xml>
Credential Alias: impersonation
>Username: Impersonator
>Password: secret
>Do you want to encrypt the password? y/n (y):
>Passphrase for encryption: another_secret
>Do you want to write the passphrase to the xml? y/n (n):
2.The CryptoTools utility updates the credentialstore.xml file. This file is located in the OracleBIData/web/config.
10.3.7 Configuring Oracle BI Presentation Services to Identify the Credential Store and Decryption Passphrase
Edit the OracleBIData/web/config/instanceconfig.xml file.
10.3.8 Configuring BI Presentation Services to Operate in the SSO Environment
Edit the OracleBIData/web/config/instanceconfig.xml file.
http://:/pls/orasso/orasso.wwsso_app_admin.ls_logout?p_done_url=http%3A%2F%2F:%2Fanalytics%2F
http://:/analytics
10.4 Configuring SSO for UCM 10g
To configure SSO for UCM 10g, perform the steps in the subsequent sections:
10.4.1 Installing HTTP Server
Install web server to be used as a front end to UCM. In this guide, use Oracle HTTP Server 11g which is available after the installation of Web Tier Utilities 11.1.1.2.0.
10.4.2 Configuring OHS as Web Server for UCM
Inside the httpd.conf of the OHS instance, add the following to configure this OHS instance as the web server for UCM. Make sure that you use the correct library under linux64 or linux folder:
LoadModule IdcApacheAuth
/server/shared/os/linux64/lib/IdcApache22Auth.so
IdcUserDB idc "/server/data/users/userdb.txt"
Alias /idc "/server/weblayout"
Order allow,deny
Allow from all
DirectoryIndex portal.htm
IdcSecurity idc
Note:
Ensure that the UCM Server is configured with the correct host name and port number of the Web Server to be used as its front end.
Check the/server/config/config.cfg config file and make sure the value of HttpServerAddress is correct:
HttpServerAddress=:
10.4.3 Registering OHS mod_osso with OSSO Server
To register OHS mod_osso with OSSO Server, perform the following:
1.Execute the ssoreg.sh tool, which can be found in/sso/bin, where is the directory in which Oracle Single Sign-On is installed.
Note:
Please note that the directory where you want to store the result config file must be created beforehand.
$ cd/sso/bin
$export ORACLE_HOME=
$./ssoreg.sh -oracle_home_path -site_name Stellent_UCM -config_mod_osso TRUE -mod_osso_url http://: -update_mode CREATE -remote_midtier -config_file /temp/osso_ucm.conf
2.Copy this file to the web server instance location.
For example:
/Oracle_WT1/instances/instance1/config/OHS/ohs1/osso/osso_ucm.conf
10.4.4 Configuring mod_osso to Protect Web Resources
Perform similar steps as explained in Section 10.2.4, "Configuring mod_osso to Protect Web Resources" to configure the mod_osso as follows:
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile
${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/osso/osso_ucm.conf
require valid-user
AuthType Osso
10.5 Configuring SSO for Oracle UCM 11g
Oracle UCM 11g Release 1 (11.1.1) is deployed on an Oracle WebLogic Server. Therefore, the steps to configure OAM as the SSO solution for UCM is similar to the steps described in Section 10.2, "Configuring SSO for Learning Tool".
For more detailed explanation on configuring SSO for UCM 11g Release, you can read Chapter 4.2.3 "Configuring Oracle UCM to Use Single Sign-On" in the Oracle® Fusion Middleware System Administrator's Guide for Content Server 11g Release 1 (11.1.1) at
http://download.oracle.com/docs/cd/E14571_01/doc.1111/e10792/c03_security002.htm#insertedID3
10.5.1 Installing HTTP Server
Install web server to be used as a front end to UCM 11g. In this guide, use Oracle HTTP Server 11g, which is available after the installation of Web Tier Utilities 11.1.1.2.0.
10.5.2 Configuring mod_wl_ohs
Perform similar steps as Section 10.2.2, "Configuring mod_wl_ohs" to configure mod_wl_ohs.
LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"
SetHandler weblogic-handler
WebLogicHost
WebLogicPort
Note:
Ensure that the UCM Server is configured with the correct host name and port number of the Web Server to be used as its front end.
Check the/server/config/config.cfg config file and make sure the value of HttpServerAddress is correct:
HttpServerAddress=:
10.5.3 Registering OHS mod_osso with OSSO Server
To register OHS mod_osso with OSSO Server, perform similar steps in Section 10.4.3, "Registering OHS mod_osso with OSSO Server".
10.5.4 Configuring mod_osso to protect Web Resource
Perform similar steps as Section 10.2.4, "Configuring mod_osso to Protect Web Resources" to configure mod_wl_ohs.
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_
NAME}/osso/osso_ucm.conf
require valid-user
AuthType Osso
10.5.5 Setting Up Providers for OSSO in a WebLogic Domain
Perform similar steps as Section 10.2.5, "Setting Up Providers for OSSO in a WebLogic Domain" to set up providers for OSSO in a WebLogic Domain that UCM is deployed to.
10.6 Updating the OSL Configuration
The following configuration is required for OSL to operate in an SSO environment:
1.Update the OSL_PROFILE_OPTION_VALUES:
Set the values for OSL_SHOW_LOGOUT_LINK in OSL_PROFILE_OPTION_VALUES table as follows:
Table 10-1 Updating OSL_PROFILE_OPTION_VALUES
Value Description
OSL_SHOW_LOGOUT_LINK
◦Y (to display the logout link in Learning Tool and Learning Tool Admin) or
◦N (to hide the logout link in Learning Tool and Learning Tool Admin)
2.Update the logout URL for Learning Tool and Learning Tool Admin.
◦Set the OSL_ADMIN_LOGOUT_URL as follows:
http://:/pls/orasso/orasso.wwsso_app_admin.ls_logout?p_done_url=http%3A%2F%2F:%2FLTAdminWeb%2F
where: and are the host name and port of the web server configured as a front end to provide access to the Learning Tool Admin application.
◦Set the OSL_LOGOUT_URL as follows:
http://:/pls/orasso/orasso.wwsso_app_admin.ls_logout?p_done_url=http%3A%2F%2F:%2FLTWeb%2F
where: and are the host name and port of the web server configured as a front end to provide access to the Learning Tool application.
For information about the OSL configuration file where you must make these changes, see Section 9.1.7, "Updating Logout URL for Learning Tool and Learning Tool Admin".
--------------------------------------------------------------------------------
Previous
Next
Copyright © 2009, 2012, Oracle and/or its affiliates. All rights reserved.
Legal Notices
Configuring OSSO SolutionThis chapter provides step-by-step instructions for configuring OSSO as the single sign-on solution for OSL. You can find complete explanation of the OSSO Solution in "Chapter 10 Configuring Single Sign-On in Oracle Fusion Middleware" in the Oracle® Fusion Middleware Security Guide 11g Release 1 (11.1.1) at
http://download.oracle.com/docs/cd/E12839_01/core.1111/e10043/toc.htm
10.1 Installing Oracle Single Sign-On and Oracle Delegated Administration Services
There are no 11g Release 1 (11.1.1) versions of Oracle Single Sign-On and Oracle Delegated Administration Services. However, both Oracle Single Sign-On and Oracle Delegated Administration Services Release 10g (10.1.4.3.0) are certified for use with Oracle Internet Directory 11g Release 1 (11.1.1).
You can find related information in "Chapter 10 Installing Oracle Single Sign-On and Oracle Delegated Administration Services Against Oracle Internet Directory" in the Oracle® Fusion Middleware Installation Guide for Oracle Identity Management 11g Release 1 (11.1.1) at
http://download.oracle.com/docs/cd/E12839_01/install.htm
10.2 Configuring SSO for Learning Tool
To configure SSO for Learning Tool, perform the steps in the subsequent sections.
10.2.1 Installing HTTP Server
Install web server to be used as a front end to the Oracle WebLogic Server. In this guide, we use Oracle HTTP Server (OHS) 11g, which is available after the installation of Web Tier Utilities 11.1.1.2.0.
10.2.2 Configuring mod_wl_ohs
If you select the option “Associate Selected Components with WebLogic Domain” during the installation of Web Tier Utilities, you are able to manage the web server using Enterprise Manager (EM).
This section demonstrates the configuration of mod_wl_ohs using EM. However, it is also possible to do the same configuration by manually editing the configuration files.
To configure mod_wl_ohs from EM, perform the following:
1.Select the OHS instance on the left panel.
2.Select Oracle HTTP Server > Administration > mod_wl_ohs Configuration on the right panel.
Figure 10-1 Configuring mod_wl_ohs
3.Enter the value for WebLogic Host, WebLogic Port, and Locations. Figure 10-2 shows a sample setup for Learning Tool Admin and Learning Tool.
Figure 10-2 Sample mod_wl_ohs configuration for LT Admin
This configuration will effectively be added to the mod_wl_ohs.conf file of this OHS instance. You can also manually modify this file without using the EM.
Note:
If you install Web Tier Utilities, you can locate mod_wl_ohs.conf file at:
For example:
For example:
WebLogicHost yourservername.com
WebLogicPort 7002
SetHandler weblogic-handler
Figure 10-3 Sample mod_wl_ohs configuration for LT
This configuration will effectively be added to the mod_wl_ohs.conf file of this OHS instance. You can also manually modify this file without using the EM.
For example:
WebLogicHost yourservername.com
WebLogicPort 7002
SetHandler weblogic-handler
10.2.3 Registering OHS mod_osso with OSSO Server
To register OHS mod_osso with OSSO server, perform the following:
1.Execute the ssoreg.sh tool, which can be found in
Note:
The directory where you want to store the result config file must be created beforehand.
$cd
$export ORACLE_HOME=
$./ssoreg.sh -oracle_home_path
$./ssoreg.sh -oracle_home_path
where:
2.Copy this file to the web server instance location.
For example:
10.2.4 Configuring mod_osso to Protect Web Resources
To configure mod_osso to protect web resources, perform the following:
1.Enable mod_osso from EM.
Select the OHS instance on the left panel and select Oracle HTTP Server > Administration > Server Configuration on the right panel.
Figure 10-4 Configuring mod_osso
Check the check box for mod_osso and click Apply.
Figure 10-5 Enabling mod_osso
2.Configure mod_osso.
Go to the Advanced Server Configuration. The Advanced Server Configuration screen enables to directly edit the configuration files. From the list, select mod_osso.conf and click Go.
Figure 10-6 Setting up Advanced Server Configuration
Edit the content of this file, see Figure 10-7.
Figure 10-7 Editing Content of mod_osso
You can also manually edit the content of this file without using EM. Below is the sample configuration done for Learning Tool Admin and Learning Tool.
Sample configuration for Learning Tool Admin:
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/osso/osso_admin.conf
require valid-user
AuthType Osso
Sample configuration for Learning Tool:
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/ ${COMPONENT_NAME}/osso/osso_lt.conf
OssoHTTPOnly Off
require valid-user
AuthType Osso
Note:
The configuration directive OssoHTTPOnly must be turned off in the web server configured as a front end to provide access to the Learning Tool application. This is to allow the audio applet in the Learning Tool application to be able to read the OSSO cookies.
10.2.5 Setting Up Providers for OSSO in a WebLogic Domain
Oracle recommends the following Authentication providers:
•OSSO Identity Asserter
•OID Authenticator
•DefaultAuthenticator
To add providers to your WebLogic domain for OSSO Identity Assertion, perform the following:
1.Log in to the WebLogic Administration Console.
2.OSSO Identity Asserter:
Go to Security Realms > Default Realm Name (Example: myrealm) and click Providers.
Select New under the Authentication Providers table.
Enter a name for the new provider, select its type, and click OK.
◦Name: OSSO Identity Asserter
◦Type: OSSOIdentityAsserter
Note:
For OSSOIdentityAsserter to appear in the list, you must copy ossoiap.jar to
The ossoiap.jar is available in
Click the name of the newly added provider.
On the Common tab, set the appropriate values for common parameters and set the Control Flag to SUFFICIENT and then save the settings.
3.Default Authentication Provider:
Go to Security Realms > Default Realm Name (Example: myrealm) and click Providers.
Click DefaultAuthentication Provider.
Set the Control Flag to OPTIONAL and click Save.
4.OID Authenticator:
The instructions to create this provider are provided in Section 8.5, "Configuring OID as Security Provider".
If the OID Authenticator is configured successfully, you can change the Control Flag to SUFFICIENT.
5.Reorder Providers:
◦OSSO Identity Asserter (SUFFICIENT)
◦OID Authenticator (SUFFICIENT)
◦DefaultAuthenticator (OPTIONAL)
6.Save all configuration settings and restart the Oracle WebLogic Server for the changes to take effect.
10.2.6 Configuring web.xml for the OSSO Identity Asserter
Update the
1.Modify the web.xml, which is located at
[OSL Home directory]/LearningTool/Configuration/LearningTool/DeploymentDescriptors/ for Learning Tool and at [OSL Home directory]/LearningTool/Configuration/Admin/DeploymentDescriptors/ for Learning Tool Admin to update the login-config as follows:
2.Run the Configurator to update the EAR files as explained in Section 9.3, "Running the OSL Learning Tool Configurator".
10.3 Configuring SSO for OBIEE
To configure SSO for OBIEE, perform the following steps in the subsequent sections:
10.3.1 Installing HTTP Server
Install web server to be used as a front end to Oracle WebLogic Server. In this guide, use Oracle HTTP Server 11g which is available after the installation of Web Tier Utilities 11.1.1.2.0.
10.3.2 Configuring mod_wl_ohs
If the ear/war file is deployed onto a WebLogic Server, perform similar steps as Section 10.2.2, "Configuring mod_wl_ohs" to configure mod_wl_ohs.
Figure 10-8 Configuring mod_wl_ohs
10.3.3 Registering OHS mod_osso with OSSO Server
To register OHS mod_osso with OSSO Server, perform the following:
1.Execute the ssoreg.sh tool, which can be found in
Note:
The directory where you want to store the result config file must be created beforehand.
$cd
$export ORACLE_HOME=
$./ssoreg.sh -oracle_home_path
http://
where:
2.Copy this file to the web server instance location.
For Example:
10.3.4 Configuring mod_osso to Protect Web Resources
Perform similar steps as explained in Section 10.2.4, "Configuring mod_osso to Protect Web Resources" to configure the mod_osso as follows:
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/ ${COMPONENT_NAME}/osso/osso_bi.conf
Header unset Pragma
OssoSendCacheHeaders off
require valid-user
AuthType Osso
10.3.5 Creating Oracle BI Server Impersonator User
Follow this procedure to create the impersonator user in the BI Server repository.
1.Open the BI Server repository file (.rpd) using BI Administration Tool.
2.Select Manage > Security to display the Security Manager.
3.Select Action > New > User to open the User dialog box.
4.Enter a name and password for this user.
For example:
Name = Impersonator
Password = secret
5.In the Group Membership portion of the dialog box, check the Administrators group to grant the user created as member to this group.
6.Click OK to create the user.
10.3.6 Adding the Impersonator Credentials to Oracle BI Presentation Services Credential Store
Perform this step to add the impersonator credentials to Oracle BI Presentation Services credential store.
1.Navigate to the OracleBI_HOME/web/bin directory.
$export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/OracleBI_HOME/web/bin$./cryptotools credstore -add -infile
Credential Alias: impersonation
>Username: Impersonator
>Password: secret
>Do you want to encrypt the password? y/n (y):
>Passphrase for encryption: another_secret
>Do you want to write the passphrase to the xml? y/n (n):
2.The CryptoTools utility updates the credentialstore.xml file. This file is located in the OracleBIData/web/config.
10.3.7 Configuring Oracle BI Presentation Services to Identify the Credential Store and Decryption Passphrase
Edit the OracleBIData/web/config/instanceconfig.xml file.
10.3.8 Configuring BI Presentation Services to Operate in the SSO Environment
Edit the OracleBIData/web/config/instanceconfig.xml file.
http://
10.4 Configuring SSO for UCM 10g
To configure SSO for UCM 10g, perform the steps in the subsequent sections:
10.4.1 Installing HTTP Server
Install web server to be used as a front end to UCM. In this guide, use Oracle HTTP Server 11g which is available after the installation of Web Tier Utilities 11.1.1.2.0.
10.4.2 Configuring OHS as Web Server for UCM
Inside the httpd.conf of the OHS instance, add the following to configure this OHS instance as the web server for UCM. Make sure that you use the correct library under linux64 or linux folder:
LoadModule IdcApacheAuth
IdcUserDB idc "
Alias /idc "
Order allow,deny
Allow from all
DirectoryIndex portal.htm
IdcSecurity idc
Note:
Ensure that the UCM Server is configured with the correct host name and port number of the Web Server to be used as its front end.
Check the
HttpServerAddress=
10.4.3 Registering OHS mod_osso with OSSO Server
To register OHS mod_osso with OSSO Server, perform the following:
1.Execute the ssoreg.sh tool, which can be found in
Note:
Please note that the directory where you want to store the result config file must be created beforehand.
$ cd
$export ORACLE_HOME=
$./ssoreg.sh -oracle_home_path
2.Copy this file to the web server instance location.
For example:
10.4.4 Configuring mod_osso to Protect Web Resources
Perform similar steps as explained in Section 10.2.4, "Configuring mod_osso to Protect Web Resources" to configure the mod_osso as follows:
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile
${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/osso/osso_ucm.conf
require valid-user
AuthType Osso
10.5 Configuring SSO for Oracle UCM 11g
Oracle UCM 11g Release 1 (11.1.1) is deployed on an Oracle WebLogic Server. Therefore, the steps to configure OAM as the SSO solution for UCM is similar to the steps described in Section 10.2, "Configuring SSO for Learning Tool".
For more detailed explanation on configuring SSO for UCM 11g Release, you can read Chapter 4.2.3 "Configuring Oracle UCM to Use Single Sign-On" in the Oracle® Fusion Middleware System Administrator's Guide for Content Server 11g Release 1 (11.1.1) at
http://download.oracle.com/docs/cd/E14571_01/doc.1111/e10792/c03_security002.htm#insertedID3
10.5.1 Installing HTTP Server
Install web server to be used as a front end to UCM 11g. In this guide, use Oracle HTTP Server 11g, which is available after the installation of Web Tier Utilities 11.1.1.2.0.
10.5.2 Configuring mod_wl_ohs
Perform similar steps as Section 10.2.2, "Configuring mod_wl_ohs" to configure mod_wl_ohs.
LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"
SetHandler weblogic-handler
WebLogicHost
WebLogicPort
Note:
Ensure that the UCM Server is configured with the correct host name and port number of the Web Server to be used as its front end.
Check the
HttpServerAddress=
10.5.3 Registering OHS mod_osso with OSSO Server
To register OHS mod_osso with OSSO Server, perform similar steps in Section 10.4.3, "Registering OHS mod_osso with OSSO Server".
10.5.4 Configuring mod_osso to protect Web Resource
Perform similar steps as Section 10.2.4, "Configuring mod_osso to Protect Web Resources" to configure mod_wl_ohs.
LoadModule osso_module "${ORACLE_HOME}/ohs/modules/mod_osso.so"
OssoIpCheck on
OssoIdleTimeout off
OssoSecureCookies off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_
NAME}/osso/osso_ucm.conf
require valid-user
AuthType Osso
10.5.5 Setting Up Providers for OSSO in a WebLogic Domain
Perform similar steps as Section 10.2.5, "Setting Up Providers for OSSO in a WebLogic Domain" to set up providers for OSSO in a WebLogic Domain that UCM is deployed to.
10.6 Updating the OSL Configuration
The following configuration is required for OSL to operate in an SSO environment:
1.Update the OSL_PROFILE_OPTION_VALUES:
Set the values for OSL_SHOW_LOGOUT_LINK in OSL_PROFILE_OPTION_VALUES table as follows:
Table 10-1 Updating OSL_PROFILE_OPTION_VALUES
Value Description
OSL_SHOW_LOGOUT_LINK
◦Y (to display the logout link in Learning Tool and Learning Tool Admin) or
◦N (to hide the logout link in Learning Tool and Learning Tool Admin)
2.Update the logout URL for Learning Tool and Learning Tool Admin.
◦Set the OSL_ADMIN_LOGOUT_URL as follows:
http://
where:
◦Set the OSL_LOGOUT_URL as follows:
http://
where:
For information about the OSL configuration file where you must make these changes, see Section 9.1.7, "Updating Logout URL for Learning Tool and Learning Tool Admin".
--------------------------------------------------------------------------------
Previous
Next
Copyright © 2009, 2012, Oracle and/or its affiliates. All rights reserved.
Legal Notices
Configuing SSO for OBIEE 10g
To start with what is SSO following is the technocal definition of SSO :– Single sign-on (SSO)is a session/user authentication process that permits a user to enter one name and password in order to access multiple applications. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session. For details please google and you will find lot many details. The above definition has been picked from TechTarget.
How User gets interpreted in SSO environment ::
In an environment where SSO has been implemented, when Oracle BI Presentation Services receives
an incoming web request, it assumes that the user who issued the request has already been
authenticated by the SSO system. Oracle BI Presentation Services uses its own credentials to
establish a connection with the Oracle BI Server on behalf of the end user. User personalization and
access controls such as data-level security are maintained in this environment. Oracle BI
Presentation Services then uses the Oracle BI Server Impersonation feature to create a connection
to the Oracle BI Server on behalf of the authenticated end user.
1. To implement following changes needs to be done in instanceConfig.xml file :
2. Along with this a user with name IMPERSONATE needs to be created in the repository.
3. Impersonator User Credentials needs to be added to Oracle BI Presentation Services Credential Store
The default location of the credentialstore.xml file is OracleBIData_HOME\web\config on Windows and OracleBIData_HOME/web/config on Linux or UNIX.
4. To Add impersonator user credentials to Oracle BI Presentation Services Credential Store.
Navigate to the directory OracleBI_HOME\web\bin on Windows or OracleBI_HOME/web/bin on
Linux or UNIX. This is the location for the CryptoTools utility.
Execute the CryptoTools utility to add the impersonator user credentials to the Oracle BI
Presentation Services Credential Store:
cryptotools credstore -add -infile/web/config/credentialstore.xml
Following is the example for cryptotool utility
cryptotools credstore -add -infile/web/config/credentialstore.xml
>Credential Alias: impersonation
>Username: Impersonator
>Password: secret
>Do you want to encrypt the password? y/n (y):
>Passphrase for encryption: another_secret
>Do you want to write the passphrase to the xml? y/n (n):
>File “/web/config/credentialstore.xml” exists. Do you want to
overwrite it? y/n (y):
Passphrase for encryption : Whatever value you pass for this argument, do remember it as this needs to be used in the instanceConfig.xml
5. configure Oracle BI Presentation Services to identify the Credential Store and decryption passphrase
1 Open the instanceconfig.xml file for editing.
2 Locate the node within this file.
Specify attribute values as shown below. If the node does not exist, create
this element with sub-elements and attributes with attribute values as shown in the following
example.
” passphrase=””/>
6. Configure optional Logoff/Logon URLs.
In environments where Single Sign-On (SSO) is enabled, you can configure log out and log on
links to appear on Oracle BI Presentation Services screens (Login and logout screens). To do so, you add the elements shown in the following table as children of the SSO element in the instanceconfig.xml file.
http://hostname:port/the_url_to_logoff_sso
http://hostname:port/the_url_to_logon_sso
How User gets interpreted in SSO environment ::
In an environment where SSO has been implemented, when Oracle BI Presentation Services receives
an incoming web request, it assumes that the user who issued the request has already been
authenticated by the SSO system. Oracle BI Presentation Services uses its own credentials to
establish a connection with the Oracle BI Server on behalf of the end user. User personalization and
access controls such as data-level security are maintained in this environment. Oracle BI
Presentation Services then uses the Oracle BI Server Impersonation feature to create a connection
to the Oracle BI Server on behalf of the authenticated end user.
1. To implement following changes needs to be done in instanceConfig.xml file :
2. Along with this a user with name IMPERSONATE needs to be created in the repository.
3. Impersonator User Credentials needs to be added to Oracle BI Presentation Services Credential Store
The default location of the credentialstore.xml file is OracleBIData_HOME\web\config on Windows and OracleBIData_HOME/web/config on Linux or UNIX.
4. To Add impersonator user credentials to Oracle BI Presentation Services Credential Store.
Navigate to the directory OracleBI_HOME\web\bin on Windows or OracleBI_HOME/web/bin on
Linux or UNIX. This is the location for the CryptoTools utility.
Execute the CryptoTools utility to add the impersonator user credentials to the Oracle BI
Presentation Services Credential Store:
cryptotools credstore -add -infile
Following is the example for cryptotool utility
cryptotools credstore -add -infile
>Credential Alias: impersonation
>Username: Impersonator
>Password: secret
>Do you want to encrypt the password? y/n (y):
>Passphrase for encryption: another_secret
>Do you want to write the passphrase to the xml? y/n (n):
>File “
overwrite it? y/n (y):
Passphrase for encryption : Whatever value you pass for this argument, do remember it as this needs to be used in the instanceConfig.xml
5. configure Oracle BI Presentation Services to identify the Credential Store and decryption passphrase
1 Open the instanceconfig.xml file for editing.
2 Locate the
Specify attribute values as shown below. If the
this element with sub-elements and attributes with attribute values as shown in the following
example.
6. Configure optional Logoff/Logon URLs.
In environments where Single Sign-On (SSO) is enabled, you can configure log out and log on
links to appear on Oracle BI Presentation Services screens (Login and logout screens). To do so, you add the elements shown in the following table as children of the SSO element in the instanceconfig.xml file.
OAS10g 10.1.3 Clustering
The static configuration model is essentially the same mechanism used in Oracle Application Server 10.1.2 and 9.0.4. It continues to be supported primarily to provide backward compatibility with these earlier releases.
Figure 8-5 Static Node-to-Node Model
Description of "Figure 8-5 Static Node-to-Node Model"
In this configuration, a node list containing the host address and ONS remote listener port for each node in the cluster is supplied. Prior to Oracle Application Server Release 3 (10.1.3.0.0), when ONS configuration data was integrated into opmn.xml, this configuration would have been set in the ons.conf configuration file.
Define the host address and the ONS remote listener port - specified within the subelement of - for each node in the cluster within the subelement. Separate each node from the next with a comma.
For example:
...
Supply the same list for each node in the cluster; each ONS instance will identify itself in the list and ignore that entry.
Note:
The opmn.xml file must be reloaded for changes to take effect in the OPMN runtime. Run the following command on the affected node to reload opmn.xml:
opmnctl reload
This command will not affect OPMN-managed components, including Oracle HTTP Server, OC4J, and deployed applications.
Viewing the Status of a Cluster
You can view the current status of the Oracle Application Server components within a cluster, using either opmnctl or Application Server Control Console.
•Viewing Cluster Status with opmnctl
•Viewing Cluster Status in Application Server Control Console
Viewing Cluster Status with opmnctl
You can check the status of the cluster using opmnctl on any Oracle Application Server node within the cluster.
opmnctl @cluster status
The output shows the status of the components installed in each active Oracle Application Server instance within the cluster:
Processes in Instance: AppSrv1.comp1.yourcompany.com
-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4JGroup:COLORS | OC4J:home | 26880 | Alive
OC4JGroup:COLORS | OC4J:oc4j_soa | 26256 | Alive
HTTP_Server | HTTP_Server | 26879 | Alive
Processes in Instance: AppSrv2.comp2.yourcompany.com-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4JGroup:COLORS | OC4J:home | 26094 | Alive
OC4JGroup:COLORS | OC4J:oc4j_soa | N/A | Down
HTTP_Server | HTTP_Server | 26093 | Alive
http://docs.oracle.com/cd/B31017_01/web.1013/b28950/topology.htm#BIHIBEHI
Figure 8-5 Static Node-to-Node Model
Description of "Figure 8-5 Static Node-to-Node Model"
In this configuration, a node list containing the host address and ONS remote listener port for each node in the cluster is supplied. Prior to Oracle Application Server Release 3 (10.1.3.0.0), when ONS configuration data was integrated into opmn.xml, this configuration would have been set in the ons.conf configuration file.
Define the host address and the ONS remote listener port - specified within the
For example:
...
Supply the same list for each node in the cluster; each ONS instance will identify itself in the list and ignore that entry.
Note:
The opmn.xml file must be reloaded for changes to take effect in the OPMN runtime. Run the following command on the affected node to reload opmn.xml:
opmnctl reload
This command will not affect OPMN-managed components, including Oracle HTTP Server, OC4J, and deployed applications.
Viewing the Status of a Cluster
You can view the current status of the Oracle Application Server components within a cluster, using either opmnctl or Application Server Control Console.
•Viewing Cluster Status with opmnctl
•Viewing Cluster Status in Application Server Control Console
Viewing Cluster Status with opmnctl
You can check the status of the cluster using opmnctl on any Oracle Application Server node within the cluster.
opmnctl @cluster status
The output shows the status of the components installed in each active Oracle Application Server instance within the cluster:
Processes in Instance: AppSrv1.comp1.yourcompany.com
-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4JGroup:COLORS | OC4J:home | 26880 | Alive
OC4JGroup:COLORS | OC4J:oc4j_soa | 26256 | Alive
HTTP_Server | HTTP_Server | 26879 | Alive
Processes in Instance: AppSrv2.comp2.yourcompany.com-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4JGroup:COLORS | OC4J:home | 26094 | Alive
OC4JGroup:COLORS | OC4J:oc4j_soa | N/A | Down
HTTP_Server | HTTP_Server | 26093 | Alive
http://docs.oracle.com/cd/B31017_01/web.1013/b28950/topology.htm#BIHIBEHI
OAS10g 10.1.3 Clustering
Configuring Static Node-to-Node Communication
In this configuration, a node list containing the host address and ONS remote listener port for each node in the cluster is supplied. Prior to Oracle Application Server Release 3 (10.1.3.0.0), when ONS configuration data was integrated into opmn.xml, this configuration would have been set in the ons.conf configuration file.
Define the host address and the ONS remote listener port - specified within the subelement of - for each node in the cluster within the subelement. Separate each node from the next with a comma.
For example:
...
Supply the same list for each node in the cluster; each ONS instance will identify itself in the list and ignore that entry.
Note:
The opmn.xml file must be reloaded for changes to take effect in the OPMN runtime. Run the following command on the affected node to reload opmn.xml:
opmnctl reload
This command will not affect OPMN-managed components, including Oracle HTTP Server, OC4J, and deployed applications.
Viewing the Status of a Cluster
You can view the current status of the Oracle Application Server components within a cluster, using either opmnctl or Application Server Control Console.
•Viewing Cluster Status with opmnctl
•Viewing Cluster Status in Application Server Control Console
Viewing Cluster Status with opmnctl
You can check the status of the cluster using opmnctl on any Oracle Application Server node within the cluster.
opmnctl @cluster status
The output shows the status of the components installed in each active Oracle Application Server instance within the cluster:
Processes in Instance: AppSrv1.comp1.yourcompany.com
-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4JGroup:COLORS | OC4J:home | 26880 | Alive
OC4JGroup:COLORS | OC4J:oc4j_soa | 26256 | Alive
HTTP_Server | HTTP_Server | 26879 | Alive
Processes in Instance: AppSrv2.comp2.yourcompany.com-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4JGroup:COLORS | OC4J:home | 26094 | Alive
OC4JGroup:COLORS | OC4J:oc4j_soa | N/A | Down
HTTP_Server | HTTP_Server | 26093 | Alive
http://docs.oracle.com/cd/B31017_01/web.1013/b28950/topology.htm#BIHIBEHI
In this configuration, a node list containing the host address and ONS remote listener port for each node in the cluster is supplied. Prior to Oracle Application Server Release 3 (10.1.3.0.0), when ONS configuration data was integrated into opmn.xml, this configuration would have been set in the ons.conf configuration file.
Define the host address and the ONS remote listener port - specified within the
For example:
...
Supply the same list for each node in the cluster; each ONS instance will identify itself in the list and ignore that entry.
Note:
The opmn.xml file must be reloaded for changes to take effect in the OPMN runtime. Run the following command on the affected node to reload opmn.xml:
opmnctl reload
This command will not affect OPMN-managed components, including Oracle HTTP Server, OC4J, and deployed applications.
Viewing the Status of a Cluster
You can view the current status of the Oracle Application Server components within a cluster, using either opmnctl or Application Server Control Console.
•Viewing Cluster Status with opmnctl
•Viewing Cluster Status in Application Server Control Console
Viewing Cluster Status with opmnctl
You can check the status of the cluster using opmnctl on any Oracle Application Server node within the cluster.
opmnctl @cluster status
The output shows the status of the components installed in each active Oracle Application Server instance within the cluster:
Processes in Instance: AppSrv1.comp1.yourcompany.com
-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4JGroup:COLORS | OC4J:home | 26880 | Alive
OC4JGroup:COLORS | OC4J:oc4j_soa | 26256 | Alive
HTTP_Server | HTTP_Server | 26879 | Alive
Processes in Instance: AppSrv2.comp2.yourcompany.com-------------------+--------------------+---------+---------
ias-component | process-type | pid | status
-------------------+--------------------+---------+---------
OC4JGroup:COLORS | OC4J:home | 26094 | Alive
OC4JGroup:COLORS | OC4J:oc4j_soa | N/A | Down
HTTP_Server | HTTP_Server | 26093 | Alive
http://docs.oracle.com/cd/B31017_01/web.1013/b28950/topology.htm#BIHIBEHI
Tuesday, February 21, 2012
Web Cache 10.1.2.0.2 as Load Balancer
To configure a single OracleAS Web Cache server as a software load balancer:
1. Download an Automated Release Update (ARU) for bug 4569559.
You can download ARUs from OracleMetalink:
http://metalink.oracle.com
2. Follow the instructions provided in the Readme for the patch.
3. Create a backup copy of the internal.xml file. This file is located in the $ORACLE_HOME/webcache directory on UNIX and ORACLE_HOME\webcache directory on Windows.
4. Use a text editor to open the internal.xml file.
5. Locate the CALYPSOINTERNALPARAMS element.
...
...
6. Add the LOADBALANCE subelement directly after the OEMPERFTOOL subelement as follows:
...
...
7. Save internal.xml.
8. Restart OracleAS Web Cache with the following command:
opmnctl restartproc ias-component=WebCache
9. Verify OracleAS Web Cache is running in the load balancer mode from the OracleAS Web Cache Manager by verifying the following status message displays beneath the Apply Changes and Cancel Changes buttons:
Web Cache running in Load Balancer Mode with current configuration
Application Server Control Console does not provide an equivalent verification status.
10. Ensure the auto-restart mechanism is enabled, as described in "Task 3: Configure Auto-Restart Settings".
11. Configure origin servers, as described in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings".
12. Create site definitions and map them to the origin servers, as described in "Task 10: Configure Web Site Settings".
13. If your application deployment requires session stickiness, enable session binding. See "Bind a Session to an Origin Server".
Applications using OracleAS Single Sign-On and Oracle Delegated Administration Services, for example, require session binding.
If the application that requires session stickiness is an OC4J application, then configure session binding using the JSESSIONID cookie.
Consider the topology depicted in Figure 8-5.
Figure 8-5 Deploying OracleAS Web Cache as a Load Balancer
Description of "Figure 8-5 Deploying OracleAS Web Cache as a Load Balancer"
To configure this topology:
1. Register the IP address of the OracleAS Web Cache server webche-host with www.app1.company.com.
2. Configure the OracleAS Web Cache server with the following:
a. Receive HTTP and HTTPS requests on designated listening ports.
b. Send HTTP and HTTPS requests to application Web servers app1-host1 and app1-host2 on designated listening ports.
c. Map virtual host site definition for www.app1.company.com mapped to app1-host1 and app1-host2.
Task 3: Configure Auto-Restart Settings
OracleAS Web Cache provides an auto-restart mechanism that checks that the cache server process is running and automatically restarts the cache server process if it is not running.
If auto-restart is enabled, the auto-restart mechanism restarts the cache server if it stops. By default, auto-restart is enabled.
Note:
If you installed OracleAS Web Cache as part of an Oracle Application Server installation, the auto-restart mechanism is run by Oracle Process Manager and Notification (OPMN) Server. If you installed OracleAS Web Cache from a kit that included only this product, the auto-restart mechanism is run by the OracleAS Web Cache monitor.
To change the auto-restart settings in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Auto-Restart.
See Also:
"Modifying Auto-Restart Settings" in Enterprise Manager Online Help for instructions
To specify the settings for auto-restart in OracleAS Web Cache Manager:
1. In the navigator frame, select Properties > Auto-Restart.
The Auto-Restart page appears.
2. To change the default settings, click Edit.
The Edit Auto-Restart dialog box is displayed.
3. If auto-restart is not enabled, in the Enabled field, select Yes.
4. You can specify that the auto-restart mechanism polls (pings) the OracleAS Web Cache cache server at specified intervals. It does this by sending requests to a specified URL. If it cannot connect to the cache server or if the cache server does not respond within a specified time, the auto-restart mechanism restarts the cache server process.
Note that the auto-restart mechanism will restart the cache server if it has failed, whether or not you enable pinging. However, if you enable pinging, the auto-restart mechanism will attempt to restart the cache if it receives network errors in response to its ping attempts.
If you do not want the auto-start mechanism to actively ping the cache server, disable pinging by selecting No in the Pinging Enabled field.
To enable pinging:
a. In the Pinging Enabled field, select Yes.
b. In the Failover Threshold field, enter the number of consecutive failed requests before the auto-restart mechanism considers the cache server to have failed. Only network errors, including timeout errors, are counted as failed requests.
The default is three failures.
For each failed request, OracleAS Web Cache increments the failure counter. When a request is successfully processed by the cache server, OracleAS Web Cache resets the failure counter.
When the failover threshold is met, the auto-restart mechanism starts the cache server.
Note:
The threshold applies only to network errors and timeouts. If the cache server process is not running, the auto-restart mechanism immediately restarts the cache server.
c. In the Ping URL field, enter the URL that the auto-restart mechanism will use to poll the cache server.
You must use a URL that is cacheable and is guaranteed to be stored in the cache. The default is /_oracle_http_server_webcache_static_.html, which is stored in the cache. If your environment uses a hardware load balancer with pinging capability, then configure the load balancer with this ping URL to ping each OracleAS Web Cache server on a periodic basis.
d. In the Ping Interval field, enter the time, in seconds, between attempts by the auto-restart mechanism to poll the cache server.
The default value is 15 seconds.
e. In the Ping Timeout field, enter the time, in seconds, that the auto-restart mechanism will wait for a response from the cache server.
The default value is 30 seconds.
5. Click Submit.
Task 9: Configure Origin Server, Load Balancing, and Failover Settings
Configure OracleAS Web Cache with the application Web servers or proxy servers to which it sends cache misses. Typically, OracleAS Web Cache uses application Web servers for internal sites and proxy servers for external sites outside a firewall.
By default, the listening port and host name of the Oracle HTTP Server are configured. When OracleAS Web Cache is installed, Oracle HTTP Server has a default listening HTTP port of 7778 during the first installation sequence.
OracleAS Web Cache only forwards requests to a configured origin server if the server is mapped to a Web site. If you are configuring load balancing for a site, then create one site-to-server mapping that maps all the applicable origin servers to the site.
See Also:
● "Stateless Load Balancing" for an overview of load balancing
● "Task 10: Configure Web Site Settings" for instructions on configuring site-to-server mappings
To configure OracleAS Web Cache with origin server information from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Origin Servers.
See Also:
"Configuring Origin Servers" in Enterprise Manager Online Help for instructions
To configure OracleAS Web Cache with origin server information from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Origin Servers.
The Origin Servers page appears.
2. Click Add in the Application Web Servers or Proxy Servers section.
The Add Application Web Server or Proxy Server dialog box appears.
3. In the Hostname field, enter the host name of the origin server.
4. In the Port field, enter the listening port from which the origin server will receive OracleAS Web Cache requests.
Note:
OracleAS Web Cache must listen on the same port as the application Web server being proxied. When configuring proxy servers, ensure there is a corresponding listening port for every port that will need to be proxied.
5. In the Routing field, select ENABLED to permit OracleAS Web Cache to route requests to the origin server or DISABLED to only serve requests from cache.
Oracle recommends selecting DISABLED if temporary maintenance of an origin server is needed.
OracleAS Web Cache tries to route a request matching a particular site to all origin servers mapped to that site. If all of the origin servers have a routing of DISABLED, OracleAS Web Cache serves a network error page to clients.
See Also:
"Configure Error Pages"
6. In the Capacity field, enter the maximum number of concurrent connections that the origin server can accept.
You determine this number by load testing the origin server until it runs out of CPU, responds slowly, or until a backend database reaches full capacity.
In a cache cluster, OracleAS Web Cache ensures that the total number of connections from all cluster members to the origin server does not exceed the capacity. Each cluster member is allowed a percentage of the maximum connections, using the following formula:
connections_from_each_cluster_member = capacity / number_of_cluster_members
7. In the Failover Threshold field, enter the number of allowed continuous read/write failures with an origin server on established connections.
The default is five request/response failures.
If any connection failure occurs, OracleAS Web Cache immediately considers an origin server down.
When the threshold is met, OracleAS Web Cache considers the origin server down and performs automatic failover of the origin servers. If an origin server fails at any time after OracleAS Web Cache has started to send a request, then OracleAS Web Cache increments the failure counter. The failure counter is reset in the event of a successful server response. A request is considered failed if:
● There are any network errors other than connection failure errors.
● The HTTP response status code is less than 100, or is one of the following messages: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout.
After the threshold is met, OracleAS Web Cache considers the server down and uses other servers for future requests. OracleAS Web Cache starts polling the down server, by sending requests to the URL specified in the Ping URL field. When OracleAS Web Cache receives a successful response from the server without any network errors and the HTTP response code is not less than 100, or not equal to 500, 502, 503, 504, OracleAS Web Cache considers the server up again and uses it for future requests.
Note:
● The threshold does not apply if OracleAS Web Cache cannot connect to an origin server. In this case, OracleAS Web Cache immediately considers the server down and does not use it for future requests. If there are other origin servers, OracleAS Web Cache retries the request to another origin server. If there no servers configured, OracleAS Web Cache returns an error.
● The failover to another origin server does not apply if there is only one origin server left.
8. In the Ping URL field, enter the URL that OracleAS Web Cache will use to poll an origin server that has reached its failover threshold:
● For an application Web Server, enter either a relative or a fully-qualified URL that includes the domain name, or site name, representing the virtual host of the application Web server.
● For a proxy server, enter a fully-qualified URL that includes the domain name, or site name, representing the virtual host of the origin server behind the proxy server.
Rather than using a static URL, Oracle recommends using a URL that checks the health of the application logic on the origin server and returns the appropriate HTTP 200 or 500 status codes. The default is "/".
9. In the Ping Interval (seconds) field, enter the time, in seconds, that OracleAS Web Cache will poll an origin server that has reached its failover threshold.
The default is 10 seconds.
10. From the Protocol list, select either HTTP to send HTTP requests on the port or HTTPS to send HTTPS requests on the port.
See Also:
"Secure Sockets Layer (SSL)"
11. Click Submit.
12. If you selected HTTPS as the listening protocol, specify the location of the wallet for OracleAS Web Cache communication to the origin server (Origin Servers, Sites, and Load Balancing > Origin Server Wallet).
See Also:
"Task 4: Configure HTTPS Port and Wallet Location for the Origin Server" for information about configuring the wallet
Task 10: Configure Web Site Settings
For OracleAS Web Cache to act as a virtual server for one or more Web sites, configure OracleAS Web Cache with information about the Web site. To configure settings for a Web site, perform the following tasks:
● Creating Site Definitions
● Configure Error Pages
● Bind a Session to an Origin Server
Creating Site Definitions
The installation process creates a default site definition that uses the host name and listening port of the computer on which Oracle HTTP Server was installed. OracleAS Web Cache forwards requests without host information to this site.
You need to create site definition for any named sites. A site definition consists of a host name, port information, and optional URL path prefix about the site and its aliases. Alias information is essential, because many sites are represented by one or more aliases. OracleAS Web Cache recognizes and caches requests for a site and its aliases. For example, site www.company.com:80 may have an alias of company.com:80. By specifying this alias, OracleAS Web Cache caches the same content from either company.com:80 or www.company.com:80. If a request includes a site alias that is not configured, OracleAS Web Cache sends the request to the default site.
The following sections show examples of site definitions and explain how to configure new site definitions:
● Default Site Example
● Virtual Host Site Examples
● ESI Provider Site Example
● Creating New Site Definitions
Default Site Example
For those requests that do not include a Host request-header field, OracleAS Web Cache sends the request to the default site. The default site, established during installation, uses the host name and listening port of the computer on which Oracle HTTP Server was installed. Figure 8-1 shows an example of a default site definition from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The rules for the default site are as follows:
● The site definition in the Named Sites Definitions section maps HTTP requests to the origin server host-server:7778. If you select to edit this definition, you can view the ESI content policy from the Advanced tab. The ESI content policy is set to Unrestricted, which instructs OracleAS Web Cache to serve site content, as well as assemble ESI include fragments.
● The first mapping *.80 in the Server Mapping for Unnamed Site uses a * wildcard host name to map all other virtual site names to the origin server. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first rule.
● The second mapping *.* in the Server Mapping for Unnamed Site uses a * wildcard host name to map all other virtual site names to the origin server and a * wildcard port number to map the site name to multiple port numbers. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first two rules.
Figure 8-1 Default Site Definitions
Description of "Figure 8-1 Default Site Definitions"
Note:
If you modify the name of the default site, you must also modify the ServerName directive in the httpd.conf file. See "Task 7: Provide Directives to Oracle HTTP Server".
Virtual Host Site Examples
Figure 8-2 shows how you would configure a virtual host site named www.company.com:80 without ESI content from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The site definition in the Named Sites Definitions section maps HTTP requests to site www.company.com:80 and and site alias company.com:80 to origin server host-server:7778. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from host-server:7778 for this site.
Figure 8-2 Example: Site Settings for a Virtual Host Site
Description of "Figure 8-2 Example: Site Settings for a Virtual Host Site"
Figure 8-3 shows how you would configure a virtual host site named www.1st.company.com:80 and www.2nd.company.com with ESI content from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The rules are as follows:
● The site definitions in the Named Sites Definitions section map HTTP requests to sites www.1st.company.com:80 and www.2nd.company.com:80 and respective aliases 1st.company.com and 2nd.company.com to origin server host-server:7778. The ESI content policy is set to Unrestricted, which enables OracleAS Web Cache to serve site content, as well as assemble ESI include fragments.
● The mapping www.*.company.com:80 in the Server Mapping for Unnamed Site uses a * wildcard host name to map sites matching www.*.company.com to origin server host-server:7778. The ESI content policy is set to Unrestricted.
Figure 8-3 Example: Site Settings for Multiple Virtual Host Sites
Description of "Figure 8-3 Example: Site Settings for Multiple Virtual Host Sites"
ESI Provider Site Example
Figure 8-4 shows how you would configure ESI provider sites named www.providersite1.com:80 and www.providersite2.com from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The site definitions in the Named Sites Definitions section specify how to map HTTP requests to sites www.providersite1.com:80 and www.providersite2.com:80 and respective aliases providersite1.com and providersite2.com. Requests to www.providersite1.com map to proxy-host:80. There is no origin server specified for www.providersite2.com, because the proxy server is not known. Instead, DNS will be used to resolve the site name to the appropriate server. The ESI content policy is set to Fragments Only, which restricts OracleAS Web Cache from using this mapping for any content that is not ESI.
Figure 8-4 Example: Site Settings for Multiple ESI Provider Sites
Description of "Figure 8-4 Example: Site Settings for Multiple ESI Provider Sites"
Creating New Site Definitions
If the default site definition is not adequate for your configuration, create additional site definitions.
To create new site definitions from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Site Properties for a Named Site" or "Configuring Site Properties for an Unnamed Site" in Enterprise Manager Online Help for instructions
Using OracleAS Web Cache Manager, you can either discover site and alias information from Oracle HTTP Server, or you can manually create definitions. Oracle recommends using the site discovery feature to initially create the necessary definitions. After discovery is complete, you can manually create additional site definitions. Application Server Control Console does not support site discovery.
See Also:
Help for the Site Definitions page in OracleAS Web Cache Manager Online Help for instructions on using the site discovery feature
To create new site definitions from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site Definitions.
The Site Definitions page appears.
Note:
● It may not be possible to specify a site definition for an external ESI provider site. If an ESI request is made to a provider that does not match any application Web server mapping, then OracleAS Web Cache uses Domain Name System (DNS) to resolve the site name. Note that this will not work if there is a firewall between the cache and the ESI provider. In that case, you must provide a proxy server mapping that directs the request to the appropriate proxy.
● Undefined ESI provider sites disable the following OracleAS Web Cache features:
— Performance assurance heuristics
— Origin server features, such as surge protection, load balancing, failover, and session binding
● It is not possible to configure only ESI provider sites. In a configuration with ESI provider sites, at least one virtual host site definition must exist for ESI template pages.
2. Specify the site information:
a. In the Site Definitions page, click Add Site.
The Add Site dialog box appears.
b. In the Host Name field, enter the site host name, for example, www.company.com. To enable OracleAS Web Cache to match requests to this site, do not add protocol information (http:// or https://) to the host name.
Note:
Do not use the wildcard * in the Host Name field to represent multiple sites.
c. Optionally, in the URL Path Prefix field, enter the path prefix of the URLs to distinguish this site from another site that shares the same host name. Ensure the prefix starts with "/" to distinguish from another site that shares the same host name. Do not include the file name or embedded URL parameters in the prefix.
The prefix is excluded in matching requests to the site.
For example, the following URLs share the same site name, but belong to two entirely differently applications hosted on entirely different origin servers:
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
While the first URL shows an email user a front page after login, the second URL displays an inbox. If the site host name is defined as www.company.com, then you specify the prefixes as /portal and /um to distinguish the sites. Requests are matched for www.company.com, not www.company.com/portal and www.company.com/um.
d. In the Port Number field, enter the port number from which the Web site is listening for incoming HTTP requests.
The port number should be the port used in client requests.
In a configuration in which the OracleAS Web Cache listen port is the same as the logical site port, changing the OracleAS Web Cache listen port requires you to also change the logical site port in both the Site Definitions and Site-to-Server Mapping pages.
e. In the HTTPS Only Prefix field, enter the URL prefix for which only HTTPS requests will be served. If you must restrict all traffic to HTTPS, enter "/ " for the entire site.
f. In the URL Parameter to Ignore field, specify site-specific embedded URL or POST body parameters to ignore.
By configuring OracleAS Web Cache to ignore the value of embedded URL or POST body parameters, you enable OracleAS Web Cache to serve one cached object to multiple sessions requesting the same page. OracleAS Web Cache caches the response to the first request and serves subsequent requests for the page from its cache.
If you prefer instead to set a global parameter to apply to all sites, click Global URL Parameters to Ignore from the main Site Definitions page.
See Also:
● Excluding the Value of Embedded URL or POST Body Parameters for an overview and an example scenario
● Configuring OracleAS Web Cache to Exclude the Value of Embedded URL or POST Body Parameters for instructions on setting global parameters
g. In the Client-Side Certificate field, select Required or Not Required to specify that OracleAS Web Cache require or not require client-side certificates from client browsers.
A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user's public key and must be digitally signed by a trusted CA.
h. In the Default Site field, select Yes to specify the site as the default site, or select No to specify this site as a nondefault site.
If you select Yes for a site, another site that previously had the Yes setting will change to No.
If the default site includes a URL path prefix, the prefix is excluded in matching requests to the site. For example, if you specify a default site of www.company.com and a URL path prefix of /portal, requests are matched for www.company.com, not www.company.com/portal.
See Also:
"Default Site Example" for information about how the default site is used
i. In the Create Alias from Site Name with/without www field, select either Yes or No.
● Select Yes to use the site name as a site alias.
For example, if the site domain name is company.com, a site alias of www.company.com will be used. If the site domain name is www.company.com, a site alias of company.com will be used.
● Select No if you do not want to use the site name as a site alias.
3. If the site uses additional aliases, map the site to those aliases.
Important:
To ensure requests are directed to the correct site, specify all possible variations of the site name. If a request includes a site alias that is not configured, OracleAS Web Cache sends the request to the default site.
a. In the Site Definitions page, select a site, and then click Add Alias.
The Add Alias for Site dialog box appears.
b. In the Host Name field, enter the site alias name, such as company.com.
Note:
Do not use the wildcard * in the Host Name field to represent multiple aliases.
c. In the Port Number field, enter the HTTP or HTTPS port number from which the alias is listening for incoming HTTP requests.
The port number should be the port used in client requests.
4. Click Submit.
To map sites to origin servers from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Site Properties for a Named Site" in Enterprise Manager Online Help for instructions
To map sites to origin servers from OracleAS Web Cache Manager, take the following steps:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping.
The Site-to-Server Mapping page appears.
2. Click Create if no mappings exist. If mappings already exist, select a mapping, and then click Insert Above or Insert Below.
The Create Site-to-Server Mapping or Edit/Add Site-to-Server Mapping dialog box appears.
3. In the Edit Site Name section, select one of the following options:
● Enter Site Name to enter the site name, such as www.company.com or *.company.com, as well as the HTTP or HTTPS port number from which the site is listening for incoming requests.
● Select from Site definitions to select a site definition created in the Site Definitions page.
Note:
You can use the wildcard * in the Host Name field in the following ways:
● Map multiple site names to one or more application Web server or proxy servers. For example, *.company.com can be used to match sites site1.company.com and site2.company.com.
● Route cache misses to undefined ESI provider sites outside a firewall and accessible by a proxy server. For example, * can be used to map to proxy server proxy-host.
You can use the wildcard * in the Port Number field to map the same site name with different port numbers to the same origin servers. If the origin servers are proxy servers, ensure they were configured to listen on the same port as the application Web server being proxied, as described in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings".
This option does not enable you to create a site definition. You must create a site definition in the Site Definitions page.
4. In the Select either application Web servers or proxy servers to which this Site is mapped, select one of the following options:
● Select Application Web Servers to select application Web servers specified in the Origin Servers page
● Select Proxy Servers to select proxy servers specified in the Origin Servers page
Note:
If you configured multiple origin servers in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings" for load balancing, then create one site-to-server mapping that maps all the applicable origin servers to the site. In that site-to-server mapping, select all the origin servers that apply for the site. If you split the origin servers among multiple site-to-server mappings, load balancing for the site will not occur in the intended manner.
5. In the Exclude section, select one of the following options to restrict OracleAS Web Cache access to the origin servers for the sites specified in Edit Site Name.
● Exclude Fragments restricts OracleAS Web Cache from using this mapping for ESI fragments. Select this option if the site is a virtual host site that does not provide ESI content.
● Fragments Only restricts OracleAS Web Cache from using this mapping for any content that is not an ESI fragment. Select this option if the site is an ESI provider site.
● Unrestricted does not enforce any OracleAS Web Cache restrictions. Select this option if the site is a virtual host site that supports ESI.
For example, one mapping entry that uses Exclude Fragments does not mean that OracleAS Web Cache is not allowed to assemble ESI content from other origin servers.
6. Click Submit.
7. After you create the mappings, order them. For each request, the first matching mapping is used.
In the Site-to-Server Mapping page, select a mapping, and then click Move Up or Move Down to order the mappings. Note the following:
● Because mappings that use the wildcard * encompass a broader scope, give these mappings a lower priority than other mappings.
● Because requests are resolved to the first matching mapping, give mappings that contain the optional URL path prefix a higher priority than those mappings without an URL path prefix.
For example, you should order the following mappings as follows:
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
http://www.company.com
If you instead reorder the mappings as follows, the request for URLs http://www.company.com/portal/page?_pageid=33,4232&_dad=portal and http://www.company.com/um/traffic_cop?mailid=inbox will never be reached. Requests for these URLs will instead resolve to http://www.company.com because it is listed first:
http://www.company.com
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
Note:
If the protocol used in the src attribute of an tag attribute does not match the protocol specified in the Site-to-Server Mapping page, then OracleAS Web Cache uses the protocol configured for the origin server in the Site-to-Server Mapping page. OracleAS Web Cache also reports the following warning message to the event log:
ESI include fragment protocol does not match origin server protocol: Origin Server Protocol=protocol URL=URL
For example, if the template page is configured with
[25/Jul/2005:19:30:48 +0000] [warning 11250] [ecid: -] ESI include fragment protocol does not match origin server protocol: Origin Server Protocol=http URL=https://www.company.com/gifs/frag1.gif
Configure Error Pages
For configured sites, specify error pages to be served from OracleAS Web Cache for network communication errors, site busy errors, and ESI errors:
1. Create error pages and place them in the $ORACLE_HOME/webcache/files directory on UNIX and the ORACLE_HOME\webcache\files directory on Windows. The default settings are as follows:
● For network errors, the default setting is set to network_error.html. This error page is served when there is a network problem while connecting, sending, or receiving a response from an origin server for a cache-miss request.
● For site busy errors, the default setting is set to busy_error.html. This page is served when origin server capacity is reached.
● For ESI default fragments, the default setting is set to esi_fragment_error.txt. This page is served when OracleAS Web Cache is unable to fetch the src specified in an tag and the alt attribute, onerror attribute, or the try |attempt |except block are either not present or fail.
See Also:
"Exceptions and Errors"
For a production environment, modify the defaults or create entirely new error pages to be consistent with other error pages for the site.
2. Configure OracleAS Web Cache with the error pages.
You can modify the settings for error pages in one of two ways:
● Change the default settings, and apply it to all defined sites.
● Modify the error page settings for a specific site.
From Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Default Error Pages" in Enterprise Manager Online Help for instructions on configuring error pages
From OracleAS Web Cache Manager, perform these steps to configure error pages:
● In the navigator frame, select Origin Servers, Sites, and Load Balancing > Error Pages.
The Error Pages page appears.
● Select either Default Pages or a site name in the table, and then click Edit.
The Edit Error Pages dialog box appears.
● In the Network Error Page field, enter the file name of the error page that will be delivered for network communication problems between OracleAS Web Cache and the Web site.
If you are using the default network_error.html page, leave the field as is.
● In the Site Busy Page field, enter the file name of the error page that will be delivered when a Web site is saturated with requests.
If you are using the default busy_error.html page, leave the field as is.
● In the ESI Default Fragment field, enter the file name of the page that will be delivered when OracleAS Web Cache is unable to retrieve an HTML fragment for an tag.
If you are not using tags for partial page caching or you want to use only ESI language elements for exceptions, do not enter a value.
● Click Submit.
If you selected Default Pages in Step b, the new settings will be applied to all defined sites with the default page setting. However, the new setting will not be applied to undefined sites. If you selected a specific site in Step b, the new settings will be applied to just to the site.
See Also:
"Exceptions and Errors" to understand how exceptions and error are handled for errors
Bind a Session to an Origin Server
Notes:
● When a session cookie expires, OracleAS Web Cache does not continue to bind the user session to the origin server. Instead, OracleAS Web Cache uses load balancing to choose an origin server. To avoid pages being served past the client session expiration time, ensure that the session cookie expires before the origin server expires the client session.
● If an origin server is busy, OracleAS Web Cache disables session binding to that origin server.
You can configure OracleAS Web Cache to support session binding, whereby a user session for a particular site is bound to an origin server in order to maintain state for a period of time. To utilize this feature, the origin server itself must maintain state; that is, it must be stateful.
If a request is forwarded to an origin server for an object requiring session binding, the origin server creates the user session by including the session information to clients through OracleAS Web Cache in the form of a session cookie or an embedded URL parameter. OracleAS Web Cache does not process the value of the parameter or cookie; it simply passes the information back to the client browser. When a client includes the session information in a subsequent request, OracleAS Web Cache forwards the request to the origin server that originally created the user session. OracleAS Web Cache binds the user session to that particular origin server.
If you have configured a cache cluster, you must enable tracking of session bindings through the use of a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.
See Also::
● "Session Binding(Stateful Load Balancing)" for an overview of origin server binding
● "Task 3: Enable Tracking of Session Binding" for instructions on enabling session tracking in a cluster
By default, session binding is not enabled for any sites. If there is no session binding specified for a site, then the default session binding setting is applied, which uses the Default Session Binding rule. The Default Session Binding rule has a default value of Disable Session Binding. You can enable session binding in one of two ways:
● Change the default value of the Default Session Binding rule from Disable Session Binding to a specific session and binding mechanism. OracleAS Web Cache applies these settings to all sites that use the Default Session Binding rule. If you decide to change the value of the Default Session Binding rule, ensure all named sites currently configured with this rule require session binding. If some sites do not require session binding, leave the value of Disable Session Binding, and instead specify session binding settings for the site. Use the next option.
● Overwrite the default session binding setting to some other session for a specific site.
To enable session binding in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Session Binding Settings" in Enterprise Manager Online Help for instructions
To enable session binding from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Session Binding.
The Session Binding page appears.
2. In the Session Binding page, select Default Session Binding or a specific site name in the table, and then click Edit Selected.
The Edit Session Binding dialog box appears.
3. From the Please select a session list:
● If you selected the Default Session Binding rule in Step 2, change the session value from Use Default Session Binding to another defined session, and then skip to Step 4.
● If you selected a specific site in Step 2, change the session value from Disable Session Binding to a defined session, and then skip to Step 3. Table 8-1 provides descriptions of the default session definitions provided at installation time.
If you want OracleAS Web Cache to bind user sessions with multiple cookies when any cookie is set, select a session of Any Set Cookie. When selecting Any Set Cookie, in Please select a session binding mechanism, select Cookie-Based to instruct OracleAS Web Cache to include a Set-Cookie response-header in the response.
If the sessions listed do not contain the definition you require, click Cancel to exit the Edit Session Binding dialog box. Continue to Step 4.
4. Create a session definition:
● In the navigator frame, select Rules for Caching, Personalization, and Compression > Session Definitions.
The Session Definitions page appears.
● From the For Site list, select the Web site for which you want to create site-specific site definitions.
● Click Add or Create.
The Edit/Add Session Definition dialog box appears.
● In the Session Name field, enter an easy-to-remember unique name.
● Enter the cookie name in the Cookie Name field and the embedded URL parameter in the URL or Post body parameter field.
If you enter both a cookie name and an embedded URL parameter, keep in mind that both must be used to support the same session. If they support different sessions, create separate session definitions. You can specify up to 20 session definitions for each page.
Note:
OracleAS Web Cache requires a session cookie to perform session binding. If client browsers do not support cookies and you want to use an embedded URL parameter for the session, then perform the following for OracleAS Web Cache to perform session binding on the session:
1. In addition to the URL Parameter field, specify a cookie name for the session in the Cookie Name field.
2. Ensure that the origin server returns a Set-Cookie response-header with the value of the session every time a session is created.
Set-Cookie: cookie=value
Set value to the same value as set in the URL Parameter field.
OracleAS Web Cache uses the Set-Cookie response header, even if ignored by browsers, to locate the session cookie value for session binding.
See Also: http://www.rfc-editor.org/ for further information about the Set-Cookie response header
● Click Submit.
● Repeat Steps 1 through 3.
5. From the Please select a session binding mechanism list, select one of the following mechanisms:
● Cookie-based: Select if the client supports cookies. OracleAS Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between OracleAS Web Cache and the client browser.
● OC4J-based: Select if the application is based on OC4J. OracleAS Web Cache forwards routing information with each request to OC4J through Oracle HTTP Server.
● Internal-tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and OC4J. This option is intended for backward compatibility with earlier releases of OracleAS Web Cache. OracleAS Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must bind at the load balancer layer.
6. Click Submit.
If you selected the Default Session Binding rule in Step 2, the new settings will be applied to all defined sites with the default session binding setting. However, the new default will not be applied to undefined sites. If you selected a specific site in Step 2, the new settings will be applied to just the site.
Bind a Session to an Origin Server
Notes:
● When a session cookie expires, OracleAS Web Cache does not continue to bind the user session to the origin server. Instead, OracleAS Web Cache uses load balancing to choose an origin server. To avoid pages being served past the client session expiration time, ensure that the session cookie expires before the origin server expires the client session.
● If an origin server is busy, OracleAS Web Cache disables session binding to that origin server.
You can configure OracleAS Web Cache to support session binding, whereby a user session for a particular site is bound to an origin server in order to maintain state for a period of time. To utilize this feature, the origin server itself must maintain state; that is, it must be stateful.
If a request is forwarded to an origin server for an object requiring session binding, the origin server creates the user session by including the session information to clients through OracleAS Web Cache in the form of a session cookie or an embedded URL parameter. OracleAS Web Cache does not process the value of the parameter or cookie; it simply passes the information back to the client browser. When a client includes the session information in a subsequent request, OracleAS Web Cache forwards the request to the origin server that originally created the user session. OracleAS Web Cache binds the user session to that particular origin server.
If you have configured a cache cluster, you must enable tracking of session bindings through the use of a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.
See Also::
● "Session Binding(Stateful Load Balancing)" for an overview of origin server binding
● "Task 3: Enable Tracking of Session Binding" for instructions on enabling session tracking in a cluster
By default, session binding is not enabled for any sites. If there is no session binding specified for a site, then the default session binding setting is applied, which uses the Default Session Binding rule. The Default Session Binding rule has a default value of Disable Session Binding. You can enable session binding in one of two ways:
● Change the default value of the Default Session Binding rule from Disable Session Binding to a specific session and binding mechanism. OracleAS Web Cache applies these settings to all sites that use the Default Session Binding rule. If you decide to change the value of the Default Session Binding rule, ensure all named sites currently configured with this rule require session binding. If some sites do not require session binding, leave the value of Disable Session Binding, and instead specify session binding settings for the site. Use the next option.
● Overwrite the default session binding setting to some other session for a specific site.
To enable session binding in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Session Binding Settings" in Enterprise Manager Online Help for instructions
To enable session binding from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Session Binding.
The Session Binding page appears.
2. In the Session Binding page, select Default Session Binding or a specific site name in the table, and then click Edit Selected.
The Edit Session Binding dialog box appears.
3. From the Please select a session list:
● If you selected the Default Session Binding rule in Step 2, change the session value from Use Default Session Binding to another defined session, and then skip to Step 4.
● If you selected a specific site in Step 2, change the session value from Disable Session Binding to a defined session, and then skip to Step 3. Table 8-1 provides descriptions of the default session definitions provided at installation time.
If you want OracleAS Web Cache to bind user sessions with multiple cookies when any cookie is set, select a session of Any Set Cookie. When selecting Any Set Cookie, in Please select a session binding mechanism, select Cookie-Based to instruct OracleAS Web Cache to include a Set-Cookie response-header in the response.
If the sessions listed do not contain the definition you require, click Cancel to exit the Edit Session Binding dialog box. Continue to Step 4.
4. Create a session definition:
● In the navigator frame, select Rules for Caching, Personalization, and Compression > Session Definitions.
The Session Definitions page appears.
● From the For Site list, select the Web site for which you want to create site-specific site definitions.
● Click Add or Create.
The Edit/Add Session Definition dialog box appears.
● In the Session Name field, enter an easy-to-remember unique name.
● Enter the cookie name in the Cookie Name field and the embedded URL parameter in the URL or Post body parameter field.
If you enter both a cookie name and an embedded URL parameter, keep in mind that both must be used to support the same session. If they support different sessions, create separate session definitions. You can specify up to 20 session definitions for each page.
Note:
OracleAS Web Cache requires a session cookie to perform session binding. If client browsers do not support cookies and you want to use an embedded URL parameter for the session, then perform the following for OracleAS Web Cache to perform session binding on the session:
1. In addition to the URL Parameter field, specify a cookie name for the session in the Cookie Name field.
2. Ensure that the origin server returns a Set-Cookie response-header with the value of the session every time a session is created.
Set-Cookie: cookie=value
Set value to the same value as set in the URL Parameter field.
OracleAS Web Cache uses the Set-Cookie response header, even if ignored by browsers, to locate the session cookie value for session binding.
See Also: http://www.rfc-editor.org/ for further information about the Set-Cookie response header
● Click Submit.
● Repeat Steps 1 through 3.
5. From the Please select a session binding mechanism list, select one of the following mechanisms:
● Cookie-based: Select if the client supports cookies. OracleAS Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between OracleAS Web Cache and the client browser.
● OC4J-based: Select if the application is based on OC4J. OracleAS Web Cache forwards routing information with each request to OC4J through Oracle HTTP Server.
● Internal-tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and OC4J. This option is intended for backward compatibility with earlier releases of OracleAS Web Cache. OracleAS Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must bind at the load balancer layer.
6. Click Submit.
If you selected the Default Session Binding rule in Step 2, the new settings will be applied to all defined sites with the default session binding setting. However, the new default will not be applied to undefined sites. If you selected a specific site in Step 2, the new settings will be applied to just the site.
http://www.scribd.com/doc/54944312/8/Configure-OracleAS-Web-Cache-to-Act-Solely-as-a-Software-Load-Balancer
1. Download an Automated Release Update (ARU) for bug 4569559.
You can download ARUs from OracleMetalink:
http://metalink.oracle.com
2. Follow the instructions provided in the Readme for the patch.
3. Create a backup copy of the internal.xml file. This file is located in the $ORACLE_HOME/webcache directory on UNIX and ORACLE_HOME\webcache directory on Windows.
4. Use a text editor to open the internal.xml file.
5. Locate the CALYPSOINTERNALPARAMS element.
...
...
6. Add the LOADBALANCE subelement directly after the OEMPERFTOOL subelement as follows:
...
...
7. Save internal.xml.
8. Restart OracleAS Web Cache with the following command:
opmnctl restartproc ias-component=WebCache
9. Verify OracleAS Web Cache is running in the load balancer mode from the OracleAS Web Cache Manager by verifying the following status message displays beneath the Apply Changes and Cancel Changes buttons:
Web Cache running in Load Balancer Mode with current configuration
Application Server Control Console does not provide an equivalent verification status.
10. Ensure the auto-restart mechanism is enabled, as described in "Task 3: Configure Auto-Restart Settings".
11. Configure origin servers, as described in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings".
12. Create site definitions and map them to the origin servers, as described in "Task 10: Configure Web Site Settings".
13. If your application deployment requires session stickiness, enable session binding. See "Bind a Session to an Origin Server".
Applications using OracleAS Single Sign-On and Oracle Delegated Administration Services, for example, require session binding.
If the application that requires session stickiness is an OC4J application, then configure session binding using the JSESSIONID cookie.
Consider the topology depicted in Figure 8-5.
Figure 8-5 Deploying OracleAS Web Cache as a Load Balancer
Description of "Figure 8-5 Deploying OracleAS Web Cache as a Load Balancer"
To configure this topology:
1. Register the IP address of the OracleAS Web Cache server webche-host with www.app1.company.com.
2. Configure the OracleAS Web Cache server with the following:
a. Receive HTTP and HTTPS requests on designated listening ports.
b. Send HTTP and HTTPS requests to application Web servers app1-host1 and app1-host2 on designated listening ports.
c. Map virtual host site definition for www.app1.company.com mapped to app1-host1 and app1-host2.
Task 3: Configure Auto-Restart Settings
OracleAS Web Cache provides an auto-restart mechanism that checks that the cache server process is running and automatically restarts the cache server process if it is not running.
If auto-restart is enabled, the auto-restart mechanism restarts the cache server if it stops. By default, auto-restart is enabled.
Note:
If you installed OracleAS Web Cache as part of an Oracle Application Server installation, the auto-restart mechanism is run by Oracle Process Manager and Notification (OPMN) Server. If you installed OracleAS Web Cache from a kit that included only this product, the auto-restart mechanism is run by the OracleAS Web Cache monitor.
To change the auto-restart settings in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Auto-Restart.
See Also:
"Modifying Auto-Restart Settings" in Enterprise Manager Online Help for instructions
To specify the settings for auto-restart in OracleAS Web Cache Manager:
1. In the navigator frame, select Properties > Auto-Restart.
The Auto-Restart page appears.
2. To change the default settings, click Edit.
The Edit Auto-Restart dialog box is displayed.
3. If auto-restart is not enabled, in the Enabled field, select Yes.
4. You can specify that the auto-restart mechanism polls (pings) the OracleAS Web Cache cache server at specified intervals. It does this by sending requests to a specified URL. If it cannot connect to the cache server or if the cache server does not respond within a specified time, the auto-restart mechanism restarts the cache server process.
Note that the auto-restart mechanism will restart the cache server if it has failed, whether or not you enable pinging. However, if you enable pinging, the auto-restart mechanism will attempt to restart the cache if it receives network errors in response to its ping attempts.
If you do not want the auto-start mechanism to actively ping the cache server, disable pinging by selecting No in the Pinging Enabled field.
To enable pinging:
a. In the Pinging Enabled field, select Yes.
b. In the Failover Threshold field, enter the number of consecutive failed requests before the auto-restart mechanism considers the cache server to have failed. Only network errors, including timeout errors, are counted as failed requests.
The default is three failures.
For each failed request, OracleAS Web Cache increments the failure counter. When a request is successfully processed by the cache server, OracleAS Web Cache resets the failure counter.
When the failover threshold is met, the auto-restart mechanism starts the cache server.
Note:
The threshold applies only to network errors and timeouts. If the cache server process is not running, the auto-restart mechanism immediately restarts the cache server.
c. In the Ping URL field, enter the URL that the auto-restart mechanism will use to poll the cache server.
You must use a URL that is cacheable and is guaranteed to be stored in the cache. The default is /_oracle_http_server_webcache_static_.html, which is stored in the cache. If your environment uses a hardware load balancer with pinging capability, then configure the load balancer with this ping URL to ping each OracleAS Web Cache server on a periodic basis.
d. In the Ping Interval field, enter the time, in seconds, between attempts by the auto-restart mechanism to poll the cache server.
The default value is 15 seconds.
e. In the Ping Timeout field, enter the time, in seconds, that the auto-restart mechanism will wait for a response from the cache server.
The default value is 30 seconds.
5. Click Submit.
Task 9: Configure Origin Server, Load Balancing, and Failover Settings
Configure OracleAS Web Cache with the application Web servers or proxy servers to which it sends cache misses. Typically, OracleAS Web Cache uses application Web servers for internal sites and proxy servers for external sites outside a firewall.
By default, the listening port and host name of the Oracle HTTP Server are configured. When OracleAS Web Cache is installed, Oracle HTTP Server has a default listening HTTP port of 7778 during the first installation sequence.
OracleAS Web Cache only forwards requests to a configured origin server if the server is mapped to a Web site. If you are configuring load balancing for a site, then create one site-to-server mapping that maps all the applicable origin servers to the site.
See Also:
● "Stateless Load Balancing" for an overview of load balancing
● "Task 10: Configure Web Site Settings" for instructions on configuring site-to-server mappings
To configure OracleAS Web Cache with origin server information from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Origin Servers.
See Also:
"Configuring Origin Servers" in Enterprise Manager Online Help for instructions
To configure OracleAS Web Cache with origin server information from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Origin Servers.
The Origin Servers page appears.
2. Click Add in the Application Web Servers or Proxy Servers section.
The Add Application Web Server or Proxy Server dialog box appears.
3. In the Hostname field, enter the host name of the origin server.
4. In the Port field, enter the listening port from which the origin server will receive OracleAS Web Cache requests.
Note:
OracleAS Web Cache must listen on the same port as the application Web server being proxied. When configuring proxy servers, ensure there is a corresponding listening port for every port that will need to be proxied.
5. In the Routing field, select ENABLED to permit OracleAS Web Cache to route requests to the origin server or DISABLED to only serve requests from cache.
Oracle recommends selecting DISABLED if temporary maintenance of an origin server is needed.
OracleAS Web Cache tries to route a request matching a particular site to all origin servers mapped to that site. If all of the origin servers have a routing of DISABLED, OracleAS Web Cache serves a network error page to clients.
See Also:
"Configure Error Pages"
6. In the Capacity field, enter the maximum number of concurrent connections that the origin server can accept.
You determine this number by load testing the origin server until it runs out of CPU, responds slowly, or until a backend database reaches full capacity.
In a cache cluster, OracleAS Web Cache ensures that the total number of connections from all cluster members to the origin server does not exceed the capacity. Each cluster member is allowed a percentage of the maximum connections, using the following formula:
connections_from_each_cluster_member = capacity / number_of_cluster_members
7. In the Failover Threshold field, enter the number of allowed continuous read/write failures with an origin server on established connections.
The default is five request/response failures.
If any connection failure occurs, OracleAS Web Cache immediately considers an origin server down.
When the threshold is met, OracleAS Web Cache considers the origin server down and performs automatic failover of the origin servers. If an origin server fails at any time after OracleAS Web Cache has started to send a request, then OracleAS Web Cache increments the failure counter. The failure counter is reset in the event of a successful server response. A request is considered failed if:
● There are any network errors other than connection failure errors.
● The HTTP response status code is less than 100, or is one of the following messages: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout.
After the threshold is met, OracleAS Web Cache considers the server down and uses other servers for future requests. OracleAS Web Cache starts polling the down server, by sending requests to the URL specified in the Ping URL field. When OracleAS Web Cache receives a successful response from the server without any network errors and the HTTP response code is not less than 100, or not equal to 500, 502, 503, 504, OracleAS Web Cache considers the server up again and uses it for future requests.
Note:
● The threshold does not apply if OracleAS Web Cache cannot connect to an origin server. In this case, OracleAS Web Cache immediately considers the server down and does not use it for future requests. If there are other origin servers, OracleAS Web Cache retries the request to another origin server. If there no servers configured, OracleAS Web Cache returns an error.
● The failover to another origin server does not apply if there is only one origin server left.
8. In the Ping URL field, enter the URL that OracleAS Web Cache will use to poll an origin server that has reached its failover threshold:
● For an application Web Server, enter either a relative or a fully-qualified URL that includes the domain name, or site name, representing the virtual host of the application Web server.
● For a proxy server, enter a fully-qualified URL that includes the domain name, or site name, representing the virtual host of the origin server behind the proxy server.
Rather than using a static URL, Oracle recommends using a URL that checks the health of the application logic on the origin server and returns the appropriate HTTP 200 or 500 status codes. The default is "/".
9. In the Ping Interval (seconds) field, enter the time, in seconds, that OracleAS Web Cache will poll an origin server that has reached its failover threshold.
The default is 10 seconds.
10. From the Protocol list, select either HTTP to send HTTP requests on the port or HTTPS to send HTTPS requests on the port.
See Also:
"Secure Sockets Layer (SSL)"
11. Click Submit.
12. If you selected HTTPS as the listening protocol, specify the location of the wallet for OracleAS Web Cache communication to the origin server (Origin Servers, Sites, and Load Balancing > Origin Server Wallet).
See Also:
"Task 4: Configure HTTPS Port and Wallet Location for the Origin Server" for information about configuring the wallet
Task 10: Configure Web Site Settings
For OracleAS Web Cache to act as a virtual server for one or more Web sites, configure OracleAS Web Cache with information about the Web site. To configure settings for a Web site, perform the following tasks:
● Creating Site Definitions
● Configure Error Pages
● Bind a Session to an Origin Server
Creating Site Definitions
The installation process creates a default site definition that uses the host name and listening port of the computer on which Oracle HTTP Server was installed. OracleAS Web Cache forwards requests without host information to this site.
You need to create site definition for any named sites. A site definition consists of a host name, port information, and optional URL path prefix about the site and its aliases. Alias information is essential, because many sites are represented by one or more aliases. OracleAS Web Cache recognizes and caches requests for a site and its aliases. For example, site www.company.com:80 may have an alias of company.com:80. By specifying this alias, OracleAS Web Cache caches the same content from either company.com:80 or www.company.com:80. If a request includes a site alias that is not configured, OracleAS Web Cache sends the request to the default site.
The following sections show examples of site definitions and explain how to configure new site definitions:
● Default Site Example
● Virtual Host Site Examples
● ESI Provider Site Example
● Creating New Site Definitions
Default Site Example
For those requests that do not include a Host request-header field, OracleAS Web Cache sends the request to the default site. The default site, established during installation, uses the host name and listening port of the computer on which Oracle HTTP Server was installed. Figure 8-1 shows an example of a default site definition from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The rules for the default site are as follows:
● The site definition in the Named Sites Definitions section maps HTTP requests to the origin server host-server:7778. If you select to edit this definition, you can view the ESI content policy from the Advanced tab. The ESI content policy is set to Unrestricted, which instructs OracleAS Web Cache to serve site content, as well as assemble ESI include fragments.
● The first mapping *.80 in the Server Mapping for Unnamed Site uses a * wildcard host name to map all other virtual site names to the origin server. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first rule.
● The second mapping *.* in the Server Mapping for Unnamed Site uses a * wildcard host name to map all other virtual site names to the origin server and a * wildcard port number to map the site name to multiple port numbers. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first two rules.
Figure 8-1 Default Site Definitions
Description of "Figure 8-1 Default Site Definitions"
Note:
If you modify the name of the default site, you must also modify the ServerName directive in the httpd.conf file. See "Task 7: Provide Directives to Oracle HTTP Server".
Virtual Host Site Examples
Figure 8-2 shows how you would configure a virtual host site named www.company.com:80 without ESI content from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The site definition in the Named Sites Definitions section maps HTTP requests to site www.company.com:80 and and site alias company.com:80 to origin server host-server:7778. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from host-server:7778 for this site.
Figure 8-2 Example: Site Settings for a Virtual Host Site
Description of "Figure 8-2 Example: Site Settings for a Virtual Host Site"
Figure 8-3 shows how you would configure a virtual host site named www.1st.company.com:80 and www.2nd.company.com with ESI content from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The rules are as follows:
● The site definitions in the Named Sites Definitions section map HTTP requests to sites www.1st.company.com:80 and www.2nd.company.com:80 and respective aliases 1st.company.com and 2nd.company.com to origin server host-server:7778. The ESI content policy is set to Unrestricted, which enables OracleAS Web Cache to serve site content, as well as assemble ESI include fragments.
● The mapping www.*.company.com:80 in the Server Mapping for Unnamed Site uses a * wildcard host name to map sites matching www.*.company.com to origin server host-server:7778. The ESI content policy is set to Unrestricted.
Figure 8-3 Example: Site Settings for Multiple Virtual Host Sites
Description of "Figure 8-3 Example: Site Settings for Multiple Virtual Host Sites"
ESI Provider Site Example
Figure 8-4 shows how you would configure ESI provider sites named www.providersite1.com:80 and www.providersite2.com from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The site definitions in the Named Sites Definitions section specify how to map HTTP requests to sites www.providersite1.com:80 and www.providersite2.com:80 and respective aliases providersite1.com and providersite2.com. Requests to www.providersite1.com map to proxy-host:80. There is no origin server specified for www.providersite2.com, because the proxy server is not known. Instead, DNS will be used to resolve the site name to the appropriate server. The ESI content policy is set to Fragments Only, which restricts OracleAS Web Cache from using this mapping for any content that is not ESI.
Figure 8-4 Example: Site Settings for Multiple ESI Provider Sites
Description of "Figure 8-4 Example: Site Settings for Multiple ESI Provider Sites"
Creating New Site Definitions
If the default site definition is not adequate for your configuration, create additional site definitions.
To create new site definitions from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Site Properties for a Named Site" or "Configuring Site Properties for an Unnamed Site" in Enterprise Manager Online Help for instructions
Using OracleAS Web Cache Manager, you can either discover site and alias information from Oracle HTTP Server, or you can manually create definitions. Oracle recommends using the site discovery feature to initially create the necessary definitions. After discovery is complete, you can manually create additional site definitions. Application Server Control Console does not support site discovery.
See Also:
Help for the Site Definitions page in OracleAS Web Cache Manager Online Help for instructions on using the site discovery feature
To create new site definitions from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site Definitions.
The Site Definitions page appears.
Note:
● It may not be possible to specify a site definition for an external ESI provider site. If an ESI request is made to a provider that does not match any application Web server mapping, then OracleAS Web Cache uses Domain Name System (DNS) to resolve the site name. Note that this will not work if there is a firewall between the cache and the ESI provider. In that case, you must provide a proxy server mapping that directs the request to the appropriate proxy.
● Undefined ESI provider sites disable the following OracleAS Web Cache features:
— Performance assurance heuristics
— Origin server features, such as surge protection, load balancing, failover, and session binding
● It is not possible to configure only ESI provider sites. In a configuration with ESI provider sites, at least one virtual host site definition must exist for ESI template pages.
2. Specify the site information:
a. In the Site Definitions page, click Add Site.
The Add Site dialog box appears.
b. In the Host Name field, enter the site host name, for example, www.company.com. To enable OracleAS Web Cache to match requests to this site, do not add protocol information (http:// or https://) to the host name.
Note:
Do not use the wildcard * in the Host Name field to represent multiple sites.
c. Optionally, in the URL Path Prefix field, enter the path prefix of the URLs to distinguish this site from another site that shares the same host name. Ensure the prefix starts with "/" to distinguish from another site that shares the same host name. Do not include the file name or embedded URL parameters in the prefix.
The prefix is excluded in matching requests to the site.
For example, the following URLs share the same site name, but belong to two entirely differently applications hosted on entirely different origin servers:
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
While the first URL shows an email user a front page after login, the second URL displays an inbox. If the site host name is defined as www.company.com, then you specify the prefixes as /portal and /um to distinguish the sites. Requests are matched for www.company.com, not www.company.com/portal and www.company.com/um.
d. In the Port Number field, enter the port number from which the Web site is listening for incoming HTTP requests.
The port number should be the port used in client requests.
In a configuration in which the OracleAS Web Cache listen port is the same as the logical site port, changing the OracleAS Web Cache listen port requires you to also change the logical site port in both the Site Definitions and Site-to-Server Mapping pages.
e. In the HTTPS Only Prefix field, enter the URL prefix for which only HTTPS requests will be served. If you must restrict all traffic to HTTPS, enter "/ " for the entire site.
f. In the URL Parameter to Ignore field, specify site-specific embedded URL or POST body parameters to ignore.
By configuring OracleAS Web Cache to ignore the value of embedded URL or POST body parameters, you enable OracleAS Web Cache to serve one cached object to multiple sessions requesting the same page. OracleAS Web Cache caches the response to the first request and serves subsequent requests for the page from its cache.
If you prefer instead to set a global parameter to apply to all sites, click Global URL Parameters to Ignore from the main Site Definitions page.
See Also:
● Excluding the Value of Embedded URL or POST Body Parameters for an overview and an example scenario
● Configuring OracleAS Web Cache to Exclude the Value of Embedded URL or POST Body Parameters for instructions on setting global parameters
g. In the Client-Side Certificate field, select Required or Not Required to specify that OracleAS Web Cache require or not require client-side certificates from client browsers.
A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user's public key and must be digitally signed by a trusted CA.
h. In the Default Site field, select Yes to specify the site as the default site, or select No to specify this site as a nondefault site.
If you select Yes for a site, another site that previously had the Yes setting will change to No.
If the default site includes a URL path prefix, the prefix is excluded in matching requests to the site. For example, if you specify a default site of www.company.com and a URL path prefix of /portal, requests are matched for www.company.com, not www.company.com/portal.
See Also:
"Default Site Example" for information about how the default site is used
i. In the Create Alias from Site Name with/without www field, select either Yes or No.
● Select Yes to use the site name as a site alias.
For example, if the site domain name is company.com, a site alias of www.company.com will be used. If the site domain name is www.company.com, a site alias of company.com will be used.
● Select No if you do not want to use the site name as a site alias.
3. If the site uses additional aliases, map the site to those aliases.
Important:
To ensure requests are directed to the correct site, specify all possible variations of the site name. If a request includes a site alias that is not configured, OracleAS Web Cache sends the request to the default site.
a. In the Site Definitions page, select a site, and then click Add Alias.
The Add Alias for Site dialog box appears.
b. In the Host Name field, enter the site alias name, such as company.com.
Note:
Do not use the wildcard * in the Host Name field to represent multiple aliases.
c. In the Port Number field, enter the HTTP or HTTPS port number from which the alias is listening for incoming HTTP requests.
The port number should be the port used in client requests.
4. Click Submit.
To map sites to origin servers from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Site Properties for a Named Site" in Enterprise Manager Online Help for instructions
To map sites to origin servers from OracleAS Web Cache Manager, take the following steps:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping.
The Site-to-Server Mapping page appears.
2. Click Create if no mappings exist. If mappings already exist, select a mapping, and then click Insert Above or Insert Below.
The Create Site-to-Server Mapping or Edit/Add Site-to-Server Mapping dialog box appears.
3. In the Edit Site Name section, select one of the following options:
● Enter Site Name to enter the site name, such as www.company.com or *.company.com, as well as the HTTP or HTTPS port number from which the site is listening for incoming requests.
● Select from Site definitions to select a site definition created in the Site Definitions page.
Note:
You can use the wildcard * in the Host Name field in the following ways:
● Map multiple site names to one or more application Web server or proxy servers. For example, *.company.com can be used to match sites site1.company.com and site2.company.com.
● Route cache misses to undefined ESI provider sites outside a firewall and accessible by a proxy server. For example, * can be used to map to proxy server proxy-host.
You can use the wildcard * in the Port Number field to map the same site name with different port numbers to the same origin servers. If the origin servers are proxy servers, ensure they were configured to listen on the same port as the application Web server being proxied, as described in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings".
This option does not enable you to create a site definition. You must create a site definition in the Site Definitions page.
4. In the Select either application Web servers or proxy servers to which this Site is mapped, select one of the following options:
● Select Application Web Servers to select application Web servers specified in the Origin Servers page
● Select Proxy Servers to select proxy servers specified in the Origin Servers page
Note:
If you configured multiple origin servers in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings" for load balancing, then create one site-to-server mapping that maps all the applicable origin servers to the site. In that site-to-server mapping, select all the origin servers that apply for the site. If you split the origin servers among multiple site-to-server mappings, load balancing for the site will not occur in the intended manner.
5. In the Exclude section, select one of the following options to restrict OracleAS Web Cache access to the origin servers for the sites specified in Edit Site Name.
● Exclude Fragments restricts OracleAS Web Cache from using this mapping for ESI fragments. Select this option if the site is a virtual host site that does not provide ESI content.
● Fragments Only restricts OracleAS Web Cache from using this mapping for any content that is not an ESI fragment. Select this option if the site is an ESI provider site.
● Unrestricted does not enforce any OracleAS Web Cache restrictions. Select this option if the site is a virtual host site that supports ESI.
For example, one mapping entry that uses Exclude Fragments does not mean that OracleAS Web Cache is not allowed to assemble ESI content from other origin servers.
6. Click Submit.
7. After you create the mappings, order them. For each request, the first matching mapping is used.
In the Site-to-Server Mapping page, select a mapping, and then click Move Up or Move Down to order the mappings. Note the following:
● Because mappings that use the wildcard * encompass a broader scope, give these mappings a lower priority than other mappings.
● Because requests are resolved to the first matching mapping, give mappings that contain the optional URL path prefix a higher priority than those mappings without an URL path prefix.
For example, you should order the following mappings as follows:
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
http://www.company.com
If you instead reorder the mappings as follows, the request for URLs http://www.company.com/portal/page?_pageid=33,4232&_dad=portal and http://www.company.com/um/traffic_cop?mailid=inbox will never be reached. Requests for these URLs will instead resolve to http://www.company.com because it is listed first:
http://www.company.com
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
Note:
If the protocol used in the src attribute of an
ESI include fragment protocol does not match origin server protocol: Origin Server Protocol=protocol URL=URL
For example, if the template page is configured with
[25/Jul/2005:19:30:48 +0000] [warning 11250] [ecid: -] ESI include fragment protocol does not match origin server protocol: Origin Server Protocol=http URL=https://www.company.com/gifs/frag1.gif
Configure Error Pages
For configured sites, specify error pages to be served from OracleAS Web Cache for network communication errors, site busy errors, and ESI
1. Create error pages and place them in the $ORACLE_HOME/webcache/files directory on UNIX and the ORACLE_HOME\webcache\files directory on Windows. The default settings are as follows:
● For network errors, the default setting is set to network_error.html. This error page is served when there is a network problem while connecting, sending, or receiving a response from an origin server for a cache-miss request.
● For site busy errors, the default setting is set to busy_error.html. This page is served when origin server capacity is reached.
● For ESI default fragments, the default setting is set to esi_fragment_error.txt. This page is served when OracleAS Web Cache is unable to fetch the src specified in an
See Also:
"Exceptions and Errors"
For a production environment, modify the defaults or create entirely new error pages to be consistent with other error pages for the site.
2. Configure OracleAS Web Cache with the error pages.
You can modify the settings for error pages in one of two ways:
● Change the default settings, and apply it to all defined sites.
● Modify the error page settings for a specific site.
From Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Default Error Pages" in Enterprise Manager Online Help for instructions on configuring error pages
From OracleAS Web Cache Manager, perform these steps to configure error pages:
● In the navigator frame, select Origin Servers, Sites, and Load Balancing > Error Pages.
The Error Pages page appears.
● Select either Default Pages or a site name in the table, and then click Edit.
The Edit Error Pages dialog box appears.
● In the Network Error Page field, enter the file name of the error page that will be delivered for network communication problems between OracleAS Web Cache and the Web site.
If you are using the default network_error.html page, leave the field as is.
● In the Site Busy Page field, enter the file name of the error page that will be delivered when a Web site is saturated with requests.
If you are using the default busy_error.html page, leave the field as is.
● In the ESI Default Fragment field, enter the file name of the page that will be delivered when OracleAS Web Cache is unable to retrieve an HTML fragment for an
If you are not using
● Click Submit.
If you selected Default Pages in Step b, the new settings will be applied to all defined sites with the default page setting. However, the new setting will not be applied to undefined sites. If you selected a specific site in Step b, the new settings will be applied to just to the site.
See Also:
"Exceptions and Errors" to understand how exceptions and error are handled for
Bind a Session to an Origin Server
Notes:
● When a session cookie expires, OracleAS Web Cache does not continue to bind the user session to the origin server. Instead, OracleAS Web Cache uses load balancing to choose an origin server. To avoid pages being served past the client session expiration time, ensure that the session cookie expires before the origin server expires the client session.
● If an origin server is busy, OracleAS Web Cache disables session binding to that origin server.
You can configure OracleAS Web Cache to support session binding, whereby a user session for a particular site is bound to an origin server in order to maintain state for a period of time. To utilize this feature, the origin server itself must maintain state; that is, it must be stateful.
If a request is forwarded to an origin server for an object requiring session binding, the origin server creates the user session by including the session information to clients through OracleAS Web Cache in the form of a session cookie or an embedded URL parameter. OracleAS Web Cache does not process the value of the parameter or cookie; it simply passes the information back to the client browser. When a client includes the session information in a subsequent request, OracleAS Web Cache forwards the request to the origin server that originally created the user session. OracleAS Web Cache binds the user session to that particular origin server.
If you have configured a cache cluster, you must enable tracking of session bindings through the use of a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.
See Also::
● "Session Binding(Stateful Load Balancing)" for an overview of origin server binding
● "Task 3: Enable Tracking of Session Binding" for instructions on enabling session tracking in a cluster
By default, session binding is not enabled for any sites. If there is no session binding specified for a site, then the default session binding setting is applied, which uses the Default Session Binding rule. The Default Session Binding rule has a default value of Disable Session Binding. You can enable session binding in one of two ways:
● Change the default value of the Default Session Binding rule from Disable Session Binding to a specific session and binding mechanism. OracleAS Web Cache applies these settings to all sites that use the Default Session Binding rule. If you decide to change the value of the Default Session Binding rule, ensure all named sites currently configured with this rule require session binding. If some sites do not require session binding, leave the value of Disable Session Binding, and instead specify session binding settings for the site. Use the next option.
● Overwrite the default session binding setting to some other session for a specific site.
To enable session binding in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Session Binding Settings" in Enterprise Manager Online Help for instructions
To enable session binding from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Session Binding.
The Session Binding page appears.
2. In the Session Binding page, select Default Session Binding or a specific site name in the table, and then click Edit Selected.
The Edit Session Binding dialog box appears.
3. From the Please select a session list:
● If you selected the Default Session Binding rule in Step 2, change the session value from Use Default Session Binding to another defined session, and then skip to Step 4.
● If you selected a specific site in Step 2, change the session value from Disable Session Binding to a defined session, and then skip to Step 3. Table 8-1 provides descriptions of the default session definitions provided at installation time.
If you want OracleAS Web Cache to bind user sessions with multiple cookies when any cookie is set, select a session of Any Set Cookie. When selecting Any Set Cookie, in Please select a session binding mechanism, select Cookie-Based to instruct OracleAS Web Cache to include a Set-Cookie response-header in the response.
If the sessions listed do not contain the definition you require, click Cancel to exit the Edit Session Binding dialog box. Continue to Step 4.
4. Create a session definition:
● In the navigator frame, select Rules for Caching, Personalization, and Compression > Session Definitions.
The Session Definitions page appears.
● From the For Site list, select the Web site for which you want to create site-specific site definitions.
● Click Add or Create.
The Edit/Add Session Definition dialog box appears.
● In the Session Name field, enter an easy-to-remember unique name.
● Enter the cookie name in the Cookie Name field and the embedded URL parameter in the URL or Post body parameter field.
If you enter both a cookie name and an embedded URL parameter, keep in mind that both must be used to support the same session. If they support different sessions, create separate session definitions. You can specify up to 20 session definitions for each page.
Note:
OracleAS Web Cache requires a session cookie to perform session binding. If client browsers do not support cookies and you want to use an embedded URL parameter for the session, then perform the following for OracleAS Web Cache to perform session binding on the session:
1. In addition to the URL Parameter field, specify a cookie name for the session in the Cookie Name field.
2. Ensure that the origin server returns a Set-Cookie response-header with the value of the session every time a session is created.
Set-Cookie: cookie=value
Set value to the same value as set in the URL Parameter field.
OracleAS Web Cache uses the Set-Cookie response header, even if ignored by browsers, to locate the session cookie value for session binding.
See Also: http://www.rfc-editor.org/ for further information about the Set-Cookie response header
● Click Submit.
● Repeat Steps 1 through 3.
5. From the Please select a session binding mechanism list, select one of the following mechanisms:
● Cookie-based: Select if the client supports cookies. OracleAS Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between OracleAS Web Cache and the client browser.
● OC4J-based: Select if the application is based on OC4J. OracleAS Web Cache forwards routing information with each request to OC4J through Oracle HTTP Server.
● Internal-tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and OC4J. This option is intended for backward compatibility with earlier releases of OracleAS Web Cache. OracleAS Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must bind at the load balancer layer.
6. Click Submit.
If you selected the Default Session Binding rule in Step 2, the new settings will be applied to all defined sites with the default session binding setting. However, the new default will not be applied to undefined sites. If you selected a specific site in Step 2, the new settings will be applied to just the site.
Bind a Session to an Origin Server
Notes:
● When a session cookie expires, OracleAS Web Cache does not continue to bind the user session to the origin server. Instead, OracleAS Web Cache uses load balancing to choose an origin server. To avoid pages being served past the client session expiration time, ensure that the session cookie expires before the origin server expires the client session.
● If an origin server is busy, OracleAS Web Cache disables session binding to that origin server.
You can configure OracleAS Web Cache to support session binding, whereby a user session for a particular site is bound to an origin server in order to maintain state for a period of time. To utilize this feature, the origin server itself must maintain state; that is, it must be stateful.
If a request is forwarded to an origin server for an object requiring session binding, the origin server creates the user session by including the session information to clients through OracleAS Web Cache in the form of a session cookie or an embedded URL parameter. OracleAS Web Cache does not process the value of the parameter or cookie; it simply passes the information back to the client browser. When a client includes the session information in a subsequent request, OracleAS Web Cache forwards the request to the origin server that originally created the user session. OracleAS Web Cache binds the user session to that particular origin server.
If you have configured a cache cluster, you must enable tracking of session bindings through the use of a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.
See Also::
● "Session Binding(Stateful Load Balancing)" for an overview of origin server binding
● "Task 3: Enable Tracking of Session Binding" for instructions on enabling session tracking in a cluster
By default, session binding is not enabled for any sites. If there is no session binding specified for a site, then the default session binding setting is applied, which uses the Default Session Binding rule. The Default Session Binding rule has a default value of Disable Session Binding. You can enable session binding in one of two ways:
● Change the default value of the Default Session Binding rule from Disable Session Binding to a specific session and binding mechanism. OracleAS Web Cache applies these settings to all sites that use the Default Session Binding rule. If you decide to change the value of the Default Session Binding rule, ensure all named sites currently configured with this rule require session binding. If some sites do not require session binding, leave the value of Disable Session Binding, and instead specify session binding settings for the site. Use the next option.
● Overwrite the default session binding setting to some other session for a specific site.
To enable session binding in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Session Binding Settings" in Enterprise Manager Online Help for instructions
To enable session binding from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Session Binding.
The Session Binding page appears.
2. In the Session Binding page, select Default Session Binding or a specific site name in the table, and then click Edit Selected.
The Edit Session Binding dialog box appears.
3. From the Please select a session list:
● If you selected the Default Session Binding rule in Step 2, change the session value from Use Default Session Binding to another defined session, and then skip to Step 4.
● If you selected a specific site in Step 2, change the session value from Disable Session Binding to a defined session, and then skip to Step 3. Table 8-1 provides descriptions of the default session definitions provided at installation time.
If you want OracleAS Web Cache to bind user sessions with multiple cookies when any cookie is set, select a session of Any Set Cookie. When selecting Any Set Cookie, in Please select a session binding mechanism, select Cookie-Based to instruct OracleAS Web Cache to include a Set-Cookie response-header in the response.
If the sessions listed do not contain the definition you require, click Cancel to exit the Edit Session Binding dialog box. Continue to Step 4.
4. Create a session definition:
● In the navigator frame, select Rules for Caching, Personalization, and Compression > Session Definitions.
The Session Definitions page appears.
● From the For Site list, select the Web site for which you want to create site-specific site definitions.
● Click Add or Create.
The Edit/Add Session Definition dialog box appears.
● In the Session Name field, enter an easy-to-remember unique name.
● Enter the cookie name in the Cookie Name field and the embedded URL parameter in the URL or Post body parameter field.
If you enter both a cookie name and an embedded URL parameter, keep in mind that both must be used to support the same session. If they support different sessions, create separate session definitions. You can specify up to 20 session definitions for each page.
Note:
OracleAS Web Cache requires a session cookie to perform session binding. If client browsers do not support cookies and you want to use an embedded URL parameter for the session, then perform the following for OracleAS Web Cache to perform session binding on the session:
1. In addition to the URL Parameter field, specify a cookie name for the session in the Cookie Name field.
2. Ensure that the origin server returns a Set-Cookie response-header with the value of the session every time a session is created.
Set-Cookie: cookie=value
Set value to the same value as set in the URL Parameter field.
OracleAS Web Cache uses the Set-Cookie response header, even if ignored by browsers, to locate the session cookie value for session binding.
See Also: http://www.rfc-editor.org/ for further information about the Set-Cookie response header
● Click Submit.
● Repeat Steps 1 through 3.
5. From the Please select a session binding mechanism list, select one of the following mechanisms:
● Cookie-based: Select if the client supports cookies. OracleAS Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between OracleAS Web Cache and the client browser.
● OC4J-based: Select if the application is based on OC4J. OracleAS Web Cache forwards routing information with each request to OC4J through Oracle HTTP Server.
● Internal-tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and OC4J. This option is intended for backward compatibility with earlier releases of OracleAS Web Cache. OracleAS Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must bind at the load balancer layer.
6. Click Submit.
If you selected the Default Session Binding rule in Step 2, the new settings will be applied to all defined sites with the default session binding setting. However, the new default will not be applied to undefined sites. If you selected a specific site in Step 2, the new settings will be applied to just the site.
http://www.scribd.com/doc/54944312/8/Configure-OracleAS-Web-Cache-to-Act-Solely-as-a-Software-Load-Balancer
Subscribe to:
Posts (Atom)