Fuji's Frequently Asked Questions

General

What's the relationship to OpenESB and OpenESB v2?

OpenESB is the community that Fuji is part of. The OpenESB v2 platform represents the architecture and codeline which forms the basis for the current production versions of the platform in Java CAPS and the upcoming GlassFish ESB v2.

Fuji represents an evolution and revolution of that stack as a basis for an upcoming OpenESB v3 / GlassFish ESB v3. Evolutionary in the sense that Fuji still supports the JSR 208 contract and applications developed in the context of v2 will continue to run. Revolutionary in the sense of productivity and flexibility (including OSGi to push the envelope on modularity and light weight platforms, web tooling and domain specific language options etc.)

What's the relationship to GlassFish ESB?

GlassFish ESB is a binary distribution that combines technology from Project OpenESB, the GlassFish application server and the NetBeans IDE communities into a commercial distribution supported by Sun Microsystems. The upcoming GlassFish ESB v2 release leverages the stability and enterprise features of the OpenESB v2 codeline. Current plans are that Project Fuji forms the basis of a next generation GlassFish ESB. In that context it is important to realize that Fuji is evolutionary in the sense that applications developed in the context of v2 also run on the v3 architecture thanks to both supporting the JSR 208 (JBI) standard.

Building

Running

OSGi

Is the OSGi service registry used as the registry for the NMR?

Yes and no. The OSGi service registry provides a great way to share services between software components in an OSGi runtime. The internal endpoint registry in the NMR is really just an address map for activated service endpoints. As such, it's not really meant to be consumed by anything other than the NMR itself.

That said, we have added a nice little feature in Fuji where each activated service endpoint has a corresponding "ServiceChannel" registered in the OSGi service registry. ServiceChannel provides a simple programmatic API for interacting with an endpoint hosted in Fuji.

JBI

IFL

What is the relationship of IFL to BPEL?

IFL is explicitly designed to be complementary to BPEL in that BPEL only operates on abstract definitions (including partner links), the IFL is used to map the logical name BPEL uses (partner link) to the concrete services - and hence routes to the concrete service.

It is also design that several scenarios can be expressed in either BPEL or in IFL as a top goal of IFL is to not force users to use an advanced (but complex) language such as BPEL for basic routing / enterprise integration pattern tasks.

It should also be noted that BPEL with its business process focus has a different design center or view than the enterprise integration pattern focus of IFL. Hence one or the other may fit the domain specific problem more in terms of the way the problem is approached.

To stay true to the goals of IFL it must stay concise and to the point, complexity is avoided wherever possible - at the cost of not covering some scnearios. In those cases a language such as BPEL with the desired functionality should be used.

Why does it only have a few enterprise integration patterns supported today?

As a basic principle in Project Fuji and IFL we want to share early and often; we want to develop a language in the community that is truly useful, not invented in isolation. That is to say that there surely are more patterns that would be useful to add to IFL, not all of them may require a special keyword though.

Is it a line based syntax?

Not today, although our examples show a line based syntax our parser does not require this. We may consider this limitation in the future if it keeps the language simpler.

What kind of domain specific language (DSL) is it

IFL is an external DSL in language oriented programming terms, although it does borrow from a scripting/ruby syntax. This means we're not extending another generic language to parse and use the DSL. An internal DSL (just as a JRuby DSL) would mainly be useful if there was a desire to use the generic language's power embedded in the DSL. This is not the case with IFL today.

Why didn't you use XML? Or Java? Or....?

We want the language to be as concise as possible so it can be created and edited productively even in a text editor. XML or Java have a certain overhead associated with them (pointy or curly brackets etc). The key to keeping the learning curve small we believe is to keep the language very concise and the syntax straight forward and familiar (hence the similarity to ruby)

Aren't there other technologies for composing services already?

Yes there are, it seems no-one has hit the sweet spot yet though with a productive language and model that fits the problems encountered in this domain well. We're putting this language out there to the community as a proposal to see if this can evolve to fulfill this gap.

Exactly where does IFL execute if it is not in its own jbi container?

IFL is not an 'executable' language, it is used to declare the services used in your application and define the routing between those services. At packaging-time, the IFL is converted into configuration consumable by the underlying Fuji runtime. Software components deployed in Fuji do not have to worry about consuming IFL directly.

If IFL is able "join" services and route messages between them, is it potentially replacing responsibilities which currently exist in the current JBI service assembly connection information? What are the consequences of having doing that from a end-user developer perspective.

Quite to the contrary, during the packaging phase, service wiring details in the IFL are converted into service assembly connection information. This is a great example of how Fuji reuses many of the robust JBI mechanisms "behind the scenes" without requiring direct knowledge or control on the part of the user.

This page (revision-9) was last changed on 04-Nov-08 15:20 PM, -0800 by AndiEgloff.
This page was created on 06-Jun-08 06:41 AM, -0700 by KeithBabo.

More info...