You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Bozo Juretic <bj...@inet.hr> on 2008/12/20 12:02:43 UTC
HTTP BC -> JSR-181 SE
Hello,
1. What is the XML format expected by the jsr-181 component (SE
implemented as JavaBean)? I'm trying to receive the custom GET or POST
fields in HTTP BC and then (using the custom Marshaler class) to invoke
the JavaBean method of jsr-181 SE. If you have other ideas on how to do
this, I would appreciate if you could share them with me.
2. Another thing, what's the right way to implement XML-RPC (over HTTP)
consumer BC? If there is not an existing BC for this, can you recommend
a combination of existing BCs and libraries to accomplish this?
Thank you and best regards,
Bozo
Re: HTTP BC -> JSR-181 SE
Posted by Bozo Juretic <bj...@inet.hr>.
Freeman Fang wrote:
> Bozo Juretic wrote:
>> This is little too abstract for me at this phase, can you please
>> provide an example of this, i.e. one or two cases of what would DSL
>> do and what would the "business logic" be in other components, and
>> what other components would this be? Just generic ideas, I will fill
>> in the blanks related to my specific case.
> It depend on your business logic, servicemix-camel just provide this
> option for you.
> All JBI endpoint can be addressed by using URI as [1], so in your
> camel DSL (camelContext), For an instance, if you think some task is
> more suitable for servicemix-cxf-se, you can define endpoint with name
> cxf-se-endpoint, then in your DSL, you can refer this endpoint by
> jbi:name:cxf-se-endpoint, so that not all of your business logic have
> to be present in the camel SE.
> [1]http://activemq.apache.org/camel/jbi.html
>
Hello again Freeman,
after taking a closer look at Camel I think this is one of the best
components in servicemix. I think I can use camel plus a few BCs to
solve my problem.
Thank you for your kind assistance,
Bozo
Re: HTTP BC -> JSR-181 SE
Posted by Freeman Fang <fr...@gmail.com>.
Bozo Juretic wrote:
> Freeman Fang wrote:
>> Bozo Juretic wrote:
>>> Hi Freeman,
>>>
>>> yes I've been through it yesterday. Just let me summarize to see if
>>> I got it right: various frontend and backend components (custom,
>>> webservices etc.) would act as endpoints for a central camel SE
>>> which would:
>>> 1. Take the data from database
>>> 2. Do the business login and transformation
>>> 3. Use the Camel DSL for routing after this is done.
>>>
>>> All of the "business logic" would thus be present in the camel SE
>>> mentioned above.
>>>
>> Actually besides what you summarize, servicemix-camel aslo can use
>> DSL to talk with other endpoint inside JBI constainer, so that you
>> can delegate your business logic to other more suitable endpoint in
>> other components
>>
> This is little too abstract for me at this phase, can you please
> provide an example of this, i.e. one or two cases of what would DSL do
> and what would the "business logic" be in other components, and what
> other components would this be? Just generic ideas, I will fill in the
> blanks related to my specific case.
It depend on your business logic, servicemix-camel just provide this
option for you.
All JBI endpoint can be addressed by using URI as [1], so in your camel
DSL (camelContext), For an instance, if you think some task is more
suitable for servicemix-cxf-se, you can define endpoint with name
cxf-se-endpoint, then in your DSL, you can refer this endpoint by
jbi:name:cxf-se-endpoint, so that not all of your business logic have to
be present in the camel SE.
[1]http://activemq.apache.org/camel/jbi.html
>
> Thanks and best regards,
>
> Bozo
>
Re: HTTP BC -> JSR-181 SE
Posted by Bozo Juretic <bj...@inet.hr>.
Freeman Fang wrote:
> Bozo Juretic wrote:
>> Hi Freeman,
>>
>> yes I've been through it yesterday. Just let me summarize to see if I
>> got it right: various frontend and backend components (custom,
>> webservices etc.) would act as endpoints for a central camel SE which
>> would:
>> 1. Take the data from database
>> 2. Do the business login and transformation
>> 3. Use the Camel DSL for routing after this is done.
>>
>> All of the "business logic" would thus be present in the camel SE
>> mentioned above.
>>
> Actually besides what you summarize, servicemix-camel aslo can use DSL
> to talk with other endpoint inside JBI constainer, so that you can
> delegate your business logic to other more suitable endpoint in other
> components
>
This is little too abstract for me at this phase, can you please provide
an example of this, i.e. one or two cases of what would DSL do and what
would the "business logic" be in other components, and what other
components would this be? Just generic ideas, I will fill in the blanks
related to my specific case.
Thanks and best regards,
Bozo
Re: HTTP BC -> JSR-181 SE
Posted by Freeman Fang <fr...@gmail.com>.
Bozo Juretic wrote:
>
>
> Freeman Fang wrote:
>> Bozo Juretic wrote:
>>> Hello Freeman,
>>>
>>> Freeman Fang wrote:
>>>> Bozo Juretic wrote:
>>>>> Hello,
>>>>>
>>>>> 1. What is the XML format expected by the jsr-181 component (SE
>>>>> implemented as JavaBean)? I'm trying to receive the custom GET or
>>>>> POST fields in HTTP BC and then (using the custom Marshaler class)
>>>>> to invoke the JavaBean method of jsr-181 SE. If you have other
>>>>> ideas on how to do this, I would appreciate if you could share
>>>>> them with me.
>>>> Both soap message and jbi message should be fine. And you can take
>>>> a look at the wsdl-first example shipped with kit.
>>> Thank you for you kind response.
>>>
>>> There is another dilemma I have, of architectural nature. We have
>>> been using in production a custom developed messaging-based software
>>> for processing financial transactions, where financial institutions
>>> have different protocols in the background. In the frontend part of
>>> the solution we have something similar to a BizTalk's (or Axis2's)
>>> Pipeline with Componentes (i.e. different stages of syntax and
>>> business validation), before the message actually gets to the
>>> processing code (actual business logic, which would do the routing
>>> based on data from the database). We are right now migrating this
>>> stuff to open architecture of servicemix since a lot of our code is
>>> basically already done by you guys.
>>>
>>> Can you propose a way to re-implement the pipeline in the
>>> servicesmix? To be more precise, what is the best architectural
>>> strategy for having many stages of business validation (i.e. you
>>> look up something in the database and possibly return fault to the
>>> client if something is not right), so that the actual business logic
>>> can remain simple (routing + transformation). Since I don't have a
>>> lot of experience with servicemix (been on it only for a few days
>>> after dismissing openesb), the only thing I can implement is one
>>> giant JavaBean with dynamic routing (based on message and database
>>> data) and business validation. I'm sure there must be a better way,
>>> based on already defined patterns.
>>>
>>> Thanks in advance for your time.
>> Hi Bozo,
>>
>> After going through your requirements, the servicemix-camel component
>> which leverage apache camel project come to my mind. I believe it's
>> what you want, it's very suitable for the concept you mentioned,
>> pipeline, content based routing, transformation, etc.
>> You can take a look [1] and [2] to get more details
>>
>> [1]http://servicemix.apache.org/servicemix-camel.html
>> [2]http://activemq.apache.org/camel/
> Hi Freeman,
>
> yes I've been through it yesterday. Just let me summarize to see if I
> got it right: various frontend and backend components (custom,
> webservices etc.) would act as endpoints for a central camel SE which
> would:
> 1. Take the data from database
> 2. Do the business login and transformation
> 3. Use the Camel DSL for routing after this is done.
>
> All of the "business logic" would thus be present in the camel SE
> mentioned above.
>
Actually besides what you summarize, servicemix-camel aslo can use DSL
to talk with other endpoint inside JBI constainer, so that you can
delegate your business logic to other more suitable endpoint in other
components
> Something like that?
>
> Best regards,
>
> Bozo
>
>
Re: HTTP BC -> JSR-181 SE
Posted by Bozo Juretic <bj...@inet.hr>.
Freeman Fang wrote:
> Bozo Juretic wrote:
>> Hello Freeman,
>>
>> Freeman Fang wrote:
>>> Bozo Juretic wrote:
>>>> Hello,
>>>>
>>>> 1. What is the XML format expected by the jsr-181 component (SE
>>>> implemented as JavaBean)? I'm trying to receive the custom GET or
>>>> POST fields in HTTP BC and then (using the custom Marshaler class)
>>>> to invoke the JavaBean method of jsr-181 SE. If you have other
>>>> ideas on how to do this, I would appreciate if you could share them
>>>> with me.
>>> Both soap message and jbi message should be fine. And you can take a
>>> look at the wsdl-first example shipped with kit.
>> Thank you for you kind response.
>>
>> There is another dilemma I have, of architectural nature. We have
>> been using in production a custom developed messaging-based software
>> for processing financial transactions, where financial institutions
>> have different protocols in the background. In the frontend part of
>> the solution we have something similar to a BizTalk's (or Axis2's)
>> Pipeline with Componentes (i.e. different stages of syntax and
>> business validation), before the message actually gets to the
>> processing code (actual business logic, which would do the routing
>> based on data from the database). We are right now migrating this
>> stuff to open architecture of servicemix since a lot of our code is
>> basically already done by you guys.
>>
>> Can you propose a way to re-implement the pipeline in the
>> servicesmix? To be more precise, what is the best architectural
>> strategy for having many stages of business validation (i.e. you look
>> up something in the database and possibly return fault to the client
>> if something is not right), so that the actual business logic can
>> remain simple (routing + transformation). Since I don't have a lot of
>> experience with servicemix (been on it only for a few days after
>> dismissing openesb), the only thing I can implement is one giant
>> JavaBean with dynamic routing (based on message and database data)
>> and business validation. I'm sure there must be a better way, based
>> on already defined patterns.
>>
>> Thanks in advance for your time.
> Hi Bozo,
>
> After going through your requirements, the servicemix-camel component
> which leverage apache camel project come to my mind. I believe it's
> what you want, it's very suitable for the concept you mentioned,
> pipeline, content based routing, transformation, etc.
> You can take a look [1] and [2] to get more details
>
> [1]http://servicemix.apache.org/servicemix-camel.html
> [2]http://activemq.apache.org/camel/
Hi Freeman,
yes I've been through it yesterday. Just let me summarize to see if I
got it right: various frontend and backend components (custom,
webservices etc.) would act as endpoints for a central camel SE which would:
1. Take the data from database
2. Do the business login and transformation
3. Use the Camel DSL for routing after this is done.
All of the "business logic" would thus be present in the camel SE
mentioned above.
Something like that?
Best regards,
Bozo
Re: HTTP BC -> JSR-181 SE
Posted by Freeman Fang <fr...@gmail.com>.
Bozo Juretic wrote:
> Hello Freeman,
>
> Freeman Fang wrote:
>> Bozo Juretic wrote:
>>> Hello,
>>>
>>> 1. What is the XML format expected by the jsr-181 component (SE
>>> implemented as JavaBean)? I'm trying to receive the custom GET or
>>> POST fields in HTTP BC and then (using the custom Marshaler class)
>>> to invoke the JavaBean method of jsr-181 SE. If you have other ideas
>>> on how to do this, I would appreciate if you could share them with me.
>> Both soap message and jbi message should be fine. And you can take a
>> look at the wsdl-first example shipped with kit.
> Thank you for you kind response.
>
> There is another dilemma I have, of architectural nature. We have been
> using in production a custom developed messaging-based software for
> processing financial transactions, where financial institutions have
> different protocols in the background. In the frontend part of the
> solution we have something similar to a BizTalk's (or Axis2's)
> Pipeline with Componentes (i.e. different stages of syntax and
> business validation), before the message actually gets to the
> processing code (actual business logic, which would do the routing
> based on data from the database). We are right now migrating this
> stuff to open architecture of servicemix since a lot of our code is
> basically already done by you guys.
>
> Can you propose a way to re-implement the pipeline in the servicesmix?
> To be more precise, what is the best architectural strategy for having
> many stages of business validation (i.e. you look up something in the
> database and possibly return fault to the client if something is not
> right), so that the actual business logic can remain simple (routing +
> transformation). Since I don't have a lot of experience with
> servicemix (been on it only for a few days after dismissing openesb),
> the only thing I can implement is one giant JavaBean with dynamic
> routing (based on message and database data) and business validation.
> I'm sure there must be a better way, based on already defined patterns.
>
> Thanks in advance for your time.
Hi Bozo,
After going through your requirements, the servicemix-camel component
which leverage apache camel project come to my mind. I believe it's what
you want, it's very suitable for the concept you mentioned, pipeline,
content based routing, transformation, etc.
You can take a look [1] and [2] to get more details
[1]http://servicemix.apache.org/servicemix-camel.html
[2]http://activemq.apache.org/camel/
Regards
Freeman
>
> Best regards,
>
> Bozo
>
>
>
>
>
>
>
Re: HTTP BC -> JSR-181 SE
Posted by Bozo Juretic <bj...@inet.hr>.
Hello Freeman,
Freeman Fang wrote:
> Bozo Juretic wrote:
>> Hello,
>>
>> 1. What is the XML format expected by the jsr-181 component (SE
>> implemented as JavaBean)? I'm trying to receive the custom GET or
>> POST fields in HTTP BC and then (using the custom Marshaler class) to
>> invoke the JavaBean method of jsr-181 SE. If you have other ideas on
>> how to do this, I would appreciate if you could share them with me.
> Both soap message and jbi message should be fine. And you can take a
> look at the wsdl-first example shipped with kit.
Thank you for you kind response.
There is another dilemma I have, of architectural nature. We have been
using in production a custom developed messaging-based software for
processing financial transactions, where financial institutions have
different protocols in the background. In the frontend part of the
solution we have something similar to a BizTalk's (or Axis2's) Pipeline
with Componentes (i.e. different stages of syntax and business
validation), before the message actually gets to the processing code
(actual business logic, which would do the routing based on data from
the database). We are right now migrating this stuff to open
architecture of servicemix since a lot of our code is basically already
done by you guys.
Can you propose a way to re-implement the pipeline in the servicesmix?
To be more precise, what is the best architectural strategy for having
many stages of business validation (i.e. you look up something in the
database and possibly return fault to the client if something is not
right), so that the actual business logic can remain simple (routing +
transformation). Since I don't have a lot of experience with servicemix
(been on it only for a few days after dismissing openesb), the only
thing I can implement is one giant JavaBean with dynamic routing (based
on message and database data) and business validation. I'm sure there
must be a better way, based on already defined patterns.
Thanks in advance for your time.
Best regards,
Bozo
Re: HTTP BC -> JSR-181 SE
Posted by Freeman Fang <fr...@gmail.com>.
Bozo Juretic wrote:
> Hello,
>
> 1. What is the XML format expected by the jsr-181 component (SE
> implemented as JavaBean)? I'm trying to receive the custom GET or POST
> fields in HTTP BC and then (using the custom Marshaler class) to
> invoke the JavaBean method of jsr-181 SE. If you have other ideas on
> how to do this, I would appreciate if you could share them with me.
Both soap message and jbi message should be fine. And you can take a
look at the wsdl-first example shipped with kit.
>
> 2. Another thing, what's the right way to implement XML-RPC (over
> HTTP) consumer BC? If there is not an existing BC for this, can you
> recommend a combination of existing BCs and libraries to accomplish this?
>
I think you needn't do something special for the rpc-literal (I don't
think the rpc-encoded is supported ), if your wsdl is rpc-literal, the
servicemix-http will use rpc automatically for you.
> Thank you and best regards,
>
> Bozo
>