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"

ns:ep1ns=http://test.com/myNS

route from "ep1ns:SOAPEndpoint.buy" to "RecPartnerLink.buy"

operations are optional

SOAPEndpoint.properties namespace=http://test.com/myNS

RecPartnerLink.properties bpel=bp1.bpel

default for generating both BPEL and PL details? Can we ask/prompt?

Namespaces? Can we say in the IFL namespaces are optional, only needed to disambiguate? Generate default namespace using project name? Warn/Failure if ambiguous?

What about work-flow with existing WSDL? - Maybe place wsdl in artifact directory for service/endpoint? is that kosher? what about wsdl with more than one port/endpoint defined? - Properties file points to WSDL? If more than one port/endpoint in WSDL, more than one properties file points to common WSDL file

SOAPEndpoint.properties wsdlfile=ATest.wsdl

HTTP BC -> BPEL (in-out) <- same as above, e.g.

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-1) was last changed on 04-May-08 17:38 PM, -0700 by AndiEgloff.

More info...