Index Changes

Note

Note that this page lists ideas for Aspects, most of these Aspects have not been realized (yet)

Project Fuji Aspect Interceptors Overview


Table of Contents

Tee Aspect Interceptor

Explicitly allows you to list the publish-subscribe relationship in your routing logic; this keeps the producer and consumer decoupled but lets you control the fine grained routing configuration. This allows you to route messages to a number of destinations. This aspect also allows you to route messages to a separate endpoint before it is forwarded to the ultimate destination.

Use-Cases

The Administrator wants to listen in on message exchanges to an endpoint in by adding a wire taps and redirect the message to different services.

Strategy

In some scenarios, you want to redirect the same message to two different components. The Tee Aspect Service Engine core introduces a T-junction that facilitates message redirection to two different components at the same time.

It acts very much like the tee command in Unix where, for example, you may want to save the output of a command in a file, while at the same time see the results on the terminal as it is being produced. Then if you see that the output is in error, you can stop the command.

The tee command in Unix acts like a T-junction. For e.g., the UNIX command

ls -al | tee folderdetails

shows all the details of the current folder on the terminal screen and also redirects the details to a file named folderdetails.

This pattern ensures that the Tee policy acts between the client and the service that is involved to service the operation. Therefore, if this aspect is configured, all messages flowing between the client and the service providers flow through the Tee engine core. The routing will happen based on a configurable Rule Set which can be configured from the Web Console.

Composite Apps requiring use of this pattern will have to employ the Filter One-Way exchange pattern.

Tee Management Configuration

  • Get/Set/Add s
  • Get/Set/Add/Edit s to

For example,

<?xml version="1.0" encoding="UTF-8"?>
<tee>
    <config />
    <ruleset name="mytee" >
        <rule name="myfirstrule">
            <xpath keyExpression="/Employee/FirstName"/>            
            <destination id="1" />
            <destination id="2" />
        </rule>
    </ruleset>
</tee>

Content-Based Routing Aspect Interceptor

Consume from an input destination, evaluate some predicate then route to the right output destination. This allows you to route messages to the correct destination based on the contents of the message exchanges.

Use-Cases

A scenario where based on the content of the message it has to be routed to different recipients is very common in integration scenarios. An enterprise that has multiple partners like Walmart, and a Mom-And-Pop shop. Walmart provides a huge discount for item X when the number of orders is above 10000, and Mom-And-Pop Shop provides a good price below 10000 items of item X. When the message comes in, based on the predicate to the number of items, and if the item is X, the rule may specify that the message needs to be routed to the Walmart partner endpoint, or to the Mom-And-Pop Shop endpoint. At a later point in time, Walmart can provide a better discount for orders over 5000. The system need not be redeployed. The rules can be changed on the fly through configuration exposed through a Web Console.

Strategy

The Content-Based Routing Aspect is used to forward a message to the correct destination based on the content of the message payload. For example, a typical scenario for this may be that on receipt of a purchase order, the message needs to be routed to the appropriate order management system, based on the type of item that has been ordered (which will be obtained by parsing an XPath expression in the message payload). The routing will happen based on a configurable Rule Set which can be configured from the Web Console.

This pattern ensures the Content-Based Routing policy acts between the client and the multiple services that are involved to service the operation. Therefore, if this aspect is configured, all messages flowing between the client and the service providers flow through the Content-Based Routing engine core.

Composite Apps requiring use of this pattern will have to employ either the Filter Request/Reply or the Filter One-Way exchange pattern. Content-Based Routing Management Configuration

  • Get/Set/Add s
  • Get/Set/Add/Edit s to

For example,

<?xml version="1.0" encoding="UTF-8"?>
<contentBasedRouting>
    <config />
    <ruleset name="myrouting_1">
        <rule name="myfirstrule">
            <xpath keyExpression="/Employee/FirstName"/>            
            <destination id="1" />
        </rule>
        <rule name="mysecondrule">
            <xpath keyExpression="/Employee/FirstName"/>            
            <destination id="2" />
        </rule>
        <rule name="mythirdrule">
            <xpath keyExpression="/Employee/FirstName"/>            
            <destination id="3" />
        </rule>
    </ruleset>
