You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Ryan Moquin <fr...@gmail.com> on 2007/08/29 02:41:45 UTC
JSR181 interservice communication
I'm sorry if there is something really obvious somewhere about how this is
done, but I was wondering if someone can tell me or point me to where I can
find out how to make two JSR181 services in servicemix talk to each other.
I would just have one call the other as if they weren't hooked to the NMR,
but I'm assuming that's not the most efficient and that there is a better
way. I saw some various pieces of code that sound kind of like what I want,
but since I'm a bit new still to how to interact with Servicemix (other than
deploy to and call a service externally) so I'm a little bit unsure of what
I need to do. Can anyone point me in the right direction?
Thanks!
Ryan
Re: JSR181 interservice communication
Posted by Ryan Moquin <fr...@gmail.com>.
I have my service classes created, since I'm already using them
individually.. I was talking about the proxy class it mentions in the docs.
I found a message with a google search that does this a slightly different
way than the user's guide and I seem be having a bit more luck with that
since it is setting a proxy on my service, it seems like it couldn't find
the service since it says for the alert property being set using my
debugger:
XFireProxy[null]
I did try to invoke the service it is able to. What was in the user guide
didn't work, but this seems to work:
<jsr181:endpoint wsdlResource="classpath:WaterGaugeService.wsdl"
style="document">
<jsr181:pojo>
<bean class="
com.bae.gse.flare.service.watergauge.WaterGaugeServiceImpl">
<property name="context" ref="context" />
</bean>
</jsr181:pojo>
</jsr181:endpoint>
<bean id="waterGaugeBean" class="
com.bae.gse.flare.service.watergauge.WaterGaugeServiceImpl">
<property name="alert">
<jsr181:proxy service="alertservice:AlertService"
context="#context"
type="com.bae.gse.flare.alertservice.AlertServicePort"
/>
</property>
</bean>
On 8/29/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> Classes are not generated on the fly.
> They are generated by wsdl2java, which is usually configured
> in a maven plugin in your pom.
> You need to generate the classes for your two services if you want
> to use both inside the SU.
>
> On Aug 29, 2007, at 4:14 PM, Ryan Moquin wrote:
>
> > Hate to keep bugging you, but I have to be doing something wrong.
> > I looked
> > up in the docs, the JSR181 proxy element. I tried to set it up in my
> > xbean.xml, in the service unit for my WaterGaugeService which wants
> > to use
> > my AlertService. In my xbean.xml for my WaterGaugeService, I
> > defined the
> > namespace that is in my AlertService SU, then added a proxy
> > configuration.
> > I also added a property to my WaterGaugeService using the interface
> > for the
> > AlertService. When I run my maven build, I get this error:
> >
> > [ERROR] BUILD ERROR
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] Failed to generate jbi.xml
> >
> > Embedded error: Unable to generate service unit descriptor!
> > com.bae.gse.flare.service.alert.AlertServiceProxy
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> >
> > Doesn't the Proxy class get generated on the fly? Or do I need to
> > create
> > it?
> >
> > Here is how I configured my xbean.xml (the relevant snippet):
> >
> > <jsr181:endpoint pojoClass="
> > com.bae.gse.flare.service.watergauge.WaterGaugeServiceImpl"
> > wsdlResource="classpath:WaterGaugeService.wsdl"
> > style="document" />
> >
> > <jsr181:endpoint serviceInterface="
> > com.bae.gse.flare.alertservice.AlertServicePort">
> > <jsr181:pojo>
> > <bean class="com.bae.gse.flare.service.alert.AlertServiceProxy">
> > <property name="alert">
> > <jsr181:proxy service="alertservice:AlertService"
> > context="#context"
> > type="com.bae.gse.flare.alertservice.AlertServicePort" />
> > </property>
> > </bean>
> > </jsr181:pojo>
> > </jsr181:endpoint>
> >
> >
> > On 8/29/07, Ryan Moquin <fr...@gmail.com> wrote:
> >>
> >> While I'm thinking about it, is there any reason for going through
> >> the NMR
> >> vs. just using the bean directly? Is it only to be loosely
> >> coupled or are
> >> there any other advantages?
> >>
> >> On 8/29/07, Ryan Moquin <fr...@gmail.com> wrote:
> >>>
> >>> Ah, so that is different than what I thought I was supposed to
> >>> do. I'll
> >>> give it a try, thanks!!
> >>>
> >>> On 8/29/07, Nodet Guillaume < gnodet@gmail.com> wrote:
> >>>>
> >>>>
> >>>> Let's say you have two beans foo.bar.AImpl and foo.bar.BImpl that
> >>>> implement
> >>>> the foor.bar.A and foo.bar.B interfaces. Then you would have
> >>>>
> >>>> package foo.bar;
> >>>> @WebService(..)
> >>>> class AImpl implements A {
> >>>> private B b;
> >>>> public void setB(B b) {
> >>>> this.b = b;
> >>>> }
> >>>> ...
> >>>> }
> >>>>
> >>>> and you can wire together using the <jsr181:proxy /> if you want to
> >>>> go through
> >>>> the NMR and be independent of B location and implementation, or
> >>>> using
> >>>> spring
> >>>> just inject an instance of the second service into the first one:
> >>>>
> >>>> <bean id="a" class="foo.bar.AImpl">
> >>>> <property name="b" value-ref="b" />
> >>>> ..
> >>>> </bean>
> >>>>
> >>>> <bean id="b" class="foo.bar.BImpl">
> >>>> ...
> >>>> </bean>
> >>>>
> >>>> You can still expose those beans (one ore both) as jsr181 endpoints
> >>>> in the
> >>>> usual way...
> >>>>
> >>>> Cheers,
> >>>> Guillaume Nodet
> >>>>
> >>>> On Aug 29, 2007, at 2:41 AM, Ryan Moquin wrote:
> >>>>
> >>>>> I'm sorry if there is something really obvious somewhere about how
> >>>>> this is
> >>>>> done, but I was wondering if someone can tell me or point me to
> >>>>> where I can
> >>>>> find out how to make two JSR181 services in servicemix talk to
> >>>>> each
> >>>>> other.
> >>>>> I would just have one call the other as if they weren't hooked to
> >>>>> the NMR,
> >>>>> but I'm assuming that's not the most efficient and that there is a
> >>>>> better
> >>>>> way. I saw some various pieces of code that sound kind of like
> >>>>> what I want,
> >>>>> but since I'm a bit new still to how to interact with Servicemix
> >>>>> (other than
> >>>>> deploy to and call a service externally) so I'm a little bit
> >>>>> unsure
> >>>>> of what
> >>>>> I need to do. Can anyone point me in the right direction?
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Ryan
> >>>>
> >>>>
> >>>
> >>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
>
Re: JSR181 interservice communication
Posted by Nodet Guillaume <gn...@gmail.com>.
Classes are not generated on the fly.
They are generated by wsdl2java, which is usually configured
in a maven plugin in your pom.
You need to generate the classes for your two services if you want
to use both inside the SU.
On Aug 29, 2007, at 4:14 PM, Ryan Moquin wrote:
> Hate to keep bugging you, but I have to be doing something wrong.
> I looked
> up in the docs, the JSR181 proxy element. I tried to set it up in my
> xbean.xml, in the service unit for my WaterGaugeService which wants
> to use
> my AlertService. In my xbean.xml for my WaterGaugeService, I
> defined the
> namespace that is in my AlertService SU, then added a proxy
> configuration.
> I also added a property to my WaterGaugeService using the interface
> for the
> AlertService. When I run my maven build, I get this error:
>
> [ERROR] BUILD ERROR
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] Failed to generate jbi.xml
>
> Embedded error: Unable to generate service unit descriptor!
> com.bae.gse.flare.service.alert.AlertServiceProxy
> [INFO]
> ----------------------------------------------------------------------
> --
>
> Doesn't the Proxy class get generated on the fly? Or do I need to
> create
> it?
>
> Here is how I configured my xbean.xml (the relevant snippet):
>
> <jsr181:endpoint pojoClass="
> com.bae.gse.flare.service.watergauge.WaterGaugeServiceImpl"
> wsdlResource="classpath:WaterGaugeService.wsdl"
> style="document" />
>
> <jsr181:endpoint serviceInterface="
> com.bae.gse.flare.alertservice.AlertServicePort">
> <jsr181:pojo>
> <bean class="com.bae.gse.flare.service.alert.AlertServiceProxy">
> <property name="alert">
> <jsr181:proxy service="alertservice:AlertService"
> context="#context"
> type="com.bae.gse.flare.alertservice.AlertServicePort" />
> </property>
> </bean>
> </jsr181:pojo>
> </jsr181:endpoint>
>
>
> On 8/29/07, Ryan Moquin <fr...@gmail.com> wrote:
>>
>> While I'm thinking about it, is there any reason for going through
>> the NMR
>> vs. just using the bean directly? Is it only to be loosely
>> coupled or are
>> there any other advantages?
>>
>> On 8/29/07, Ryan Moquin <fr...@gmail.com> wrote:
>>>
>>> Ah, so that is different than what I thought I was supposed to
>>> do. I'll
>>> give it a try, thanks!!
>>>
>>> On 8/29/07, Nodet Guillaume < gnodet@gmail.com> wrote:
>>>>
>>>>
>>>> Let's say you have two beans foo.bar.AImpl and foo.bar.BImpl that
>>>> implement
>>>> the foor.bar.A and foo.bar.B interfaces. Then you would have
>>>>
>>>> package foo.bar;
>>>> @WebService(..)
>>>> class AImpl implements A {
>>>> private B b;
>>>> public void setB(B b) {
>>>> this.b = b;
>>>> }
>>>> ...
>>>> }
>>>>
>>>> and you can wire together using the <jsr181:proxy /> if you want to
>>>> go through
>>>> the NMR and be independent of B location and implementation, or
>>>> using
>>>> spring
>>>> just inject an instance of the second service into the first one:
>>>>
>>>> <bean id="a" class="foo.bar.AImpl">
>>>> <property name="b" value-ref="b" />
>>>> ..
>>>> </bean>
>>>>
>>>> <bean id="b" class="foo.bar.BImpl">
>>>> ...
>>>> </bean>
>>>>
>>>> You can still expose those beans (one ore both) as jsr181 endpoints
>>>> in the
>>>> usual way...
>>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>> On Aug 29, 2007, at 2:41 AM, Ryan Moquin wrote:
>>>>
>>>>> I'm sorry if there is something really obvious somewhere about how
>>>>> this is
>>>>> done, but I was wondering if someone can tell me or point me to
>>>>> where I can
>>>>> find out how to make two JSR181 services in servicemix talk to
>>>>> each
>>>>> other.
>>>>> I would just have one call the other as if they weren't hooked to
>>>>> the NMR,
>>>>> but I'm assuming that's not the most efficient and that there is a
>>>>> better
>>>>> way. I saw some various pieces of code that sound kind of like
>>>>> what I want,
>>>>> but since I'm a bit new still to how to interact with Servicemix
>>>>> (other than
>>>>> deploy to and call a service externally) so I'm a little bit
>>>>> unsure
>>>>> of what
>>>>> I need to do. Can anyone point me in the right direction?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Ryan
>>>>
>>>>
>>>
>>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: JSR181 interservice communication
Posted by Ryan Moquin <fr...@gmail.com>.
Hate to keep bugging you, but I have to be doing something wrong. I looked
up in the docs, the JSR181 proxy element. I tried to set it up in my
xbean.xml, in the service unit for my WaterGaugeService which wants to use
my AlertService. In my xbean.xml for my WaterGaugeService, I defined the
namespace that is in my AlertService SU, then added a proxy configuration.
I also added a property to my WaterGaugeService using the interface for the
AlertService. When I run my maven build, I get this error:
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to generate jbi.xml
Embedded error: Unable to generate service unit descriptor!
com.bae.gse.flare.service.alert.AlertServiceProxy
[INFO]
------------------------------------------------------------------------
Doesn't the Proxy class get generated on the fly? Or do I need to create
it?
Here is how I configured my xbean.xml (the relevant snippet):
<jsr181:endpoint pojoClass="
com.bae.gse.flare.service.watergauge.WaterGaugeServiceImpl"
wsdlResource="classpath:WaterGaugeService.wsdl"
style="document" />
<jsr181:endpoint serviceInterface="
com.bae.gse.flare.alertservice.AlertServicePort">
<jsr181:pojo>
<bean class="com.bae.gse.flare.service.alert.AlertServiceProxy">
<property name="alert">
<jsr181:proxy service="alertservice:AlertService"
context="#context" type="com.bae.gse.flare.alertservice.AlertServicePort" />
</property>
</bean>
</jsr181:pojo>
</jsr181:endpoint>
On 8/29/07, Ryan Moquin <fr...@gmail.com> wrote:
>
> While I'm thinking about it, is there any reason for going through the NMR
> vs. just using the bean directly? Is it only to be loosely coupled or are
> there any other advantages?
>
> On 8/29/07, Ryan Moquin <fr...@gmail.com> wrote:
> >
> > Ah, so that is different than what I thought I was supposed to do. I'll
> > give it a try, thanks!!
> >
> > On 8/29/07, Nodet Guillaume < gnodet@gmail.com> wrote:
> > >
> > >
> > > Let's say you have two beans foo.bar.AImpl and foo.bar.BImpl that
> > > implement
> > > the foor.bar.A and foo.bar.B interfaces. Then you would have
> > >
> > > package foo.bar;
> > > @WebService(..)
> > > class AImpl implements A {
> > > private B b;
> > > public void setB(B b) {
> > > this.b = b;
> > > }
> > > ...
> > > }
> > >
> > > and you can wire together using the <jsr181:proxy /> if you want to
> > > go through
> > > the NMR and be independent of B location and implementation, or using
> > > spring
> > > just inject an instance of the second service into the first one:
> > >
> > > <bean id="a" class="foo.bar.AImpl">
> > > <property name="b" value-ref="b" />
> > > ..
> > > </bean>
> > >
> > > <bean id="b" class="foo.bar.BImpl">
> > > ...
> > > </bean>
> > >
> > > You can still expose those beans (one ore both) as jsr181 endpoints
> > > in the
> > > usual way...
> > >
> > > Cheers,
> > > Guillaume Nodet
> > >
> > > On Aug 29, 2007, at 2:41 AM, Ryan Moquin wrote:
> > >
> > > > I'm sorry if there is something really obvious somewhere about how
> > > > this is
> > > > done, but I was wondering if someone can tell me or point me to
> > > > where I can
> > > > find out how to make two JSR181 services in servicemix talk to each
> > > > other.
> > > > I would just have one call the other as if they weren't hooked to
> > > > the NMR,
> > > > but I'm assuming that's not the most efficient and that there is a
> > > > better
> > > > way. I saw some various pieces of code that sound kind of like
> > > > what I want,
> > > > but since I'm a bit new still to how to interact with Servicemix
> > > > (other than
> > > > deploy to and call a service externally) so I'm a little bit unsure
> > > > of what
> > > > I need to do. Can anyone point me in the right direction?
> > > >
> > > > Thanks!
> > > >
> > > > Ryan
> > >
> > >
> >
>
Re: JSR181 interservice communication
Posted by Ryan Moquin <fr...@gmail.com>.
Ah, gotcha. So performance is the reason you'd do it.
Thanks!
On 9/4/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> Mainly if you really need performances over flexibility.
> If you inject a direct reference, there will be no marshalling and
> unmarshalling.
>
> On Aug 31, 2007, at 2:59 PM, Ryan Moquin wrote:
>
> > I'm referring to Nodet's response to my original question:
> >
> > "or using
> > spring
> > just inject an instance of the second service into the first one:"
> >
> > I was just wondering why one would want to do this, when they have
> > the other
> > option available.
> >
> > On 8/31/07, Bruce Snyder <br...@gmail.com> wrote:
> >>
> >> On 8/30/07, Ryan Moquin <fr...@gmail.com> wrote:
> >>> That's why I was surprised about the option to inject a bean
> >>> directly...
> >> it
> >>> almost sounds like going through the NMR would be worthless in that
> >>> respect. So it's just another option if you didn't care to take
> >> advantage
> >>> of the functionality the NMR provides.
> >>
> >> I"m not sure what you mean by 'the option to inject a bean directly'
> >> if you don't want to take advantage of the functionality the NMR
> >> provides? I'm not understanding this statement at all, please
> >> clarify.
> >>
> >> Bruce
> >> --
> >> perl -e 'print
> >> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> >> );'
> >>
> >> Apache ActiveMQ - http://activemq.org/
> >> Apache ServiceMix - http://servicemix.org/
> >> Apache Geronimo - http://geronimo.apache.org/
> >> Castor - http://castor.org/
> >>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
>
Re: JSR181 interservice communication
Posted by Nodet Guillaume <gn...@gmail.com>.
Mainly if you really need performances over flexibility.
If you inject a direct reference, there will be no marshalling and
unmarshalling.
On Aug 31, 2007, at 2:59 PM, Ryan Moquin wrote:
> I'm referring to Nodet's response to my original question:
>
> "or using
> spring
> just inject an instance of the second service into the first one:"
>
> I was just wondering why one would want to do this, when they have
> the other
> option available.
>
> On 8/31/07, Bruce Snyder <br...@gmail.com> wrote:
>>
>> On 8/30/07, Ryan Moquin <fr...@gmail.com> wrote:
>>> That's why I was surprised about the option to inject a bean
>>> directly...
>> it
>>> almost sounds like going through the NMR would be worthless in that
>>> respect. So it's just another option if you didn't care to take
>> advantage
>>> of the functionality the NMR provides.
>>
>> I"m not sure what you mean by 'the option to inject a bean directly'
>> if you don't want to take advantage of the functionality the NMR
>> provides? I'm not understanding this statement at all, please
>> clarify.
>>
>> Bruce
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>>
>> Apache ActiveMQ - http://activemq.org/
>> Apache ServiceMix - http://servicemix.org/
>> Apache Geronimo - http://geronimo.apache.org/
>> Castor - http://castor.org/
>>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: JSR181 interservice communication
Posted by Ryan Moquin <fr...@gmail.com>.
I'm referring to Nodet's response to my original question:
"or using
spring
just inject an instance of the second service into the first one:"
I was just wondering why one would want to do this, when they have the other
option available.
On 8/31/07, Bruce Snyder <br...@gmail.com> wrote:
>
> On 8/30/07, Ryan Moquin <fr...@gmail.com> wrote:
> > That's why I was surprised about the option to inject a bean directly...
> it
> > almost sounds like going through the NMR would be worthless in that
> > respect. So it's just another option if you didn't care to take
> advantage
> > of the functionality the NMR provides.
>
> I"m not sure what you mean by 'the option to inject a bean directly'
> if you don't want to take advantage of the functionality the NMR
> provides? I'm not understanding this statement at all, please clarify.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>
Re: JSR181 interservice communication
Posted by Bruce Snyder <br...@gmail.com>.
On 8/30/07, Ryan Moquin <fr...@gmail.com> wrote:
> That's why I was surprised about the option to inject a bean directly... it
> almost sounds like going through the NMR would be worthless in that
> respect. So it's just another option if you didn't care to take advantage
> of the functionality the NMR provides.
I"m not sure what you mean by 'the option to inject a bean directly'
if you don't want to take advantage of the functionality the NMR
provides? I'm not understanding this statement at all, please clarify.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: JSR181 interservice communication
Posted by Ryan Moquin <fr...@gmail.com>.
That's why I was surprised about the option to inject a bean directly... it
almost sounds like going through the NMR would be worthless in that
respect. So it's just another option if you didn't care to take advantage
of the functionality the NMR provides.
On 8/29/07, Bruce Snyder <br...@gmail.com> wrote:
>
> On 8/29/07, Ryan Moquin <fr...@gmail.com> wrote:
> > While I'm thinking about it, is there any reason for going through the
> NMR
> > vs. just using the bean directly? Is it only to be loosely coupled or
> are
> > there any other advantages?
>
> The NMR mediates communication so that the location of each service
> doesn't matter. Use of the NMR is done via a flow and the three main
> flows provided by ServiceMix (i.e., SEDA, JMS and JCA) each provide a
> certain level of threading and buffering for messages via
> java.util.concurrent queues.
>
> Consider a situation where you have multiple instances of ServiceMix
> running. When networking the containers together, the NMR allows
> services running in one container to communicate with services running
> in another container very easily. If you make those two services talk
> directly to one another without using the NMR, then you are completely
> circumventing the inherent benefits provided by the NMR. In a way,
> this would be no better than running web services in stand alone web
> containers and making them talk directly to one another.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>
Re: JSR181 interservice communication
Posted by Bruce Snyder <br...@gmail.com>.
On 8/29/07, Ryan Moquin <fr...@gmail.com> wrote:
> While I'm thinking about it, is there any reason for going through the NMR
> vs. just using the bean directly? Is it only to be loosely coupled or are
> there any other advantages?
The NMR mediates communication so that the location of each service
doesn't matter. Use of the NMR is done via a flow and the three main
flows provided by ServiceMix (i.e., SEDA, JMS and JCA) each provide a
certain level of threading and buffering for messages via
java.util.concurrent queues.
Consider a situation where you have multiple instances of ServiceMix
running. When networking the containers together, the NMR allows
services running in one container to communicate with services running
in another container very easily. If you make those two services talk
directly to one another without using the NMR, then you are completely
circumventing the inherent benefits provided by the NMR. In a way,
this would be no better than running web services in stand alone web
containers and making them talk directly to one another.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: JSR181 interservice communication
Posted by Ryan Moquin <fr...@gmail.com>.
While I'm thinking about it, is there any reason for going through the NMR
vs. just using the bean directly? Is it only to be loosely coupled or are
there any other advantages?
On 8/29/07, Ryan Moquin <fr...@gmail.com> wrote:
>
> Ah, so that is different than what I thought I was supposed to do. I'll
> give it a try, thanks!!
>
> On 8/29/07, Nodet Guillaume < gnodet@gmail.com> wrote:
> >
> >
> > Let's say you have two beans foo.bar.AImpl and foo.bar.BImpl that
> > implement
> > the foor.bar.A and foo.bar.B interfaces. Then you would have
> >
> > package foo.bar;
> > @WebService(..)
> > class AImpl implements A {
> > private B b;
> > public void setB(B b) {
> > this.b = b;
> > }
> > ...
> > }
> >
> > and you can wire together using the <jsr181:proxy /> if you want to
> > go through
> > the NMR and be independent of B location and implementation, or using
> > spring
> > just inject an instance of the second service into the first one:
> >
> > <bean id="a" class="foo.bar.AImpl">
> > <property name="b" value-ref="b" />
> > ..
> > </bean>
> >
> > <bean id="b" class="foo.bar.BImpl">
> > ...
> > </bean>
> >
> > You can still expose those beans (one ore both) as jsr181 endpoints
> > in the
> > usual way...
> >
> > Cheers,
> > Guillaume Nodet
> >
> > On Aug 29, 2007, at 2:41 AM, Ryan Moquin wrote:
> >
> > > I'm sorry if there is something really obvious somewhere about how
> > > this is
> > > done, but I was wondering if someone can tell me or point me to
> > > where I can
> > > find out how to make two JSR181 services in servicemix talk to each
> > > other.
> > > I would just have one call the other as if they weren't hooked to
> > > the NMR,
> > > but I'm assuming that's not the most efficient and that there is a
> > > better
> > > way. I saw some various pieces of code that sound kind of like
> > > what I want,
> > > but since I'm a bit new still to how to interact with Servicemix
> > > (other than
> > > deploy to and call a service externally) so I'm a little bit unsure
> > > of what
> > > I need to do. Can anyone point me in the right direction?
> > >
> > > Thanks!
> > >
> > > Ryan
> >
> >
>
Re: JSR181 interservice communication
Posted by Ryan Moquin <fr...@gmail.com>.
Ah, so that is different than what I thought I was supposed to do. I'll
give it a try, thanks!!
On 8/29/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
>
> Let's say you have two beans foo.bar.AImpl and foo.bar.BImpl that
> implement
> the foor.bar.A and foo.bar.B interfaces. Then you would have
>
> package foo.bar;
> @WebService(..)
> class AImpl implements A {
> private B b;
> public void setB(B b) {
> this.b = b;
> }
> ...
> }
>
> and you can wire together using the <jsr181:proxy /> if you want to
> go through
> the NMR and be independent of B location and implementation, or using
> spring
> just inject an instance of the second service into the first one:
>
> <bean id="a" class="foo.bar.AImpl">
> <property name="b" value-ref="b" />
> ..
> </bean>
>
> <bean id="b" class="foo.bar.BImpl">
> ...
> </bean>
>
> You can still expose those beans (one ore both) as jsr181 endpoints
> in the
> usual way...
>
> Cheers,
> Guillaume Nodet
>
> On Aug 29, 2007, at 2:41 AM, Ryan Moquin wrote:
>
> > I'm sorry if there is something really obvious somewhere about how
> > this is
> > done, but I was wondering if someone can tell me or point me to
> > where I can
> > find out how to make two JSR181 services in servicemix talk to each
> > other.
> > I would just have one call the other as if they weren't hooked to
> > the NMR,
> > but I'm assuming that's not the most efficient and that there is a
> > better
> > way. I saw some various pieces of code that sound kind of like
> > what I want,
> > but since I'm a bit new still to how to interact with Servicemix
> > (other than
> > deploy to and call a service externally) so I'm a little bit unsure
> > of what
> > I need to do. Can anyone point me in the right direction?
> >
> > Thanks!
> >
> > Ryan
>
>
Re: JSR181 interservice communication
Posted by Nodet Guillaume <gn...@gmail.com>.
Let's say you have two beans foo.bar.AImpl and foo.bar.BImpl that
implement
the foor.bar.A and foo.bar.B interfaces. Then you would have
package foo.bar;
@WebService(..)
class AImpl implements A {
private B b;
public void setB(B b) {
this.b = b;
}
...
}
and you can wire together using the <jsr181:proxy /> if you want to
go through
the NMR and be independent of B location and implementation, or using
spring
just inject an instance of the second service into the first one:
<bean id="a" class="foo.bar.AImpl">
<property name="b" value-ref="b" />
..
</bean>
<bean id="b" class="foo.bar.BImpl">
...
</bean>
You can still expose those beans (one ore both) as jsr181 endpoints
in the
usual way...
Cheers,
Guillaume Nodet
On Aug 29, 2007, at 2:41 AM, Ryan Moquin wrote:
> I'm sorry if there is something really obvious somewhere about how
> this is
> done, but I was wondering if someone can tell me or point me to
> where I can
> find out how to make two JSR181 services in servicemix talk to each
> other.
> I would just have one call the other as if they weren't hooked to
> the NMR,
> but I'm assuming that's not the most efficient and that there is a
> better
> way. I saw some various pieces of code that sound kind of like
> what I want,
> but since I'm a bit new still to how to interact with Servicemix
> (other than
> deploy to and call a service externally) so I'm a little bit unsure
> of what
> I need to do. Can anyone point me in the right direction?
>
> Thanks!
>
> Ryan