EnterpriseRequestProxyCommand (OpenEAI API beta 3.0)

Overview

Package

Class

Use

Tree

Deprecated

Index

Help

PREV CLASS NEXT CLASS

FRAMES NO FRAMES

SUMMARY: NESTED | FIELD | CONSTR | METHOD

DETAIL: FIELD | CONSTR | METHOD

org.openeai.implementations.gateways.requestproxy
Class EnterpriseRequestProxyCommand


java.lang.Object

  |

  +--org.openeai.OpenEaiObject

        |

        +--org.openeai.jms.consumer.commands.ConsumerCommand

              |

              +--org.openeai.jms.consumer.commands.RequestCommandImpl

                    |

                    +--org.openeai.implementations.gateways.requestproxy.EnterpriseRequestProxyCommand

All Implemented Interfaces:: RequestCommand

public class EnterpriseRequestProxyCommand
extends RequestCommandImpl
implements RequestCommand

OpenEAI Reference Implementation Enterprise Request Proxy.

The purpose of this command is to verify that an untrusted application making a request of an authoritative source is authorized to do so. The gateway associated to this command sits between an untrusted requesting application and an authoritative source. The requesting application is only permitted to send requests to a Queue monitored by the request proxy. Requests delivered to that Queue are consumed by the EnterpriseRequestProxy. If this command determines that the requesting application is authorized to perform the request it will forward the request to the intended target on behalf of the requesting application, consume the response and return it to the requesting application. Technically speaking, only the request proxy has authority to connect to the Queues monitored by authoritative systems. The only other applications that should be allowed to connect directly to those Queues are other "trusted" applications. Deciding whether or not an application is trusted, is a case by case decision. If the requesting application is not authorized to make the request, an error will be returned indicating this.

Authorization to perform a request can be determined in a number of ways. For this implementation, there are two potential layers to this determination. The first layer is based soley on the messageObject, messageRelease and messageAction associated to the request. The configuration of this command will provide the information needed to make this determination (MessageObjectConfigs associated to a requesting application). The second layer can be much more complex and is based on any number of other factors including the content of the message or other ancillary information that may be retrieved from other sources. Of these two layers, the first is always used. The second layer need only be used if appropriate and is driven by configuration properties specified in the configuration associated to this command.

One difference between the deployment of this gateway and most others is that a single instance of the RequestProxy will generally have PointToPoinConsumers connecting to a destination specific to each application that may be making a request. This is because each untrusted application is only given access to one destination based on the way this RequestProxy implementation is designed. This makes the configuration of the gateway simpler because you can separate each requesting application into its own set of configuration information. Additionally, it makes the broker environment more clear and easier to restrict access.

These are the configuration parameters associated to this command. These are specified the Command's Configuration element in the deployment document associated to the gateway.

Property Name Required Description

MessagingComponents yes This is a container Element that provides a mechanism for specifying which Applications will be making requests. It simply contains one or more Application Elements which are used by this command to establish AppConfig objects associated to each requesting application. The AppConfig objects that get established will contain all the resources needed to proxy the messages from the requesting applications appropriately.

Application yes This Element is used to specify the name of the requesting application that will be making requests. It is also a container for the Configuration Element which is implemented by the AppConfig Java object and contains all initialized resources required to proxy the messages from the requesting applications. The "id" attribute is used to specify the name of the requesting application. The MessageObjects used by the requesting application must be configured appropriately to use the same application name or they will never be allowed to send any requests. The Description element is used to provide a description of the requesting application. There should be a Application Element specified for each requesting application that should be proxied.

Configuration yes This Element is implmemented by the AppConfig java object. This is the same configuration Element used by all other messaging components that use an AppConfig. This will contain the resources required to proxy requests. Those resources include:

