IFL Scenarios

Arrows indicate the message exchange pattern such as in-only or in-out.

HTTP BC -> BPEL (in-only)

SOAP "SOAPEndpoint"
BPEL "RecPartnerLink"

route do
  from "SOAPEndpoint"
  to "RecPartnerLink"
end

 
route from "SOAPEndpoint" to "RecPartnerLink"

HTTP BC -> BPEL (in-out) <-

route from "SOAPEndpoint" to "RecPartnerLink"

HTTP BC -> transform -> BPEL (in-only)

route do from "SOAPEndpoint" to "EERequestReploy" to "RecPartnerLink" end

or route do from "SOAPEndpoint" to in:"EERequestReploy" to "RecPartnerLink" end

(should this be called a filter or is it confusing that it transforms? Should there be a "sequence" construct?)

HTTP BC -> request transform -> BPEL (in-out) <- response transform <-

route do from "SOAPEndpoint" to in:"EERequestReploy" out:"EE2RequestReply" to "RecPartnerLink" end

HTTP BC -> BPEL (in-out) -> EE Webservice (in-only) <- -> HTTP BC (in-out) <-

route from "SOAPEndpoint" to "RecPartnerLink"

route from "InvokePartnerLink1" to "EEServiceEndpoint"

route from "InvokePartnerLink2" to "SOAPEndpoint2"

HTTP BC -> sequence -> CICS BC (in-out) <- | <- | -> JDBC BC (in-only) | -> HTTP BC (in-out) <- <-

route do from "SOAPEndpoint" to in:"CICSRequestReply" to in:"JDBCOneWay" to HttpRequestReply" end

For "to" with in-out the rule would be the output is linked to the next input if it's not at the end For "to" with in-only the rule could be that the last relevant input remains valid?

(overload to for final service as well as filter?)

RSS BC -> request filter -> broadcast -> request transform -> XMPP BC (implicit operation / operations match) -> AjaxPush BC

route do from "myFeed" to "rubyFilter" broadcast do branch do to "transform" to "notifyMe" end branch to "publisMe" end end

(? How does it actually remove messages in this "filter"? Does it need a separate construct for interceptors from true filtering?)

Possible alternative with explicit "filter". Danger: filter here really means removing stuff, not really "pipe and filter"

route do from "myFeed" filter "rubyFilter" broadcast do branch do to "transform" to "notifyMe" end branch to "publisMe" end end

alternate definition?

route do from "myFeed" filter "rubyFilter" broadcast do branch "transformAndNotify" branch to "publisMe" end end

def "transformAndNotify" do to "transform" to "notifyMe" end

Demo scenario (slightly simpler than above, not transform in broadcast)

RSS BC -> request filter -> broadcast -> XMPP BC (implicit operation / operations match) -> AjaxPush BC

3 equivalent variants

RSS "myRSS" JRuby "filterFeed" XMPP "notifyMe" AjaxPush "displayOnPage"

route do from "myRSS.processFeed" to "filterFeed.filter" broadcast do branch to "notifyMe.sendIM" branch to "displayOnPage.push" end end

variant 2:

route do from RSS "myRSS.processFeed" to JRuby "filterFeed.filter" broadcast do branch to XMPP "notifyMe.sendIM" branch to AjaxPush "displayOnPage.push" end end

and again variant 3 with pre-defined services

route do from "myRSS.processFeed" to "filterFeed.filter" broadcast do branch to "notifyMe.sendIM" branch to "displayOnPage.push" end end

HTTP BC -> JDBC BC (in-only, but operations don't match)

route from "SOAPEndpoint.operation1" to "JDBCOneWay.updateCustomer"

route from "SOAPEndpoint.operation2" to "JDBCOneWay.deleteCustomer"

route from "SOAPEndpoint.operation3" to "JDBCOneWay.createCustomer"

route from "SOAPEndpoint.operation4" to "JDBCOneWay.readCustomer"

or let's say only few operations don't match - default and override?

route from "SOAPEndpoint" to "JDBCOneWay"

route from "SOAPEndpoint.operation1" to "JDBCOneWay.updateCustomer"

or should we consider an explicit mapping construct? Could default to using "as is" if not mapping defined.

route do from "SOAPEndpoint" map_operation (operation1=insertCustomer, operation2=updateCustomer) to "JDBCOneWay" end

HTTP BC -> Dynamic Router

(as usual, artifact type "DynamicRouter" is optional

route from "SOAPEndpoint" to DynamicRouter "myRouter"

How do we just "publish" target endpoints that can by dynamically called. Something like?

route From "LocalCandidateEndpoint1"

route from "LocalCandidateEndpoint2"

(? Should it actually allow defining some of the candidate endpoints here? Dynamic routing rules only defined outside of the language, e.g. in a DB?)

This page (revision-2) was last changed on 04-May-08 17:45 PM, -0700 by AndiEgloff.
This page was created on 04-May-08 17:38 PM, -0700 by AndiEgloff.

More info...