All communications through binding component?
Is it the intent of the JBI spec to have all communications go through the binding components? Unlike the EJB spec, there doesn't seem to be any restrictions on what a service engine can do. In some cases, I've been doing some communication from a service engine. For example:
message --> BC --> SE --> EJB
Is this cheating or should I be doing:
message --> BC --> SE --> BC --> EJB
In cases where the communication to a resource is a 1-to-1 relationship with a single service engine, I see no problem with allowing the service engine to talk directly to the resource (and without the XML conversion overhead). However, I don't want to develop components in this way if the spec is going to "outlaw" socket communications (and a container may pull those packages from its component classloader to enforce this).
Thoughts?
Is clustering and/or distributed components/NMR/threads going to be addressed by the JBI spec at all?
-tim
[1001 byte] By [
tdrurya] at [2007-10-2 19:45:45]
That's not cheating at all. All JBI components can function as service providers and consumers; binding components aren't anything special. BCs function as proxies for remote service consumers or providers.
The GlassFish app server is a good example of your first example. It provides a service engine that contains its EJB and servlet containers. Invoking a service provided by an EJB is accomplished simply by invoking a service from the GlassFish service engine.
Similarly, service engines can consume services from other service engines directly:
SE1 --> SE2
and binding components can consume services provided by other binding components (protocol hopping):
message --> BC1 --> BC2 --> ext provider.
Tim,
Your second topic, clustering and distribution, are possible topics for the JBI 2.0 specification. JBI 1.0 has left this open right now for implementations to experiment with. Open ESB (and some other open-source JBI implementations) shows how JBI 1.0 can be leveraged to create a distributed system (an ESB).
-Ron
