Some javascript/style in this post has been disabled (
why?)
Please comment in particular on whether you think scoping a namespace
to an IFL file by default is more desirable than the original thought
of application wide scope.
There have been some points raised about the last proposal (forwarded
at the bottom).
- Scope of namespaces beyond the file might seem unexpected and
possibly
error prone
- Using "public"/"private" both as a
prefix name and as a visibility modifier keyword is confusing
- Relative uris should not start with slash
The biggest challenge is the scope of the namespace, assuming we want
to keep some kind of capability to declare a namespace prefix once per
application. IFL files today deliberately just provide for logical
grouping, and any service / route definition within the application is
visible to any other IFL file.
Here is one proposal which makes some minimal changes to the current
approach to see if it can address the suggestions:
Overview of Changes
- Namespace definitions within an IFL file are local to that IFL
file
- A special file "shared-namespaces.ifl" lists namespaces that have
an application wide visibility scope
- Local namespaces defined in an ifl file can override the shared
namespaces
- Relative uris don't start with slash
- Prefixes used to configure default namespaces use a -ns suffix to
not confuse it with the "public" visibility modifier keyword
Example app.ifl
Example with namespace app3 defined in the IFL, app4 defined as
shared namespace
namespace app3 "app3"
file "in-file"
bpel "purchase-order"
route do
from "in-file"
to "app3:convert-order"
to "app4:purchase-order"
end
Example shared-namespaces.ifl
# base URI used for relative URIs
namespace base-ns "http://fuji.dev.java.net/application/"
namespace public-ns "my-app"
namespace private-ns "my-app/private"
# User defined namespaces, relative to base URI or absolute
namespace app4 "app4"
namespace ex2 "http://some.other.com/absolutens"
The side effect of the updated namespace scope would be that:
- other IFL files can again declare the app3 prefix, and either
assign it the same or another namespace.
- Can make IFL files more self-contained
- an IFL file can override the app4 prefix if the "global"
namespace definition does not apply to this file
Andreas Egloff wrote:
Below is the current proposal for adding explicit namespace support to
IFL. Note that in this
approach I removed the idea from earlier proposals of namespaces in
properties files.
http://wiki.open-esb.java.net/Wiki.jsp?page=FujiNamespacesAndServiceVisibility
Feedback is appreciated.
Thanks,
Andi
Namespaces Basic Approach
- A namespace keyword in IFL to declare namespaces
- Route service names can use these declarations for prefixes, or
it can use in-line QNames ("stringified")
- A separate namespaces.ifl is generated by default. All
declarations in ifl files are visible across all ifl files in an
application, hence this is a cosmetic grouping
Example namespaces.ifl
# base URI used for relative URIs
namespace base "http://fuji.dev.java.net/application/"
namespace public "/my-app"
namespace private "/my-app/private"
# User defined namespaces, relative to base URI or absolute
namespace app3 "/app3"
namespace ex2 "http://some.other.com/absoluatens"
The first three entries are the defaults generated. base, public and
private are reserved namespace prefixes that Fuji uses to resolve
relative URIs and for services of different visibility.
- base : defines the base URI that all relative URIs get resolved
against. Allows for easy referencing of other fuji apps.
- public : namespace that any service marked as "public" (ESB
visibility) is placed in
- private : namespace that any service with default visibility
(or
explicitly marked private) is placed in. Not intended to be called by
other applications.
Example app.ifl using namespace prefix
file "in-file"
bpel "purchase-order"
route do
from "in-file"
to "app3:convert-order"
to "purchase-order"
end
Example app.ifl using in-line namespace (relative URI)
file "in-file"
bpel "purchase-order"
route do
from "in-file"
to "{/app3}convert-order"
to "purchase-order"
end
as shown above the proposal is to use the common convention of
representing QNames as strings: {namespace}local name
Example app.ifl using in-line namespace (absolute URI)
file "in-file"
bpel "purchase-order"
route do
from "in-file"
to "{http://fuji.dev.java.net/application/app3}convert-order"
to "purchase-order"
end
Example app.ifl declaring namespace in same file
It is permissible to put namespace declarations in the IFL files
directly, note that dupplicate namespace definitions are not allowed.
Hence it is good practice (particularly when using the namespace across
multiple IFL files) to put the declaration in the namespaces.ifl and by
default our tooling will do just that.
namespace app3 "/app3"
file "in-file"
bpel "purchase-order"
route do
from "in-file"
to "app3:convert-order"
to "purchase-order"
end
Visibility
In the above examples, the services are in the default "private"
namespace. To make a service callable from outside the application, use
the "public" visibility modifier keyword. This indicates the
expectation that any application on the ESB can call the service. In
the future we may add an "external" visibility modifier that
automatically exposes the service to callers outside the ESB too.
Public "named route" example
jruby "validate"
java "convert"
public route "convert-order" do
to "validate"
to "convert"
end
Public "service declaration" example
public email "email-service"