ProducerConfigs - PointToPointProducers that are connected to authoritative source destinations (Queues). These producers will be used to forward the request on behalf of the requesting application. At least one producer should be specified here for each authoritative source that requests may be forwarded to.
Additional producers could be specified here if needed. Additional producers could be needed by the ProxyCommand implemenation that gets executed to perform "content based" proxying. If needed, they would be specified and configured here.
MessageObjectConfigs - This would be a list of all Message Objects that the requesting application is allowed to message about. The proxy will retrieve the messageObject (e.g. - BasicPerson, BasicEmployee etc.) and messageRelease (e.g. - 1.0, 1.1 etc.) from the message consumed by the gateway and use that information to build a message object name that looks like this "BasicPerson.v1_0". If the end point's configuration contains a message object by that name, the proxy may forward the request if the requesting application is authorized to perform the action they've specified. To determine this, the command retrieves the messageAction attribute from the ControlAreaRequest and see if the MessageObject has a "primed" document associated to it. This is specified in the MessageObjectConfig element for the message objects that the requesting application can message about. If the primed document does not exist that corresponds to the action being requesting, permission to perform the request will be denied. If the MessageObject exists and a "primed" document has been associated to it that matches the messageAction being requested, the first layer of authorization has passed. If there are no ProxyCommand implementations associated to the application, the request will be forwarded by this command on behalf of the application making the request. If there are ProxyCommands associated to the requesting application for this message object, they will be executed according to the PropertyConfig object listed next.
PropertyConfigs - These are a set of properties associated to the requesting application. There must be one PropertyConfig object named 'ProxyCommandProperties' that this command uses to determine which resources to use to forward the request as well as make decisions about if it should forward the request. There may be additional PropertyConfigs specified if needed. The Properties that may exist in the 'ProxyCommandProperties' PropertyConfig element are:

Property Name Required Description

[messageObjectName].producerName yes The "producerName" property is used to map a incomming message object to an authoritative source. The value associated to this property should match the name of one of the producers listed above in the ProducerConfigs section. This gives you the flexibility to specify different authoritative sources for different message objects. If one system is authoritative for say BasicPerson but an entirely different system is authoritative for BasicEmployee, there will need to be multiple producers that are connected to destiniations for each authoritative source. This mapping allows us to specify which producer should be used to forward the request when/if it's determined that the requesting application has authority to do so.
Naming conventions are used here to make this mapping. The convention is [messageObjectName].producerName. Where messageObjectName is the messageObject and messageRelease from the message consumed (e.g. - BasicPerson.v1_0) and producerName is the name of a producer configured in the ProducerConfigs Element above. Support has also been added to specify a "Default" producer to use instead of having to map every message object. If one requesting application will be making most of its requests to a single authoritative source, the "Default.producerName" property should be specified. If the proxy doesn't find a producer associated to the message object in the request, it will use this default producer.

[messageObjectName].proxyCommandName yes This is the name of the ProxyCommand implementation that should be executed to perform "content based" proxying. This is where specific message content is interigated or additional information may be retrieved from other sources if needed. The AppConfig associated to the requesting application as well as the Document XML Document created from the content of the JMS Message is passed to this method so the ProxyCommand implementation has all the resources it needs at its disposal.

Author:: Tod Jackson
See Also:: ProxyCommand, ProxyCommand.execute(AppConfig, Document), ProxyCommandImpl, AppConfig, LoggerConfig, ConsumerConfig, CommandConfig, ProducerConfig, MessageObjectConfig

Field Summary

Fields inherited from class org.openeai.jms.consumer.commands.ConsumerCommand

CREATE_ACTION, DELETE_ACTION, MESSAGE_ACTION, MESSAGE_CATEGORY, MESSAGE_OBJECT, MESSAGE_RELEASE, MESSAGE_TYPE, QUERY_ACTION, UPDATE_ACTION

Fields inherited from class org.openeai.OpenEaiObject

logger

Constructor Summary

EnterpriseRequestProxyCommand(CommandConfig cConfig)
Constructor

Method Summary

javax.jms.Message execute(int messageNumber, javax.jms.Message aMessage)
Method used to implement business logic specific to a message or set of messages consumed by a OpenEAI PointToPointConsumer.

Methods inherited from class org.openeai.jms.consumer.commands.RequestCommandImpl

buildReplyDocument, buildReplyDocumentWithErrors, buildReplyDocumentWithErrors, getMessage

Methods inherited from class org.openeai.jms.consumer.commands.ConsumerCommand

addAppConfig, buildError, convertToString, generateRelease, getAppConfig, getAppConfigs, getControlArea, getInboundXmlValidation, getMessageAction, getMessageBody, getMessageCategory, getMessageDumpDirectory, getMessageObject, getMessageRelease, getMessageType, getMsgComponents, getOutboundXmlValidation, initializeInput, setAppConfig, setInboundXmlValidation, setMessageDumpDirectory, setMsgComponents, setOutboundXmlValidation, setWriteToFile, writeMessageToFile, writeToFile

Methods inherited from class org.openeai.OpenEaiObject

addLog4jProperty, getAppName, getDebug, getFromAddr, getLog4jProperties, getMailHost, getMailService, getProperties, getToAddr, initializeLog4j, initializeLog4j, initializeLog4j, setAppName, setDebug, setFromAddr, setMailHost, setMailService, setProperties, setToAddr

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail