Index Changes

Key Parts of IFL

An IFL file contains the following two basic elements:
  • Service declarations (optional*)
  • One or more route definition(s)

Although our examples use a line based syntax the current IFL does not yet add that restriction on route definitions; we may consider the limitation if it keeps IFL simpler and more concise as it grows

Example

rss "myFeed"
file "archive"

route do
   from "myFeed"
   to "archive"
end

Service Declarations

Service declarations allow for a rapid top-down workflow by declaring the type of a service. This type can be used (in combination with maven archetypes) to generate a default service that can then be modified to fit your needs.

This declaration is optional* if the user doesn't want to take advantage of this feature and defines the services explicitly, e.g. in a bottom-up or meet-in-the-middle approach where there may be existing services to link together.

Service declarations can occur anywhere in the file, although a typical convention is to add them at the top.

Format:

<service type> "<logical service name>"
Examples:
file "MySalesFile"
rss "cnnnewsfeed"
xmpp "IM"


*) the first technology preview focuses on the top-down work-flow and hence uses service declarations

IFL Keywords

At the root of IFL consists are three basic keywords; the route keyword being the top level (enclosing) keyword, and the simple "from" and "to" instructions inside the route. These allow the realization of a pipe-and-filter pattern to route messages. In addition, "composed" patterns (e.g. split, filter, broadcast...) can be added within the route to realize more advanced enterprise integration patterns.

Keywords

Code blocks with do ... end are used (instead of for example curly brackets) to enclose statements

Items Notably Absent from IFL

  • No message definitions in the IFL itself. The goal is to allow for free-form messages by default and allow for stronger typing in the service definition itself. This allows for a more dynamic and REST style approach with implicit knowledge of payloads but still provides for an approach with explicit definitions.
  • No Message Exchange Patterns (such as in-only, in-out) are defined. Again, we want to see if it is sufficient to let the underlying service define these; it may be required to add this into the language
  • No QoS or Policies; we should define how and where these get defined, currently the thought is that these policies may be provisioned in another fashion
  • No operations (yet). We want to support implicit operations and allow for specifying no operation as well, relying on message based service exchange principles. But it must be possible to work with operations as well. One proposal is to enhance IFL with optional operations such as:
   route do
      from "<logical service name>.<optional operation>"
      to "<logical service name>.<optional operation>"
   end
  • Namespaces (yet). The logical service names used in IFL are using a default namespace specific to the integration application. For bottom up approaches and for referring to service in other integration applications it must be possible to specify a namespace. One proposal is to prefix directly in the service name string, e.g. as stringified QName.
route from "{http://test.com/myNS}SOAPEndpoint" to "RecPartnerLink"

IFL enhancements going forward

  • Publish the contract to extend IFL (allow the community / users to match their needs)
  • More "composed" enterprise integration patterns out of the box (breadth)
  • Enhancements to existing enterprise integration patterns out of the box (depth)
  • Other enhancements: explicit namespaces, possibly operations (see above)

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-11) was last changed on 24-Feb-09 15:35 PM, -0800 by AndiEgloff