February 10, 2008   Sign In |  About ebizQ |  Contact Us |  Join ebizQ Gold Club
James Taylor
James Taylor's Decision Management
James is one the leading experts in enterprise decision management, a published author and a principal of Smart (enough) Systems LLC. His blog discusses the use of decision management technologies like predictive analytics and business rules to deliver agility, improve business processes and bring intelligent automation to SOA.

« More on rules and event processing | Main | Measuring Agility »

January 23, 2008
How DO decision services get data?

One of the interesting questions about decision services is the extent to which they should be able to gather their own data. Opinions on this range from a limitation of decision services being that they must be passed all the data they require to one in which even long running requests for data, say those involving a human, can be accommodated. Even if we take the position, as I do, that decision services are fundamentally synchronous, we still have a number of options:

  1. Pass all the data available into a decision service and force it to either decide or to pass back some reason why it could not decide (to do with a lack of data, say) so that the calling application can assemble the additional data required and try again.
  2. Pass the data available to the decision service but allow it to call external services and/or databases to gather the data it needs to complete the decision. Only synchronous calls are allowed as the service remains synchronous.
  3. Pass the data available to the decision service and allow it to call external services and to request additional data from a user interface. The decision is still synchronous in that it continues to run/use a thread until the data is provided through the user interface or the request for a decision is cancelled.
  4. Pass the data available to the decision service and allow it to gather the data it needs in any way. While the decision remains synchronous, in that the calling service is waiting for an answer, the decision service may be passivated or otherwise put “on ice” while waiting for the necessary data.
If synchronous behavior is not required then clearly a decision service can be invoked asynchronously, allowed to gather the data it needs to make a decision and then return its result, typically through transmission of an event. This kind of service is common in event-based architectures.

Posted by jtaylor in Business RulesDecision TechnologiesSOA |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/3074

Comments Post a comment




Remember Me?

(you may use HTML tags for style)

We ask that you type your code (displayed below) in the text box.This code is an image that cannot be read by a machine. It prevents automated programs from submitting comments.


Code:



Most Recent ebizQ Blog Entries
ADVERTISEMENT
This Work
Accountability:The opinions expressed in this blog are solely representative of the blog's author, and not of ebizQ

Subscribe to our Newsletters
ebizQ Weekly Gold Club Update
Live Webinar Updates
Updates from ebizQ Partners
ebizQ SOA Update
ebizQ BPM Update
ebizQ Security Update
ebizQ BI Update
ebizQ Open Source Software Update
Virtual Show Newsletter
Your E-mail Address:
BAM: The Killer App for CEP
Date: Feb 12, 2008
Time: 12:00 PM ET
(17:00 GMT)

I WANT TO ATTEND
Event Processing Market Pulse
Date: Feb 14, 2008
Time: 12:00 PM ET
(17:00 GMT)

I WANT TO ATTEND
Archived Webinars | Upcoming Webinars

Marketing Solutions | Feedback | About ebizQ | Unsubscribe | Privacy Policy | Site Map