</contentBasedRouting>

Resequencer Aspect Interceptor

This allows you to re-organise messages based on some comparator. We could use an Expression to create the comparator; so that you can compare contents of a message. Use-Cases
  1. A batch of messages coming in need to be sequenced based on a predicate before being sent out.
  2. A stream of message within a particular time interval needs to be sequenced based on a predicate before being sent out.

Strategy

Resequencing algorithms can be based on:
  • Batch resequencing which collects messages into a batch, sorts the messages and sends them to their destination. Messages are collected into a batch either by a maximum number of messages per batch or using a timeout; then they are sorted in order; and then sent out to their destination.
  • Stream resequencing re-orders (continuous) message streams based on the detection of gaps between messages. Messages are re-ordered based on some sequence numbers defined by a predicate using gap detection and timeouts on the level of individual messages.

This would be used to order messages. One-Way only. Priority-Based Queuing Aspect Interceptor Based on one or multiple expressions; allows the ability to sort by priority first before sending out the message batch.

Use-Cases

  1. A batch of messages coming in need to be prioritized based on a predicate before being sent out.
  2. A stream of message within a particular time interval needs to be prioritized based on a predicate before being sent out.

Strategy

For one way messages, the Priority-Based Queuing Aspect would prioritize new higher priority messages ahead of older lower priority messages. It would have rules for allowing only x un-acknowledged messages to be outstanding and would queue up the rest. For request/reply type interactions, it could work similarly. It would allow x un-responsed requests to be outstanding. This would work for some course grain priority of messages. This could control creation of new processes based on priority. But once the business process is created it would not be able to control putting one business process ahead of the other. The configuration for such a priority-based queuing advice would be based on the message content where the XPath expression evaluates to a certain value or a range of values. Messages that pass through such a priority-based queuing aspect engine would be resequenced and queued based on the XPath rules defined. Message Filter a.k.a Message Selector Aspect Interceptor This allows you to filter messages viz., allows one to consume a message from a inbound endpoint and if the Predicate is true dispatch the message to the destination endpoint else do not pass on the message.

Use-Cases

The administrator wants to selectively send messages to an endpoint or service based on some rules. This simulates a JMS Selector, where the client will only get messages that matches his JMS Selector rules. If the message does not match the selector rule specified, the message is not even sent to the destination endpoint.

Strategy

User can specify an xpath expression or set of them, that if true don't forward on the message. One-Way and Request-Reply messages. If one-way, drop message. If req/reply return fault.

Content Filter Aspect Interceptor

Provides the ability to filter content from the inbound message.

Use-Cases

A lot of times enterprises want to strip out sensitive data like SSN, employee Ids, etc. from message content. This provides the ability to strip out data from message content, by removing sensitive information or replace sensitive content within the message with mask characters.

Strategy

This would go inside the message and strip off selected elements in the message. The gui could work by showing a list of all optional elements and attributes with a check box next to each. If the user selects the check box, then that element won't be propagated on. It will be removed from the message. One-Way and Request-Reply messages. Validator Aspect Interceptor Allows the ability to validate message content against hard validation rules which would be used to make sure the message is valid

Use-Cases

Purchase Orders are batched by combining individual orders received from various sources and sending them to a partner. These various services generate individual orders and we have to ensure the orders generated are valid. This allows the administrator to provide XSDs to validate the messages before batching them.

Strategy

This would allow the user to specify that hard validation rules would be used to make sure the message is valid. This could include XML Schema, and XML Schematron rules. Works for both One-Way and Request-Reply.

Splitter Aspect Interceptor

This allows you split a message into a number of pieces and process them individually. Allows you to take a request from an inbound endpoint, split the message into pieces using an Expression, then forward each piece to a destination endpoint. Works on one-way message exchanges.

Use-Cases

