IFL Scenarios

Some examples from simple to complex to show how different scenarios can be expressed in IFL.

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

File -> File

file "infile"
file "outfile"

route from "infile" to "outfile"

File -> filter (removes entries) -> File

file "infile"
file "outfile"

route do
   from "infile"
   to "filter" 
   to "outfile"
end

File -> transform -> File

Note same as filter scenario, filter logic itself decides

file "infile"
file "outfile"

route do
   from "infile"
   to "filter" 
   to "outfile"
end

RSS BC -> request filter -> broadcast -> XMPP BC -> File BC

rss "myFeed"
jruby "filterFeed"
xmpp "notifyMe"
file "archive"

route do
  from "myFeed"
  to "filterFeed"
  broadcast do
     route to "notifyMe"
     route to "archive"
  end
end

Other Scenarios Where We Need to Add ArcheTypes to the Technology Preview

Listed here for understanding and discussion purposes, these are not yet tested or supported

HTTP BC -> BPEL (in-only)

soap "SOAPEndpoint"
bpel "RecPartnerLink"

route do
  from "SOAPEndpoint"
  to "RecPartnerLink"
end

or alternate syntax

 
route from "SOAPEndpoint" to "RecPartnerLink"

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

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 would be that the last relevant input remains valid.

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

For this the explicit operations support needs to be added.

  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"

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

More info...