You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Stefan Freyr Stefansson <st...@hugsmidjan.is> on 2006/01/03 11:55:03 UTC
Feasibility of using ServiceMix
Hello.
Related to your current discussion about how ServiceMix is _being_ used, I
have a question about _whether_ SM is an applicable choice for my situation.
The current environment:
Currently we have web based clients making HTTP calls to a central server. The
HTTP is just transport of course and it is not transporting HTML, rather it
is transporting JSON-RPC strings. For those who don't know, JSON stands for
JavaScript Object Notation and is simply put an RPC protocol minus XML (so
it's a bit more lightweight). This is not at all unlike AJAX (except of
course there's no XML). On the server side, a servlet is managing the clients
by binding a a JSON "bridge" with a "plain old java object" (POJO). So all
the JSON calls the clients make are being translated into method calls on a
POJO that again does something to fulfil the request (some methods are local
DB lookups while other methods are a webservice call).
The questions:
Before going much further, I'd like to know if this is something that we could
(at least in theory and maybe even in practice if anyone can imagine) use
ServiceMix for? What we've been pondering is to create a JBI plugin that
could handle the JSON protocol, somehow converting it to SOAP and putting on
the NMR (I at least seem to recall that the messages on the NMR have to be in
SOAP form... am I right there or is that a misconception?). In this case,
there would probably still be a servlet receiving the HTTP requests from
clients but that servlet would pass the request over to ServiceMix where the
JBI plugin would pick it up and decide what to do with it.
If we were to create such a JBI plugin, what restrictions would that impose
upon us? What I mean is, the current implementation does only what needs to
be done and no more. For example, if a local DB lookup is needed there is no
need to convert anything to SOAP and therefore it's simply not done. If we
were to create a JBI plugin one might think that the plugin had to convert
everything it receives to a SOAP message and put it on the NMR? What I'd like
to know is if there is anything stopping me from making my JBI plugin
configurable so that I can instruct it to delegate the JSON RPC it receives
to a local class without converting anything to SOAP in certain cases but
when it receives some other form of messages (a call to some specified
methods or something of the kind) it should do its standard SOAP conversion
and throw the message on the bus?
I hope I'm making myself understood here and I hope someone on this list has
some insight into this.
Kind regards, Stefan Freyr.
Re: Feasibility of using ServiceMix
Posted by Guillaume Nodet <gu...@worldonline.fr>.
Stefan Freyr Stefansson wrote:
>Thanks for the reply Guillaume.
>
>As expected this clears up some misconceptions I've had about ServiceMix but
>at the same time raises other questions. I hope you'll forgive my ignorance.
>
>So if we set up a hypothetical situation:
>A JSON RPC message is sent via HTTP from a client to a server.
>
>1) If I understand it correctly, a Binding Component would be responsible for
>communication. Does that mean that I should implement my own HTTP binding
>component? Does one exist already? Should I implement a binding component
>that somehow integrates into a running Tomcat instance to provide HTTP
>communication and session management? Could the binding component even be a
>servlet in itself? The thing is that currently the clients just make one call
>to begin with to identify themselves. The rest of the calls they make doesn't
>include any sort of authentication other than the HTTP session authentication
>and the servlet looks up their identity from their session if needed. This
>would be a major pain to have to implement ourselves.
>
>
If you are inside a web app, you should configure one container that
would delegate to the binding component.
Take a look at
http://svn.servicemix.codehaus.org/trunk/tooling/servicemix-web/ to see
how this can be done.
It uses the http component in servicemix-components.
You will need to inherit or rewrite a specific binding component that
will be able to handle a HttpServletRequest
with JSON RPC inside.
>2) The "server API", that is, the methods that will be available for the
>JSON-RPC clients are well defined. Right now, this API consists of one POJO
>with quite a few methods but we're in the process of defining these methods
>as eight distinct WSDL documents. As I've said we'll probably have to keep
>the JSON-RPC way of calling the methods on the POJO but instead of that POJO
>actually implementing these methods we will use something that will be
>defined by those WSDL documents. So the JSON-RPC receiving class will just
>delegate the methods to an operation defined in one of the eight different
>WSDLs. According to what I've read, the services provided by JBI components
>are described using WSDL. Does that mean that we could define eight different
>JBI components each "implementing" one of the WSDLs and drop them into the SM
>bus? In that case we would probably want the JSON-RPC receiver class to be a
>JBI component as well in some way as is described in point 1) above.
>
>
I do not follow. If the binding component has already transformed the
JSON-RPC to xml, in what
way are your 8 components tied to JSON-RPC ?
Btw, there is a common misconception about jbi betweem a component and
an endpoint.
A component may support service unit deployments and each service unit
may activate several endpoints.
Each endpoint may have a wsdl description.
If your pojos are not tied to json-rpc, you may want to reuse existing
stuff to write them or host them.
>One other thing that bothers me is what you said about the message format
>having to be XML. JSON strings are not XML so I'm wondering what would be the
>best way to "cheat" on that. Converting it to some "standard" XML format like
>SOAP is probably the _right_ thing to do but another idea would be to simply
>put a single root tag at the start and the corresponding end tag at the end
>of the string. I realize this is cheating a bit but could someone explain to
>me the reason why the messages in the NMR have to be XML? I mean, if any XML
>is legal then I can't imagine the NMR itself doing any processing on it
>because it couldn't possibly know what type of XML it should expect for any
>given message. The Service Components will know the format of the message but
>why would they really need it to be XML? My JSON-RPC service component could
>just as well parse a JSON string as some sort of an XML structure? I know I'm
>misunderstanding something here, I just don't know what it is.
>
>Again, any thoughts and comments would be greatly appreciated here.
>
>Kind regards, Stefan Freyr.
>
>
First, soap does not defines the message content. It is up to the
developer to create the xml schema / wsdl
which will specify it. Everything defined in soap will be mapped in the
jbi NormalizedMessage (attachments, headers, etc..).
The main point in using a jbi bus like ServiceMix is to be able to add
processing like content routing, transformation, access to other protocols
via binding components, reusing existing services, BPEL etc... If you
want all these components to be able to work together, you have to use a
common language : this is xml. But the content can not be specified
further : JBI is not geared to rpc calls, but rather document oriented
calls.
Looking at your first mail again, it seems that you have already
something working.
ServiceMix will be usefull if you plan to do some routing /
transformation or call external services for example.
Do you have such needs ? If yes, you will easily understand that you
will want to communicate with other services so that xml will become
necessary.
Else, i'm not sure ServiceMix will help you here ...
Guillaume Nodet
>
>On Tuesday 03 January 2006 11:09, Guillaume Nodet wrote:
>
>
>>JBI does in no way mandate SOAP.
>>All messages uses the NormalizedMessage class,
>>in which the content is a trax Source. This means that it must
>>be xml. However there are also attachments and properties.
>>
>>So SOAP should not be sent in the nmr, unless specific needs.
>>It should be up to the binding component to convert the soap request
>>to the jbi NormalizedMessage, removing the soap envelope.
>>Headers should be put in properties on the message, and the content should
>>be the soap body.
>>
>>There is no problem using any standard you want, provided that you can
>>translate
>>incoming / outcoming messages to / from the NormalizedMessage.
>>
>>In ServiceMix, there is no concept of "plugin". I guess you mean
>>"component".
>>The jbi api to write a component is not huge, and if you use classes
>>that are
>>defined in ServiceMix, it becomes really simple. But the main point is
>>that a component
>>can do whatever he wants : it uses the jbi api to receive messages,
>>process them, and send them
>>back (in case of a service engine). For binding components, they should
>>receive external messages,
>>transform them in a MessageExchange and send them to the NMR (or the
>>reverse).
>>But you can really do whatever you want ...
>>
>>Guillaume Nodet
>>
>>Stefan Freyr Stefansson wrote:
>>
>>
>>>Hello.
>>>
>>>Related to your current discussion about how ServiceMix is _being_ used, I
>>>have a question about _whether_ SM is an applicable choice for my
>>>situation.
>>>
>>>The current environment:
>>>Currently we have web based clients making HTTP calls to a central server.
>>>The HTTP is just transport of course and it is not transporting HTML,
>>>rather it is transporting JSON-RPC strings. For those who don't know,
>>>JSON stands for JavaScript Object Notation and is simply put an RPC
>>>protocol minus XML (so it's a bit more lightweight). This is not at all
>>>unlike AJAX (except of course there's no XML). On the server side, a
>>>servlet is managing the clients by binding a a JSON "bridge" with a
>>>"plain old java object" (POJO). So all the JSON calls the clients make
>>>are being translated into method calls on a POJO that again does
>>>something to fulfil the request (some methods are local DB lookups while
>>>other methods are a webservice call).
>>>
>>>The questions:
>>>Before going much further, I'd like to know if this is something that we
>>>could (at least in theory and maybe even in practice if anyone can
>>>imagine) use ServiceMix for? What we've been pondering is to create a JBI
>>>plugin that could handle the JSON protocol, somehow converting it to SOAP
>>>and putting on the NMR (I at least seem to recall that the messages on
>>>the NMR have to be in SOAP form... am I right there or is that a
>>>misconception?). In this case, there would probably still be a servlet
>>>receiving the HTTP requests from clients but that servlet would pass the
>>>request over to ServiceMix where the JBI plugin would pick it up and
>>>decide what to do with it.
>>>
>>>If we were to create such a JBI plugin, what restrictions would that
>>>impose upon us? What I mean is, the current implementation does only what
>>>needs to be done and no more. For example, if a local DB lookup is needed
>>>there is no need to convert anything to SOAP and therefore it's simply
>>>not done. If we were to create a JBI plugin one might think that the
>>>plugin had to convert everything it receives to a SOAP message and put it
>>>on the NMR? What I'd like to know is if there is anything stopping me
>>>from making my JBI plugin configurable so that I can instruct it to
>>>delegate the JSON RPC it receives to a local class without converting
>>>anything to SOAP in certain cases but when it receives some other form of
>>>messages (a call to some specified methods or something of the kind) it
>>>should do its standard SOAP conversion and throw the message on the bus?
>>>
>>>I hope I'm making myself understood here and I hope someone on this list
>>>has some insight into this.
>>>
>>>Kind regards, Stefan Freyr.
>>>
>>>
Re: Feasibility of using ServiceMix
Posted by Stefan Freyr Stefansson <st...@hugsmidjan.is>.
Thanks for the reply Guillaume.
As expected this clears up some misconceptions I've had about ServiceMix but
at the same time raises other questions. I hope you'll forgive my ignorance.
So if we set up a hypothetical situation:
A JSON RPC message is sent via HTTP from a client to a server.
1) If I understand it correctly, a Binding Component would be responsible for
communication. Does that mean that I should implement my own HTTP binding
component? Does one exist already? Should I implement a binding component
that somehow integrates into a running Tomcat instance to provide HTTP
communication and session management? Could the binding component even be a
servlet in itself? The thing is that currently the clients just make one call
to begin with to identify themselves. The rest of the calls they make doesn't
include any sort of authentication other than the HTTP session authentication
and the servlet looks up their identity from their session if needed. This
would be a major pain to have to implement ourselves.
2) The "server API", that is, the methods that will be available for the
JSON-RPC clients are well defined. Right now, this API consists of one POJO
with quite a few methods but we're in the process of defining these methods
as eight distinct WSDL documents. As I've said we'll probably have to keep
the JSON-RPC way of calling the methods on the POJO but instead of that POJO
actually implementing these methods we will use something that will be
defined by those WSDL documents. So the JSON-RPC receiving class will just
delegate the methods to an operation defined in one of the eight different
WSDLs. According to what I've read, the services provided by JBI components
are described using WSDL. Does that mean that we could define eight different
JBI components each "implementing" one of the WSDLs and drop them into the SM
bus? In that case we would probably want the JSON-RPC receiver class to be a
JBI component as well in some way as is described in point 1) above.
One other thing that bothers me is what you said about the message format
having to be XML. JSON strings are not XML so I'm wondering what would be the
best way to "cheat" on that. Converting it to some "standard" XML format like
SOAP is probably the _right_ thing to do but another idea would be to simply
put a single root tag at the start and the corresponding end tag at the end
of the string. I realize this is cheating a bit but could someone explain to
me the reason why the messages in the NMR have to be XML? I mean, if any XML
is legal then I can't imagine the NMR itself doing any processing on it
because it couldn't possibly know what type of XML it should expect for any
given message. The Service Components will know the format of the message but
why would they really need it to be XML? My JSON-RPC service component could
just as well parse a JSON string as some sort of an XML structure? I know I'm
misunderstanding something here, I just don't know what it is.
Again, any thoughts and comments would be greatly appreciated here.
Kind regards, Stefan Freyr.
On Tuesday 03 January 2006 11:09, Guillaume Nodet wrote:
> JBI does in no way mandate SOAP.
> All messages uses the NormalizedMessage class,
> in which the content is a trax Source. This means that it must
> be xml. However there are also attachments and properties.
>
> So SOAP should not be sent in the nmr, unless specific needs.
> It should be up to the binding component to convert the soap request
> to the jbi NormalizedMessage, removing the soap envelope.
> Headers should be put in properties on the message, and the content should
> be the soap body.
>
> There is no problem using any standard you want, provided that you can
> translate
> incoming / outcoming messages to / from the NormalizedMessage.
>
> In ServiceMix, there is no concept of "plugin". I guess you mean
> "component".
> The jbi api to write a component is not huge, and if you use classes
> that are
> defined in ServiceMix, it becomes really simple. But the main point is
> that a component
> can do whatever he wants : it uses the jbi api to receive messages,
> process them, and send them
> back (in case of a service engine). For binding components, they should
> receive external messages,
> transform them in a MessageExchange and send them to the NMR (or the
> reverse).
> But you can really do whatever you want ...
>
> Guillaume Nodet
>
> Stefan Freyr Stefansson wrote:
> >Hello.
> >
> >Related to your current discussion about how ServiceMix is _being_ used, I
> >have a question about _whether_ SM is an applicable choice for my
> > situation.
> >
> >The current environment:
> >Currently we have web based clients making HTTP calls to a central server.
> > The HTTP is just transport of course and it is not transporting HTML,
> > rather it is transporting JSON-RPC strings. For those who don't know,
> > JSON stands for JavaScript Object Notation and is simply put an RPC
> > protocol minus XML (so it's a bit more lightweight). This is not at all
> > unlike AJAX (except of course there's no XML). On the server side, a
> > servlet is managing the clients by binding a a JSON "bridge" with a
> > "plain old java object" (POJO). So all the JSON calls the clients make
> > are being translated into method calls on a POJO that again does
> > something to fulfil the request (some methods are local DB lookups while
> > other methods are a webservice call).
> >
> >The questions:
> >Before going much further, I'd like to know if this is something that we
> > could (at least in theory and maybe even in practice if anyone can
> > imagine) use ServiceMix for? What we've been pondering is to create a JBI
> > plugin that could handle the JSON protocol, somehow converting it to SOAP
> > and putting on the NMR (I at least seem to recall that the messages on
> > the NMR have to be in SOAP form... am I right there or is that a
> > misconception?). In this case, there would probably still be a servlet
> > receiving the HTTP requests from clients but that servlet would pass the
> > request over to ServiceMix where the JBI plugin would pick it up and
> > decide what to do with it.
> >
> >If we were to create such a JBI plugin, what restrictions would that
> > impose upon us? What I mean is, the current implementation does only what
> > needs to be done and no more. For example, if a local DB lookup is needed
> > there is no need to convert anything to SOAP and therefore it's simply
> > not done. If we were to create a JBI plugin one might think that the
> > plugin had to convert everything it receives to a SOAP message and put it
> > on the NMR? What I'd like to know is if there is anything stopping me
> > from making my JBI plugin configurable so that I can instruct it to
> > delegate the JSON RPC it receives to a local class without converting
> > anything to SOAP in certain cases but when it receives some other form of
> > messages (a call to some specified methods or something of the kind) it
> > should do its standard SOAP conversion and throw the message on the bus?
> >
> >I hope I'm making myself understood here and I hope someone on this list
> > has some insight into this.
> >
> >Kind regards, Stefan Freyr.
Re: Feasibility of using ServiceMix
Posted by Guillaume Nodet <gu...@worldonline.fr>.
JBI does in no way mandate SOAP.
All messages uses the NormalizedMessage class,
in which the content is a trax Source. This means that it must
be xml. However there are also attachments and properties.
So SOAP should not be sent in the nmr, unless specific needs.
It should be up to the binding component to convert the soap request
to the jbi NormalizedMessage, removing the soap envelope.
Headers should be put in properties on the message, and the content should
be the soap body.
There is no problem using any standard you want, provided that you can
translate
incoming / outcoming messages to / from the NormalizedMessage.
In ServiceMix, there is no concept of "plugin". I guess you mean
"component".
The jbi api to write a component is not huge, and if you use classes
that are
defined in ServiceMix, it becomes really simple. But the main point is
that a component
can do whatever he wants : it uses the jbi api to receive messages,
process them, and send them
back (in case of a service engine). For binding components, they should
receive external messages,
transform them in a MessageExchange and send them to the NMR (or the
reverse).
But you can really do whatever you want ...
Guillaume Nodet
Stefan Freyr Stefansson wrote:
>Hello.
>
>Related to your current discussion about how ServiceMix is _being_ used, I
>have a question about _whether_ SM is an applicable choice for my situation.
>
>The current environment:
>Currently we have web based clients making HTTP calls to a central server. The
>HTTP is just transport of course and it is not transporting HTML, rather it
>is transporting JSON-RPC strings. For those who don't know, JSON stands for
>JavaScript Object Notation and is simply put an RPC protocol minus XML (so
>it's a bit more lightweight). This is not at all unlike AJAX (except of
>course there's no XML). On the server side, a servlet is managing the clients
>by binding a a JSON "bridge" with a "plain old java object" (POJO). So all
>the JSON calls the clients make are being translated into method calls on a
>POJO that again does something to fulfil the request (some methods are local
>DB lookups while other methods are a webservice call).
>
>The questions:
>Before going much further, I'd like to know if this is something that we could
>(at least in theory and maybe even in practice if anyone can imagine) use
>ServiceMix for? What we've been pondering is to create a JBI plugin that
>could handle the JSON protocol, somehow converting it to SOAP and putting on
>the NMR (I at least seem to recall that the messages on the NMR have to be in
>SOAP form... am I right there or is that a misconception?). In this case,
>there would probably still be a servlet receiving the HTTP requests from
>clients but that servlet would pass the request over to ServiceMix where the
>JBI plugin would pick it up and decide what to do with it.
>
>If we were to create such a JBI plugin, what restrictions would that impose
>upon us? What I mean is, the current implementation does only what needs to
>be done and no more. For example, if a local DB lookup is needed there is no
>need to convert anything to SOAP and therefore it's simply not done. If we
>were to create a JBI plugin one might think that the plugin had to convert
>everything it receives to a SOAP message and put it on the NMR? What I'd like
>to know is if there is anything stopping me from making my JBI plugin
>configurable so that I can instruct it to delegate the JSON RPC it receives
>to a local class without converting anything to SOAP in certain cases but
>when it receives some other form of messages (a call to some specified
>methods or something of the kind) it should do its standard SOAP conversion
>and throw the message on the bus?
>
>I hope I'm making myself understood here and I hope someone on this list has
>some insight into this.
>
>Kind regards, Stefan Freyr.
>
>
Re: Feasibility of using ServiceMix
Posted by Stefan Freyr Stefansson <st...@hugsmidjan.is>.
Hello Roland and thanks for your reply.
I did look at Mule some time ago but I liked the philosophy of ServiceMix
better, to be completely JBI compliant.
I must admit though that I didn't quite get the difference since Mule does
offer some JBI "gateway" or something so you could definately say that my
decision was taken in the dark.
After taking a look at the links, the only thing I can see that may imply that
my decision was wrong would be that Mule seems to be more mature and it seems
to have better documentation. A logical assumption would be that the
community behind it might be more active (the mailing lists specifically) but
so far I can't complain about the responses I've been getting here ;o)
Kind regards, Stefan Freyr.
On Tuesday 03 January 2006 12:26, Roland Oertig wrote:
> Hi Stefan
>
> You may wish to also have a look at this http://mule.codehaus.org/ and
> http://mule.codehaus.org/Mule+JBI+Examples
> Eventually:
> http://www.theserverside.com/news/thread.tss?thread_id=33372
> http://www.theserverside.com/news/thread.tss?thread_id=35996
> http://servicemix.org/How+does+ServiceMix+compare+to+Mule
>
>
> It's also an approach to implement a "bridge", means service bus.
> Cheers
> Roland
>
>
> -----Original Message-----
> From: Stefan Freyr Stefansson [mailto:stfs@hugsmidjan.is]
> Sent: Dienstag, 3. Januar 2006 11:55
> To: servicemix-users@geronimo.apache.org
> Subject: Feasibility of using ServiceMix
>
> Hello.
>
> Related to your current discussion about how ServiceMix is _being_ used, I
> have a question about _whether_ SM is an applicable choice for my
> situation.
>
> The current environment:
> Currently we have web based clients making HTTP calls to a central server.
> The
> HTTP is just transport of course and it is not transporting HTML, rather it
> is transporting JSON-RPC strings. For those who don't know, JSON stands for
> JavaScript Object Notation and is simply put an RPC protocol minus XML (so
> it's a bit more lightweight). This is not at all unlike AJAX (except of
> course there's no XML). On the server side, a servlet is managing the
> clients
> by binding a a JSON "bridge" with a "plain old java object" (POJO). So all
> the JSON calls the clients make are being translated into method calls on a
> POJO that again does something to fulfil the request (some methods are
> local
>
> DB lookups while other methods are a webservice call).
>
> The questions:
> Before going much further, I'd like to know if this is something that we
> could
> (at least in theory and maybe even in practice if anyone can imagine) use
> ServiceMix for? What we've been pondering is to create a JBI plugin that
> could handle the JSON protocol, somehow converting it to SOAP and putting
> on
>
> the NMR (I at least seem to recall that the messages on the NMR have to be
> in
> SOAP form... am I right there or is that a misconception?). In this case,
> there would probably still be a servlet receiving the HTTP requests from
> clients but that servlet would pass the request over to ServiceMix where
> the
>
> JBI plugin would pick it up and decide what to do with it.
>
> If we were to create such a JBI plugin, what restrictions would that impose
> upon us? What I mean is, the current implementation does only what needs to
> be done and no more. For example, if a local DB lookup is needed there is
> no
>
> need to convert anything to SOAP and therefore it's simply not done. If we
> were to create a JBI plugin one might think that the plugin had to convert
> everything it receives to a SOAP message and put it on the NMR? What I'd
> like
> to know is if there is anything stopping me from making my JBI plugin
> configurable so that I can instruct it to delegate the JSON RPC it receives
> to a local class without converting anything to SOAP in certain cases but
> when it receives some other form of messages (a call to some specified
> methods or something of the kind) it should do its standard SOAP conversion
> and throw the message on the bus?
>
> I hope I'm making myself understood here and I hope someone on this list
> has
>
> some insight into this.
>
> Kind regards, Stefan Freyr.
RE: Feasibility of using ServiceMix
Posted by Roland Oertig <ro...@dplanet.ch>.
Hi Stefan
You may wish to also have a look at this http://mule.codehaus.org/ and
http://mule.codehaus.org/Mule+JBI+Examples
Eventually:
http://www.theserverside.com/news/thread.tss?thread_id=33372
http://www.theserverside.com/news/thread.tss?thread_id=35996
http://servicemix.org/How+does+ServiceMix+compare+to+Mule
It's also an approach to implement a "bridge", means service bus.
Cheers
Roland
-----Original Message-----
From: Stefan Freyr Stefansson [mailto:stfs@hugsmidjan.is]
Sent: Dienstag, 3. Januar 2006 11:55
To: servicemix-users@geronimo.apache.org
Subject: Feasibility of using ServiceMix
Hello.
Related to your current discussion about how ServiceMix is _being_ used, I
have a question about _whether_ SM is an applicable choice for my situation.
The current environment:
Currently we have web based clients making HTTP calls to a central server.
The
HTTP is just transport of course and it is not transporting HTML, rather it
is transporting JSON-RPC strings. For those who don't know, JSON stands for
JavaScript Object Notation and is simply put an RPC protocol minus XML (so
it's a bit more lightweight). This is not at all unlike AJAX (except of
course there's no XML). On the server side, a servlet is managing the
clients
by binding a a JSON "bridge" with a "plain old java object" (POJO). So all
the JSON calls the clients make are being translated into method calls on a
POJO that again does something to fulfil the request (some methods are local
DB lookups while other methods are a webservice call).
The questions:
Before going much further, I'd like to know if this is something that we
could
(at least in theory and maybe even in practice if anyone can imagine) use
ServiceMix for? What we've been pondering is to create a JBI plugin that
could handle the JSON protocol, somehow converting it to SOAP and putting on
the NMR (I at least seem to recall that the messages on the NMR have to be
in
SOAP form... am I right there or is that a misconception?). In this case,
there would probably still be a servlet receiving the HTTP requests from
clients but that servlet would pass the request over to ServiceMix where the
JBI plugin would pick it up and decide what to do with it.
If we were to create such a JBI plugin, what restrictions would that impose
upon us? What I mean is, the current implementation does only what needs to
be done and no more. For example, if a local DB lookup is needed there is no
need to convert anything to SOAP and therefore it's simply not done. If we
were to create a JBI plugin one might think that the plugin had to convert
everything it receives to a SOAP message and put it on the NMR? What I'd
like
to know is if there is anything stopping me from making my JBI plugin
configurable so that I can instruct it to delegate the JSON RPC it receives
to a local class without converting anything to SOAP in certain cases but
when it receives some other form of messages (a call to some specified
methods or something of the kind) it should do its standard SOAP conversion
and throw the message on the bus?
I hope I'm making myself understood here and I hope someone on this list has
some insight into this.
Kind regards, Stefan Freyr.