A Batched Purchase Order acknowledgment is received. The order has to be un-batched and sent to multiple different services that sent the individual orders.

Strategy

This would only work for messages that have one part and that part repeats. If the inbound message had 150 elements at this level that repeated, then it would create 150 individual messages on the output side. One-Way only.

The splitter will only work on operations that have one part, and that part is a repeating element. What the splitter will do is convert 1 message with n repeating elements into n messages each with 1 element. For example, if the operation's message has a part called foo that is a min=0, max=unlimited element called bar. And the input message has 10 "bar" elements. The the splitter would create 10 output messages each with one "bar" element.

The splitter would also put in a message exchange property that would identify each message's group id, it's message number, and a flag if it is the last one.

So in the example above the 10 messages would have the following properties

(GroupID=1, messageNumber=1, last=false)
(GroupID=1, messageNumber=2, last=false)
(GroupID=1, messageNumber=3, last=false)
(GroupID=1, messageNumber=4, last=false)
(GroupID=1, messageNumber=5, last=false)
(GroupID=1, messageNumber=6, last=false)
(GroupID=1, messageNumber=7, last=false)
(GroupID=1, messageNumber=8, last=false)
(GroupID=1, messageNumber=9, last=false)
(GroupID=1, messageNumber=10, last=true)

Aggregator Aspect Interceptor

Used to batch individual message contents into a larger message. Works on one-way message exchanges.

Use-Cases

Purchase Orders are batched by combining individual orders received from various sources and sending them to a partner. These various services generate individual orders that are batched into one big Purchase Order before they are sent out.

Strategy

This would take and collect the above 150 messages and put them back into a single message. Would need some special message exchange property that splitter would populate and aggregator would read. The special property would indicate the group message id, the message sequence number, and the last message.

The aggregator would then simply wait for all the messages and put them back into the array in the right order. It would be the responsibility of each se and aspect to preserve these message properties.

Scatter-Gather Aspect Interceptor

Works on request/reply message exchanges. Take in a request, split that request into multiple requests, and send them out to multiple recipients. Then gather all responses and send back a single response to original requestor. This would only work with request/reply operations.

Use-Cases

Receive a purchase order, get the best offer for each item from vendors, combine into a validated order and send it out to a recipient. If the input message has three repeating elements on the input message, then three separate messages each with one element will be sent out of the aspect. When the three messages come back they will be put together into the repeating element and sent back to the requester as one single message.

Strategy

This would be used to take a request in, split that request into multiple requests, gather all responses and send back a single response to original requestor. This would only work with request/reply operations.

The splitter and aggregator work on one-way messages only. The Scatter-Gather works on request reply. For now we will make it only work on WSDLs that has it's input message have only one part that has a repeating element, and the output message that has only one part that is a repeating element. What the aspect will do is break the input message's many elements into a lot of single element messages. And then take the resulting responses and put them back into a single repeating array. For example if the input message has 3 repeating elements on the input message, then 3 separate messages each with one element will be sent out of the aspect. When the 3 messages come back then will be put together into the repeating element and send back to the requester as one single message.

Caching Aspect Interceptor

Cache is placed between the client and the service that is being invoked. Works well when dealing with idempotent operations.

Use-Cases

A typical use-case is a Product Catalog that changes in-frequently, or Mortgage Quotes for the week. If the data is available in a cache it is easier to retrieve from the cache than to make a remote external call, or to perform some idempotent operation repeatedly.

Strategy

This would save the request and response and then resend if seen again. We need a way to select which element is the key. Also need a Time To Live configuration property. This works on Request/Reply messages only.

There are a couple of patterns that the Cache aspect should support for starters:

  1. Write-Through Cache (a.k.a. Transparent Cache) pattern
  2. Cache-Aside pattern

Write-Through Cache (a.k.a. Transparent Cache) pattern

This pattern ensures the Cache is placed between the client and the service that is being invoked. This makes sure all messages flowing between the client and the service provider flows through the cache.

This is the default Cache pattern that we will use. Composite Apps requiring use of this aspect will have to employ the Filter Request/Reply exchange pattern.

