AMIS organized its annual Oracle OpenWorld and JavaOne preview event last Tuesday. The event is organized for people that don't attend OpenWorld and for presenters to rehearse their sessions and get feedback from the audience. Vennster gave two presentations:
- Using Eclipse DBWS to Interface with Legacy Applications - Lonneke Dikmans
- Effective Fault Handling in Oracle Service Bus and SOA Suite 11g - Ronald van Luttikhuizen; co-presented at OpenWorld with Guido Schmutz, Technology manager at Trivadis
This blog includes the updated slides of the Fault Handling presentation and contains a Q&A section that answers questions from the audience at the preview event. Lonneke will post the slides of her presentation in a follow-up blog. Last but not least, thanks to AMIS for hosting the event!
Fault Handling
It is one thing to architect, design, and code the “happy flow” of your automated business processes and services. It is another thing to deal with situations you do not want or expect to occur in your processes and services. This session dives into fault handling in Oracle Service Bus 11g and Oracle SOA Suite 11g, based on an order-to-cash business process. Faults can be divided into business faults, technical faults, programming errors, and faulty user input. Each type of fault needs a different approach to prevent them from occurring or to deal with them. For example, apply User Experience (UX) techniques to improve the quality of your application so that faulty user input can be prevented as much as possible. This session shows and demos what patterns and techniques can be used in Oracle Service Bus and Oracle SOA Suite to prevent and handle technical faults as well as business faults.Q&A
This section lists answers to the questions that were raised during the preview event.
Q: Where can retries be configured in Oracle Service Bus?
The retry mechanism is used to prevent faults caused by temporary glitches such as short network interruptions. A faulted message is resend (retried) and might succeed this time since the glitch has passed. Retries are an out-of-the-box feature that can be used in Oracle Service Bus and Oracle SOA Suite using the Fault Policy framework. By default, retries are disabled in Oracle Service Bus.
In Oracle Service Bus retries can be configured for several artifacts, among others the following:
Q: Where can retries be configured in Oracle Service Bus?
The retry mechanism is used to prevent faults caused by temporary glitches such as short network interruptions. A faulted message is resend (retried) and might succeed this time since the glitch has passed. Retries are an out-of-the-box feature that can be used in Oracle Service Bus and Oracle SOA Suite using the Fault Policy framework. By default, retries are disabled in Oracle Service Bus.
In Oracle Service Bus retries can be configured for several artifacts, among others the following:
- Retries can be configured on Business Services as part of their Transport Configuration.
- Retries can be configured for inbound JCA-based Proxy Services as endpoint properties: jca.retry.count, jca.retry.interval, jca.retry.backoff, and jca.retry.maxInterval.
- Retries can be configured for outbound JCA-based Business Services using the same endpoint properties.
- Retries can be configured for JMS Proxy Services and (S)FTP Proxy Services as part of the Advanced Settings.
See Oracle's Developer’s Guide for Oracle Service Bus 11g for all possible retry configurations.
Mind transaction boundaries and write operations when configuring retries. For example, consider a flow that is composed of two actions in which the first action inserts a record in the database and then commits, while the second action invokes a Web Service. When the second action fails and the entire flow is retried, you might end up with two new, identical records.
Mind transaction boundaries and write operations when configuring retries. For example, consider a flow that is composed of two actions in which the first action inserts a record in the database and then commits, while the second action invokes a Web Service. When the second action fails and the entire flow is retried, you might end up with two new, identical records.
Q: What other load-balancing algorithms can be used besides round-robin?
When there are multiple instances of a service that are invoked from Oracle Service Bus, load-balancing can be configured on Business Services. Load-balancing can prevent faults by retrying messages that were sent to unavailable endpoints to other, hopefully active endpoints. Load-balancing is disabled by default. When enabled, the default algorithm that is used for load-balancing is round-robin.
The Oracle's Developer’s Guide for Oracle Service Bus 11g lists all possible load-balancing algorithms:
"Specify the load balancing algorithm as any one of the following values:
When there are multiple instances of a service that are invoked from Oracle Service Bus, load-balancing can be configured on Business Services. Load-balancing can prevent faults by retrying messages that were sent to unavailable endpoints to other, hopefully active endpoints. Load-balancing is disabled by default. When enabled, the default algorithm that is used for load-balancing is round-robin.
The Oracle's Developer’s Guide for Oracle Service Bus 11g lists all possible load-balancing algorithms:
"Specify the load balancing algorithm as any one of the following values:
- Round-robin - This algorithm dynamically orders the URLs that you enter in the Endpoint URI field for this business service. If the first one fails, it tries the next one, and so on until the retry count is exhausted. For every new message, there is a new order of URLs.
- Random - This algorithm randomly orders the list of URLs that you enter in the Endpoint URI field for this business service. If the first one fails, it tries the next one, and so on until the retry count is exhausted.
- Random-weighted - This algorithm randomly orders the list of URLs that you enter in the Endpoint URI field for this business service, but some are retried more than others based on the value you enter in the Weight field.
- None - This algorithm orders the list of URLs that you enter in the Endpoint URI field for this business service from top to bottom."
Q: How is throttling implemented in Oracle Service Bus (in-memory, JMS, etc.)? Are messages in the throttling queue lost when the server fails?
Throttling introduces a message queue between a Proxy Service and a Business Service that temporarily stores messages to prevent backend systems from overloading. Whenever the number of messages exceeds the thresholds as configured in the throttling settings, the message is stored in a queue. When the number of messages that need to be processed decreases, messages are removed from the queue and sent to the backend system via the Business Service.
The Oracle Administrator’s Guide for Oracle Service Bus 11g discusses throttling and its configuration:
"A throttling queue is an in-memory queue. Messages that are placed in this queue are not recoverable when a server fails or when you restart a server. When you delete or rename a business service, all the messages in the throttling queue are discarded."
The Oracle Administrator’s Guide for Oracle Service Bus 11g discusses throttling and its configuration:
"A throttling queue is an in-memory queue. Messages that are placed in this queue are not recoverable when a server fails or when you restart a server. When you delete or rename a business service, all the messages in the throttling queue are discarded."
Q: What values can be used as key for the Result Cache feature?
The result cache in Oracle Service Bus can be used to store data in-memory. When data is queried that is present in the cache, the data is fetched from memory instead of the query being sent to, and executed by the backend system. This decreases the load on the backend system. Note that this feature only works for data that is static; meaning the data is seldom changed. If not, the cache will result stale and out-of-date information. As part of the Result Cache feature you need to configure the key that is used to determine if the associated data is in the cache.
The Oracle's Developer’s Guide for Oracle Service Bus 11g says:
"Cache Token Expression – Oracle Service Bus uses a cache key to identify cached results for retrieval or population, and the cache token portion of the cache key provides the unique identifier. You can use an expression—the Cache Token Expression—to generate the cache token part of the cache key to uniquely identify a cached result for the business service.
The Cache Token Expression must resolve to a String or the value of simple content, such as an attribute or an element with no child elements. If the expression evaluates to null or causes an error, results are not cached."
The Oracle's Developer’s Guide for Oracle Service Bus 11g says:
"Cache Token Expression – Oracle Service Bus uses a cache key to identify cached results for retrieval or population, and the cache token portion of the cache key provides the unique identifier. You can use an expression—the Cache Token Expression—to generate the cache token part of the cache key to uniquely identify a cached result for the business service.
The Cache Token Expression must resolve to a String or the value of simple content, such as an attribute or an element with no child elements. If the expression evaluates to null or causes an error, results are not cached."
No comments:
Post a Comment