|
This section explains the main concepts in the Oracle Enterprise Gateway product architecture.
Policy
A policy is a network of message filters in which each filter is a modular unit that processes
a message. A message can traverse different paths through the network, depending on which filters
succeed or fail. For example, this enables you to configure policies that route messages that pass
a Schema Validation filter to a back-end system, and route messages that pass a
different Schema Validation filter to a different system.
Filter
A filter is an executable rule that performs a specific type of processing on a message. For
example, the Message Size filter rejects messages that are greater or less than
a specified size. There are many categories of message filters available with the Enterprise Gateway,
including authentication, authorization, content filtering, signing, and conversion. In the
Policy Studio, a filter is displayed as a block of business logic that forms part of an execution
flow known as a circuit.
Circuit
A circuit is a series of filters through which a message passes. A circuit can contain
other circuits, which enables you to build modular reusable policies. In the Policy Studio,
a circuit is displayed as a path through a set of filters. A filter can have only one
Success Path and one Failure Path. You can use these
success paths and failure paths to create sophisticated rules. For example, if the incoming
data matches schema A, scan for attachments, and route to service A, otherwise route to
service B. You can configure the colors used to display success paths and failure paths
in the Policy Studio Preferences menu. You can also specify to Show
Link Labels (S or F).
The following example screen shot shows an example circuit with success paths and a failure
path:
|
Example Authentication/Authorization Policy Circuit
|
A circuit must have a Start filter (in this example, Check against
threats). Filters labeled End stop the execution of the policy
if the filter execution fails. Filters labeled Start/End indicate that
the circuit execution starts there, and that the circuit stops executing if this filter fails.
A circuit with a single filter labeled Start/End is also valid.
Message Attributes
Each filter requires input data and produces output data. This data is stored in message attributes,
and you can access their values using syntax such as ${attribute.name}.
You can also use specific filters to create your own message attributes, and to set their values.
The full list of message attributes flowing through a policy is displayed when you right-click
the Policy Studio canvas, and select Show All Attributes. You can also hover your mouse
over a filter to see its inputs and outputs. The Trace filter enables you to
trace message attribute values at execution time.
The following example screen shot shows the attributes displayed when hovering over an HTTP
Basic authentication filter:
|
HTTP Basic Authentication Policy
|
If a filter requires an attribute as input that has not been generated in the previous execution steps,
the filter is displayed in a different color in the Policy Studio (default is red). You can configure
the color used to display missing attributes in the Policy Studio Preferences menu.
Alternatively, you can also view all required attributes by right-clicking the canvas, and selecting
Show All Attributes.
A missing attribute may indicate a problem that you need to investigate (for example, in the chaining
of filters or policies, or that the policy can not run on its own). This is often the case for reusable
filters, such as those displayed in the previous example.
At the policy level, you also can click the horizontal bar at the top of the Policy Studio canvas to show
the list of all attributes required as input to the entire policy. If any attributes are generated by the
policy, you can click a corresponding bar at the bottom to see a list of generated attributes. The
following example screen shot shows the attributes required by an Authenticate
policy:
|
HTTP Basic Authentication Attributes
|
Faults
When a SOAP transaction fails, you can use a SOAP fault to return error information to the SOAP
client. By default, the Enterprise Gateway returns a basic SOAP fault to the client when a message filter
fails. You can add a SOAP Fault filter to a policy to return more detailed error
information to the client. For example, the previous example screen shot shows an
AuthenticationFaultHandler, which is a policy shortcut to the following fault
handler policy:
|
Authentication Fault Handler
|
Policy Shortcut
A policy shortcut enables you to create a link from one policy to another policy. For example,
you could create a policy that inserts security tokens into a message, and another that adds
HTTP headers. You can then create a third policy that calls the other two policies using
Policy Shortcut filters.
A policy shortcut chain enables you to run a series of policies in sequence without needing to
create a policy containing policy shortcuts. In this way, you can create modular policies to perform
certain specific tasks, such as authentication, content filtering, returning faults, or logging,
and then link these policies together in a sequence using a policy shortcut chain. You can also use
Service Manager to automate the creation of a policy shortcut chain simply by dragging and dropping
existing policies into a composite policy.
Alerts
The Enterprise Gateway can send alert messages for specified events to various alerting destinations.
System alerts are usually sent when a filter fails, but they can also be used for notification
purposes. The Enterprise Gateway can send system alerts to the following destinations:
- Windows Event Log
- UNIX/Linux sylsog
- SNMP Network Management System
- Check Point Firewall-1
- Email recipient
You can configure alert destinations, and then add an Alert filter
to a policy, specifying the appropriate alert destination.
Policy Container
A policy container is used to group similar policies together (for example, all authentication
or logging policies), or policies that relate to a particular service. A number of useful policies
are provided in the Policy Library container (for example, policies that return faults,
and policies that block threatening content). You can add your own policies to this container,
and add your own policy containers to suit your requirements.
Policy Context
Policies can execute in a specified context. You can set a context by associating a relative execution
path or listener with a policy. When a policy is called from another policy, the context is set to the
calling policy name (for example, Authenticate). In the Policy Studio, you can select a
context from the drop-down list at the bottom of the canvas, and the Policy Studio displays whether the
attributes required for execution are available in that context.
Listeners
You can define different types of listeners and associate them with specific policies. For example,
listeners include the following types:
- HTTP/HTTPS
- Directory Scanner
- POP mail server connection
- JMS connection
- TIBCO RV/EMS connection
The Enterprise Gateway can be used to provide protocol mediation (for example, receiving a SOAP request over
JMS, and transforming it into a SOAP/HTTP request to a back-end service). For HTTP/HTTPS listeners,
policies are linked to a relative path. Otherwise, policies are linked to the listener itself.
You can associate a single policy with multiple listeners.
Remote Hosts
You can define a remote host when you need more control of the connection settings
to a particular Web Service server. The available connection settings include the following:
- HTTP version
- IP addresses
- Timeouts
- Buffers
- Caches
For example, by default, the Enterprise Gateway uses HTTP 1.1. You can force it to use HTTP 1.0 using
Remote Host settings. You must also define a Remote Host if you want to track real-time metrics
for a particular host.
Servlet Applications
The Enterprise Gateway provides a Web server and servlet application server that can be used to host static
content (for example, documentation for your project), or servlets providing internal services.
Static content or servlets can be accessed from a policy using the Call Internal Service
filter. This feature is not meant to replace an enterprise J2EE server, but rather
to enable you to write functionality using technology such as servlets.
Configuration Profile
A Configuration Profile contains the configuration information required to run the Enterprise Gateway. For
example, a specific Configuration Profile instance can store certificates, users, core policies and
Web Services, external connections, or listeners. A Configuration Profile can have a number of versions,
which are created by users. You can use the Policy Studio to deploy Configuration Profile versions to
Enterprise Gateway Processes, and to copy existing versions to create new Configuration Profiles.
Process
A Process is a running instance of the Enterprise Gateway. You can use Policy Studio to configure and deploy
Enterprise Gateway Processes.
Service Virtualization
When you register a Web Service, and deploy it to the Enterprise Gateway, the Enterprise Gateway virtualizes
the Web Service. Instead of connecting to the Web service directly, clients connect through
the Enterprise Gateway. The Enterprise Gateway can then apply policies to messages sent to the destination
Web Service (for example, to enable security, monitoring, and acceleration).
|