In a request/reply message exchange, the request message from the client is sent to the service with the Cache in the middle. The reply message to the client is cached. Subsequently, when the same request message is sent out by the client, the reply message is provided from the Cache instead of having to invoke the actual service.

Cache-Aside pattern

This pattern allows the Composite App developer to manage caching of certain key elements and their values contained within the messages that flow through the write-through cache and use it in building features into his composite app. Composite Apps requiring use of this aspect will have to employ the regular Request/Reply exchange pattern on the cache and make use of its get/put operations.

One scenario the user can use the Cache Aside pattern in his composite app is as follows:

  1. Check the cache before invoking a service by providing a list of XPath keyExpression(s).
  2. Get the value(s) directly from the cache and use them in the composite app.
  3. Optionally, if the values are not cached, invoke the actual service, and optionally, put the key/values into the cache.
  4. Optionally, evict or optionally, update the cache with new values.

Cache Aside Management configuration

The above mentioned scenarios would require that the user provide a list of XPath keyExpression(s) (present in the message) to cache. This can be provided through the Web Console which would have the ability to manage the key expressions. Typical operations include:
  • Get all Key Expressions to Cache
  • Edit Key Expression
  • Remove Key Expression
  • Edit value.

For example,

Cache Management Configuration

The Cache implementation uses a Linked HashMap. By over-riding the boolean removeEldestEntry(Map.Entry eldest) method, a First-In-First-Out cache can be created. This will ensure that if the ‘number of entries’ exceed the set limit; the oldest entry will be removed, which gives us automatic cache management. However, the cache can also be configured to be a Generic Cache in which case, Cache management will have to be provided by the Web Console. Typical management operations include:

  • Get/Set Caching Strategy
  • Get/Set Maximum Entries to Cache
  • Get Keys
  • Edit value
  • Time to Live value

Pluggability

Would be nice to have the ability to plug-in seamlessly with readily available third-party Cache implementations that are JSR 107 JCache API compliant.

Throttling Aspect Interceptor

Ensures system is not overloaded by reducing the traffic flowing into the system.

Use-Cases

Administrator realizes that the system is generating too many exceptions since components downstream cannot handle the load. So he wants to slow down intake of components upstream to ensure downstream components can handle the load without overloading the system.

Strategy

This proposal assumes the presence of a Throttling configuration that requires the administrator to specify the number of outstanding messages at any time for each endpoint. A message is outstanding after it has been sent until the DONE message has been received. This proposal will handle both transactional and non-transactional scenarios equally well.

The configuration for Component Container throttling should specify at the endpoint level.

  • component max - A maximum concurrency number (can be unlimited).
At the endpoint level,
  • Percentage of messages per endpoint with a minimum percentage (e.g., 10%) of a message maximum
  • Maximum percentage (e.g., 50%) of a message maximum to be processed at any point in time per endpoint.
  • A Ceiling (maximum) that defines the maximum to ever allocate to that endpoint (e.g. 50% of component max)
  • A Quota (reserve) setting that defines the minimum to reserve for that endpoint (e.g. 1% of component max).

Choking Aspect Interceptor

Choking policy acts between the client and the service that is being invoked and can be used to limit or deny access based on a user principal.

Use-Cases

Defined on a user-by-user basis, e.g., KCBebo can process 100 msgs/sec. GRaj can process 1000 msgs/sec.

Strategy

Can be defined on a user by user basis. Can also for example define, KCBebo can process 100 msgs/sec. GRaj can process 1000 msgs/sec. One-Way and Request-Reply. This aspect reduces the load on services based on policies which determine:
  • When to delay access
  • When to refuse access
This pattern ensures the Choking policy acts between the client and the service that is being invoked. Therefore, if this aspect is configured, all messages flowing between the client and the service provider flows through the Choking engine core. Composite Apps requiring use of this aspect will have to employ the Filter Request/Reply or the Filter One-Way exchange pattern. The Request Throttling policy should be applied based on:
  • Service Endpoints
  • Key Expressions in the message payload.
  • Remote User if the user principle is available in the Normalized message header

Choking Management Configuration

Get/Set the Number of connections allowed Get/Set the Delay by x milliseconds Get/Set the Allow/Disable access based on policies For example,
<?xml version="1.0" encoding="UTF-8"?>
<throttling>
    <config>
        <!-- Messages per second -->  
        <property name="rate" value="10" />
        <!-- Maximum number of queue entries -->  
        <property name="queue-length" value="1000" />        
    </config>    
    <ruleset name="mythrottling">
        <rule name="myfirstrule">
            <xpath keyExpression="/Employee/FirstName"/>            
        </rule>
    </ruleset>
</throttling>

Retry a.k.a. Auto-Reconnect Aspect Interceptor

If the service is unavailable, this policy reconnects to a service/endpoint for some number of tries before giving up and returning a fault. This aspect works on idempotent operations that do not need to go back to the client for conflict resolution. Works on request/reply scenarios.

Use-Cases

A remote service is down for a period of time. Clients that need to connect to the remote through an ESB can make use of the auto-reconnect feature to talk to remote services that are temporarily down.

Strategy

This would try and reconnect to a service/endpoint for some number of tries before giving up and returning a fault. Request-Reply.

In a request/reply scenario, if the service provider is unavailable, one has to block the client until the service is up again and a response is received. The Auto-Reconnect Aspect would keep trying to make the call to the destination every configurable seconds for another configurable amount of time until the service provider becomes available again or the maximum number of retries is reached based on the configuration.

This pattern ensures the Retry policy acts between the client and the service that is being invoked. Therefore, if this aspect is configured, all messages flowing between the client and the service provider flows through the Retry engine core.

Composite Apps requiring use of this aspect will have to employ the Filter Request/Reply exchange pattern.

The Retry Aspect works on idempotent operations that do not need to go back to the client for conflict resolution. Retry Management Configuration

  • Get/Set the Seconds to Retry
  • Get/Set the Maximum retries allowed

For example,


<?xml version="1.0" encoding="UTF-8"?>
<retry>
    <config>
        <!-- retry rate in msg / sec -->
        <property name="rate" value="10" />
        <!-- timeout in millisecond -->
        <property name="timeout" value="1000" />
    </config>
</retry>

Queuing a.k.a Auto-Reconnect Aspect Interceptor

If the service is unavailable, this policy reconnects to a service/endpoint for some number of tries before giving up and returning a fault. This aspect works on idempotent operations that do not need to go back to the client for conflict resolution. Works on one-way scenarios.

Use-Cases

A remote service is down for a period of time. Clients that need to connect to the remote through an ESB can make use of the auto-reconnect feature to talk to remote services that are temporarily down.

Strategy

Works for one-way only. This would get the message and send it on to the destination. If within x seconds a done is not received the message would be saved to disk and after that a done would be sent back to the originator. When the done is finally received on the outbound side, we can then delete the message.

In a one-way web service request scenario, if the service provider is unavailable, one can use a Queuing Aspect to queue the requests until the service provider becomes available again. The Queuing Aspect would keep trying to make the call to the destination every configurable seconds for another configurable amount of time until the service provider becomes available again or the maximum number of retries is reached based on the configuration.

This pattern ensures the Queuing policy acts between the client and the service that is being invoked. Therefore, if this aspect is configured, all messages flowing between the client and the service provider flows through the Queuing engine core.

Composite Apps requiring use of this pattern will have to employ the Filter One-Way exchange pattern.

The Queuing Aspect works on idempotent operations that do not need to go back to the client for conflict resolution. Queuing Management Configuration

  • Get/Set the Seconds to Retry
  • Get/Set the Maximum retries allowed

For example,


<?xml version="1.0" encoding="UTF-8"?>
<queuing>
    <config>
        <!-- Maximum number of queue entries -->  
        <property name="queue-length" value="1000" />
        <!-- time specified in sec/ millisec-->
        <property name="timeout" value="1000" />
        <property name="queue-type" value="normal / priority">
    </config>
</queuing>

Logging Aspect Interceptor

Used to log messages/message content as messages pass through

Use-Cases

The administrator wants to start logging messages or message content for an endpoint/service.

Strategy

The Logging aspect can be used to control logging output. The logging Level objects are ordered and are specified by ordered integers. Enabling logging at a given level also enables logging at all higher levels. The levels in descending order are:
  • SEVERE (highest value)
  • WARNING
  • INFO
  • CONFIG
  • FINE
  • FINER
  • FINEST (lowest value)
In addition there is a level OFF that can be used to turn off logging, and a level ALL that can be used to enable logging of all messages. This pattern ensures the Logging policy acts between the client and the service. Therefore, if this aspect is configured, all messages flowing between the client and the service providers flow through the Logging engine core. Composite Apps requiring use of this pattern will have to employ either the Filter Request/Reply or the Filter One-Way exchange pattern. Logging Management Configuration
  • Get/Set the Logging Level
  • Get/Set Rotation Policy
  • Get/Set Log file location
For example,
<?xml version="1.0" encoding="UTF-8"?>
<logging>              
    <config>
        <property name="level" value="INFO"/>
        <property name="rotation-policy" value="DAILY" />
        <property name="log-file" value="C:\\temp\\loggingse.log" />
    </config>
</logging>

Lease Management Aspect Interceptor

Can define length of time a particular user can access a resource. Should use user names and not explicit tokens.

Use-Cases

For example we have a list like:

User NameStart TimeEnd Time
KCBebo10/20/2008 12:23 AM 11/20/2008 12:23 AM
GRaj11/5/2008 2:33 PM 12/17/2008 4:55 AM
Then when the web service is invoked that has the KCBebo credentials on October 21' 08 it allows the call. But if the call was made with GRaj on October 21 '08, then it returns a fault because GRaj cannot access the service until November 5th.

Let's say in May KCBebo tried the call again, it fails because his lease expires. The aspect will need to look at the message exchange property that contains the security context that has the name of the principle (aka user) that is invoking this service.

Strategy

Can define length of time a particular user can access a resource. Should use user names and not explicit tokens. Works on One-Way and Request-Reply messages.

For lease management we need to keep a list of users. And for each user we have the start time and end time for when that user can request that service.

Prioritization Aspect Interceptor

Based on users or message content decide what messages get processed before others.

Use-Cases

Prioritize messages based on purchase price. That means in every batch of 100 messages, the largest orders get process first.

Strategy

Based on users or message content decide what messages get processed before others. For example, prioritize messages based on purchase price. That means the largest orders get process first. The user would configure this by selecting the element in the message with an xpath expression. Could also be based on users. The configuration will be based on a batch with a batch size or a stream of data based on time . One-Way and Request-Reply.

Message Tracking Aspect Interceptor

Keep track of messages and their corresponding messages.

Use-Cases

View the path a message instance has taken through an orchestration. This allows you to track or debug the flow.

Strategy

Keep track of messages and their corresponding messages. This would allow the user to specify which message element represents the correlation key. Then the message and key would be saved to a database table and someone could then track all messages associated with that key.

The Message Tracking aspect can be used to track messages flow through the system. Message Tracking will happen based on a configurable Rule Set which can be configured from the Web Console.

This pattern ensures the Message Tracking policy acts between the client and the multiple services that are involved to service the operation. Therefore, if this aspect is configured, all messages flowing between the client and the service providers flow through the Message Tracking engine core.

Composite Apps requiring use of this pattern will have to employ either the Filter Request/Reply or the Filter One-Way exchange pattern. Message Tracking Management Configuration

  • Get/Set/Add s
  • Get/Set/Add/Edit s to
  • Specification based
  • Pre-condition based
  • Get messages based on ID - Each normalized message has a unique message identifier that lets you select all the recorded events for a specific message.

For example,

<?xml version="1.0" encoding="UTF-8"?>
<message-tracking>
    <config>
        <property name="mode" value="database / file" />
        <!--
        config can have more params defining the database/file locations.
        -->
    </config>
    <ruleset name="myMessageTracking">
        <rule name="myfirstrule">
            <xpath keyExpression="/Employee/FirstName"/>            
        </rule>
    </ruleset>
</message-tracking>

Catch-Edit-Retry (a.k.a. Manual Recovery) Aspect Interceptor

When a failure occurs, this aspect stores the request in a database for future review. At a later point in time, an administrator can come in, inspect the message, change it if required, and retry sending the message.

Use-Cases

Useful in a scenario where message contents have invalid characters the prevent processing. Once these invalid characters are removed, the message can flow through.

Strategy

When a failure occurs, this aspect stores the request in a database for future review. At a later point in time, an administrator can come in, inspect the message, change it if required, and retry sending the message.

Audit Trail Aspect Interceptor

An audit trail or audit log is a chronological sequence of audit records, each of which contains evidence directly pertaining to and resulting from the execution of a business process or system function.

Use-Cases

In what relates to audit trail, it is also very much important to take into consideration the liability issues of your audit trails, as many times in case of dispute, these audit trails can work as an evidence for some incident.

Strategy

Keeps a track of users that accessed the system. The username is obtained from the Normalized Message Header property and the information is tracked in a database.

Chargeback Aspect Interceptor

Track usage information based on user, or some predicate.

Use-Cases

A Chargeback is initiated by the credit-card holder, who may contact his/her card issuing bank regarding an inconsistency in his/her monthly credit card statement. This begins the dispute process that may eventually lead to a chargeback, and a reinstatement of credit to the cardholder's account.

Strategy

Track usage information based on user, or some predicate. Keep track in a database that is user configurable each request and the user that made the request. Works on both One-Way and Request-Reply exchanges.

Monitoring Aspect Interceptor

Keep track of number of messages, number of errors, response time, message throughput, the number of messages processed by a given component, average time per message, average time a message needs to wait in queue to be processed by a component... for all services.

Use-Cases

Used by an administrator to track the health of the system

Strategy

Keep track of number of messages, number of errors, response time, message throughput, the number of messages processed by a given component, average time per message, average time a message needs to wait in queue to be processed by a component... for all services. This would be a basic fact table for all requests and responses that could be analytically processed as a cube. One-Way and Request-Reply.

Record/Replay Aspect Interceptor

Record and playback messages in sequence

Use-Cases

In a lot of enterprises, customers want to simulate a production environment where they want to recreate the actual environment in a test lab before putting the applications in production. A system that can record messages received in a production environment and play it back in the same sequence in a test environment would be helpful to test the system.

Strategy

This would allow messages that pass through it to be recorded and then later played back. Would allow someone to capture the traffic and then replay that without the external applications being involved. Help for problem reproduction. . One-Way and Request-Reply.

Simulator Aspect Interceptor

Simulate high-load conditions.

Use-Cases

In a lot of enterprises, customers want to simulate a high-load production environment. It would help if a simulator could generate random test data that can be used to simulate load conditions.

Strategy

This would emulate a service by providing random response generation based on the xml schema for the response message. request/reply only.

Runtime Implementation Choices

The runtime backend implementation can be achived either with:
  1. Including the capability in an Inteceptor available in the OSGi/JBI runtime as:
    1. Separate bundles that can be independently installed into the runtime
    2. Including the capability in the Service Assembly deployment bundles
  2. A Separate Service Engine to handle these concerns
  3. Including the capability in each JBI component container.

User-Interface Implementation Choices/Suggestions

The user interface for this capability to configure the different aspects should be exposed through both thin-client (Web UI) and thick-client (NetBeans) interfaces. To that end, we should expose this capability using:
  • NetBeans
  • The Management & Monitoring Web Console
  • The Dynamic Service Composition UI being developed as part of Fuji.


JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-8) was last changed on 15-Oct-09 10:45 AM, -0700 by AndiEgloff