You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Scott Johnson <sj...@mediaspansoftware.com> on 2007/05/07 20:22:12 UTC
Is ServiceMix/JBI a Good Fit for Dynamic Processing?
I am in the process of evaluating various integration/component
technologies for a forthcoming application I will be charged with
developing.
The purpose of the application is to be a means by which our
customers can perform batch operations on a selection of resources.
The customers define "work orders" that instruct the application to
perform a series of steps to accomplish the customer's goals. The
customers then instruct the application to perform those work orders.
That is the most important point: this process is completely customer-
driven and the customer can create any number of work-flows. I cannot
hard-code a Service Assembly to, say, get text files from this FTP
location, route them through the English-to-German translator, and
put them on the local hard drive. At the time of creating the
application I don't know what the work flows are specifically (just
that they involve using the services my application provides).
I have been looking into ESB, OSGi (both new approaches for me) or
just using hand-rolled code to solve the problem. Initially ESB and
OSGi seemed to be reasonably perfect matches, but the more I work
with an ESB solution, the more frustrated I become.
For my prototype application I envisioned the following pieces I'd
need to create for an ESB solution:
1. Bridge from HTTP to JMS:
a. HTTP endpoint for inbound requests (seems a reasonable way to
trigger the execution of a work order for this prototype)
b. EIP pipeline to transform and place request (which is the "work
order") onto a JMS Queue
2. JMS consumer of above JMS queue whose destination service is...
3. Custom SE1 - A component that parses the work order and forwards
to the first component listed, which is...
4. Custom SE2 - A component that performs the first work order
process then forwards the work order to...
5. Custom SE3 - A component that performs the second work order
process, then forwards the work order to...
6. Custom BC2 - An output component that places the resource to a
specific location.
Note 1: depending on the work order, there could be any number of
custom SEs involved between steps 3 and 6 above.
Note 2: none of the custom SE/BCs know about each other (as it should
be) but all know about a RoutingSlip object that is passed as a
property on the ME. Each SE designates the next service to be called
based on that routing slip (which was generated by the initial
component, #3 above) until the work order is complete.
Note 3: I have created Service Units for all the SEs which are all
designated as providers.
I'm having lots of issues getting this to work (some due to the
newness of ServiceMix and JBI to me, certainly) but, before I get
much farther I would like to ask: does this type of dynamic work flow
really align with the goals of an ESB and is it well supported or am
I barking up the wrong tree here?
Thanks for your time,
Scott
Re: Is ServiceMix/JBI a Good Fit for Dynamic Processing?
Posted by Gert Vanthienen <ge...@skynet.be>.
Scott,
Your exception is probably caused by trying to set the out message on an
InOnly MessageExchange. Did you perhaps specify an in-only MEP on the HTTP
BC endpoint?
Anyway, to 'forward' the message to the next SE, you do not have to set the
Out message on the incoming MessageExchange, you have to create a whole new
MessageExchange for the interaction with the next SE. The message you want
to forward should go in the In message of the MessageExchange. You can use
the MessageUtil class to easily transfer messages between MessageExchanges.
Have a look at the source code for e.g. StaticRoutingSlip for an example on
how to do this.
Regards,
Gert
Scott Johnson-16 wrote:
>
> I have returned to trying to get my prototype working with ServiceMix
> but something just is not clicking unfortunately.
>
> Basically my prototype consists of a few SEs and then the SUs and SA
> to configure the prototype.
>
> The 'main' SE receives requests just fine from an HTTP endpoint. But
> when I try to forward the request to another SE I get the following
> exception cause:
>
> Caused by: javax.jbi.messaging.MessagingException: Out not supported
> at
> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.setMessage
> (MessageExchangeImpl.java:317)
> at
> main.java.com.mediaspansoftware.transporter.servicemix.TaskEngineEndpoin
> t.process(TaskEngineEndpoint.java:194)
> at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess
> (AsyncBaseLifeCycle.java:489)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange
> (AsyncBaseLifeCycle.java:441)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange
> (BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound
> (DeliveryChannelImpl.java:593)
> at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting
> (AbstractFlow.java:174)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting
> (SedaFlow.java:176)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run
> (SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor
> $Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor
> $Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:613)
>
>
> This was the initial xbean.xml for the SU I deployed against the main
> SE (TaskEngine):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <beans xmlns:taskEngineSE="http://
> com.mediaspansoftware.transporter/1.0"
> xmlns:tp="http://www.mediaspansoftware.com/transporter">
>
> <taskEngineSE:endpoint
> service="tp:TaskEngine"
> endpoint="endpoint"/>
>
> </beans>
>
> It seems the SE acts like it can only process 'in' messages but I
> need to be able to forward to another SE. In looking at the original
> xbean.xml file for the SU, there is no specification of a role or
> defaultMEP. So I tried to add this information such that my xbean.xml
> looks like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <beans xmlns:taskEngineSE="http://com.mediaspansoftware/1.0"
> xmlns:tp="http://www.mediaspansoftware.com/transporter">
>
> <taskEngineSE:endpoint
> service="tp:TaskEngine"
> role="provider"
> endpoint="endpoint"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-out" />
>
> </beans>
>
> Unfortunately, now I get a new exception when attempting to re-deploy
> the SA:
>
> Caused by: org.springframework.beans.NotWritablePropertyException:
> Invalid property 'defaultMep' of bean class
> [main.java.com.mediaspansoftware.transporter.servicemix.TaskEngineEndpoi
> nt]: Bean property 'defaultMep' is not writable or has an invalid
> setter method. Does the parameter type of the setter match the return
> type of the getter?
> at org.springframework.beans.BeanWrapperImpl.setPropertyValue
> (BeanWrapperImpl.java:750)
> at org.springframework.beans.BeanWrapperImpl.setPropertyValue
> (BeanWrapperImpl.java:607)
> at
> org.springframework.beans.AbstractPropertyAccessor.setPropertyValue
> (AbstractPropertyAccessor.java:49)
> at
> org.springframework.beans.AbstractPropertyAccessor.setPropertyValues
> (AbstractPropertyAccessor.java:74)
> at
> org.springframework.beans.AbstractPropertyAccessor.setPropertyValues
> (AbstractPropertyAccessor.java:57)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
> tory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:965)
> ... 27 more
>
> How do I configure an SU so that the TaskEngine SE can receive and
> forward messages?
>
> Thanks,
> Scott
>
> ---
>
> On May 9, 2007, at 3:10 AM, Gert Vanthienen wrote:
>
>>
>> Scott,
>>
>> If your SE just wants to get a single file using, you might be
>> better off
>> using the commons-net API directly to go and get it. If you really
>> want an
>> FTP poller, I suppose you can programmaticaly add an
>> FTPPollerEndpoint once
>> the servicemix-ftp component is installed. The other option would
>> be to
>> 'generate' a SU on-the-fly and deploy it into the container using
>> the API.
>>
>> Regards,
>>
>> Gert
>>
>>
>> Scott Johnson-16 wrote:
>>>
>>>
>>> On May 8, 2007, at 8:49 AM, Gert Vanthienen wrote:
>>>
>>>> ...
>>>
>>> Yes this is precisely what I need to do. It sounds like it's worth
>>> the time for me to pursue this prototype in ServiceMix further.
>>>
>>> One other question: can the provided SEs be configured at run-time to
>>> perform their service? For example, say I have 2 work orders both of
>>> which want use FTP to monitor for input files but at different times
>>> and from different FTP sites. Can my SE pass along a configuration at
>>> run-time to the servicemix-ftp component to tell it where to GET from
>>> (rather than having to specify it in a config file)? I assume I'd
>>> still need to deploy an SU but (hopefully) I can override it's
>>> configuration dynamically as I process work-orders.
>>>
>>> Thanks,
>>> Scott
>>>
>>>> ...
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/Is-ServiceMix-
>> JBI-a-Good-Fit-for-Dynamic-Processing--tf3705460s12049.html#a10389452
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/Is-ServiceMix-JBI-a-Good-Fit-for-Dynamic-Processing--tf3705460s12049.html#a10420456
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: Is ServiceMix/JBI a Good Fit for Dynamic Processing?
Posted by Scott Johnson <sj...@mediaspansoftware.com>.
I have returned to trying to get my prototype working with ServiceMix
but something just is not clicking unfortunately.
Basically my prototype consists of a few SEs and then the SUs and SA
to configure the prototype.
The 'main' SE receives requests just fine from an HTTP endpoint. But
when I try to forward the request to another SE I get the following
exception cause:
Caused by: javax.jbi.messaging.MessagingException: Out not supported
at
org.apache.servicemix.jbi.messaging.MessageExchangeImpl.setMessage
(MessageExchangeImpl.java:317)
at
main.java.com.mediaspansoftware.transporter.servicemix.TaskEngineEndpoin
t.process(TaskEngineEndpoint.java:194)
at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess
(AsyncBaseLifeCycle.java:489)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange
(AsyncBaseLifeCycle.java:441)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange
(BaseLifeCycle.java:46)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound
(DeliveryChannelImpl.java:593)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting
(AbstractFlow.java:174)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting
(SedaFlow.java:176)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run
(SedaQueue.java:134)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:613)
This was the initial xbean.xml for the SU I deployed against the main
SE (TaskEngine):
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:taskEngineSE="http://
com.mediaspansoftware.transporter/1.0"
xmlns:tp="http://www.mediaspansoftware.com/transporter">
<taskEngineSE:endpoint
service="tp:TaskEngine"
endpoint="endpoint"/>
</beans>
It seems the SE acts like it can only process 'in' messages but I
need to be able to forward to another SE. In looking at the original
xbean.xml file for the SU, there is no specification of a role or
defaultMEP. So I tried to add this information such that my xbean.xml
looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:taskEngineSE="http://com.mediaspansoftware/1.0"
xmlns:tp="http://www.mediaspansoftware.com/transporter">
<taskEngineSE:endpoint
service="tp:TaskEngine"
role="provider"
endpoint="endpoint"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out" />
</beans>
Unfortunately, now I get a new exception when attempting to re-deploy
the SA:
Caused by: org.springframework.beans.NotWritablePropertyException:
Invalid property 'defaultMep' of bean class
[main.java.com.mediaspansoftware.transporter.servicemix.TaskEngineEndpoi
nt]: Bean property 'defaultMep' is not writable or has an invalid
setter method. Does the parameter type of the setter match the return
type of the getter?
at org.springframework.beans.BeanWrapperImpl.setPropertyValue
(BeanWrapperImpl.java:750)
at org.springframework.beans.BeanWrapperImpl.setPropertyValue
(BeanWrapperImpl.java:607)
at
org.springframework.beans.AbstractPropertyAccessor.setPropertyValue
(AbstractPropertyAccessor.java:49)
at
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues
(AbstractPropertyAccessor.java:74)
at
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues
(AbstractPropertyAccessor.java:57)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
tory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:965)
... 27 more
How do I configure an SU so that the TaskEngine SE can receive and
forward messages?
Thanks,
Scott
---
On May 9, 2007, at 3:10 AM, Gert Vanthienen wrote:
>
> Scott,
>
> If your SE just wants to get a single file using, you might be
> better off
> using the commons-net API directly to go and get it. If you really
> want an
> FTP poller, I suppose you can programmaticaly add an
> FTPPollerEndpoint once
> the servicemix-ftp component is installed. The other option would
> be to
> 'generate' a SU on-the-fly and deploy it into the container using
> the API.
>
> Regards,
>
> Gert
>
>
> Scott Johnson-16 wrote:
>>
>>
>> On May 8, 2007, at 8:49 AM, Gert Vanthienen wrote:
>>
>>> ...
>>
>> Yes this is precisely what I need to do. It sounds like it's worth
>> the time for me to pursue this prototype in ServiceMix further.
>>
>> One other question: can the provided SEs be configured at run-time to
>> perform their service? For example, say I have 2 work orders both of
>> which want use FTP to monitor for input files but at different times
>> and from different FTP sites. Can my SE pass along a configuration at
>> run-time to the servicemix-ftp component to tell it where to GET from
>> (rather than having to specify it in a config file)? I assume I'd
>> still need to deploy an SU but (hopefully) I can override it's
>> configuration dynamically as I process work-orders.
>>
>> Thanks,
>> Scott
>>
>>> ...
>>
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Is-ServiceMix-
> JBI-a-Good-Fit-for-Dynamic-Processing--tf3705460s12049.html#a10389452
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
Re: Is ServiceMix/JBI a Good Fit for Dynamic Processing?
Posted by Gert Vanthienen <ge...@skynet.be>.
Scott,
If your SE just wants to get a single file using, you might be better off
using the commons-net API directly to go and get it. If you really want an
FTP poller, I suppose you can programmaticaly add an FTPPollerEndpoint once
the servicemix-ftp component is installed. The other option would be to
'generate' a SU on-the-fly and deploy it into the container using the API.
Regards,
Gert
Scott Johnson-16 wrote:
>
>
> On May 8, 2007, at 8:49 AM, Gert Vanthienen wrote:
>
>>...
>
> Yes this is precisely what I need to do. It sounds like it's worth
> the time for me to pursue this prototype in ServiceMix further.
>
> One other question: can the provided SEs be configured at run-time to
> perform their service? For example, say I have 2 work orders both of
> which want use FTP to monitor for input files but at different times
> and from different FTP sites. Can my SE pass along a configuration at
> run-time to the servicemix-ftp component to tell it where to GET from
> (rather than having to specify it in a config file)? I assume I'd
> still need to deploy an SU but (hopefully) I can override it's
> configuration dynamically as I process work-orders.
>
> Thanks,
> Scott
>
>> ...
>
>
>
>
>
--
View this message in context: http://www.nabble.com/Is-ServiceMix-JBI-a-Good-Fit-for-Dynamic-Processing--tf3705460s12049.html#a10389452
Sent from the ServiceMix - User mailing list archive at Nabble.com.
unsubscribe
Posted by Robert Sinner <rs...@cms-solutions.com>.
unsubscribe
Re: Is ServiceMix/JBI a Good Fit for Dynamic Processing?
Posted by Scott Johnson <sj...@mediaspansoftware.com>.
On May 8, 2007, at 8:49 AM, Gert Vanthienen wrote:
> Scott,
>
>
> So you want to build your SE then, that inspects your work order
> and calls the required services based on the information available
> in the work itself -- that wouldn't be any problem. Probably you
> can take a look at how ServiceMix static routing slip
> implementation does this, but instead you dynamically generate the
> list of exchange targets in your code.
>
Yes this is precisely what I need to do. It sounds like it's worth
the time for me to pursue this prototype in ServiceMix further.
One other question: can the provided SEs be configured at run-time to
perform their service? For example, say I have 2 work orders both of
which want use FTP to monitor for input files but at different times
and from different FTP sites. Can my SE pass along a configuration at
run-time to the servicemix-ftp component to tell it where to GET from
(rather than having to specify it in a config file)? I assume I'd
still need to deploy an SU but (hopefully) I can override it's
configuration dynamically as I process work-orders.
Thanks,
Scott
> ServiceMix ships with servicemix-quartz, which can be used to
> schedule and trigger jobs.
>
>
> Gert
>
> Scott Johnson wrote:
>> On May 7, 2007, at 4:09 PM, Gert Vanthienen wrote:
>>
>>>
>>> L.S.,
>>>
>>>
>>> I think an ESB solution, such as ServiceMix, can provide you with
>>> a lot of
>>> the features you require:
>>> - flexible protocol handling and bridging
>>> - loose coupling
>>> - routing services
>>> - dynamic endpoints
>>>
>>> Using ServiceMix as the foundation for your solution would allow
>>> you to
>>> leverage these features and to invest your development efforts on
>>> the SE you
>>> will be using in step 3 of the flow you describe. If I
>>> understand your
>>> requirements correctly, you would want to build some kind of
>>> tooling to
>>> easily assemble and deploy these workflows (as service assemblies).
>>>
>>
>> I hadn't thought about using the service assembly as the driver
>> for completing a work order. In some cases our customers may build
>> hundreds of work orders, and we'd have to manage a service
>> assembly for each. That may be workable (although it seems more
>> involved than what I was originally thinking about). My original
>> idea was to have one service assembly that simply defined the
>> various SEs, etc. needed and their roles and have the routing done
>> dynamically by each SE (via the RoutingSlip approach I mentioned
>> in the original mail that is created based on a work order
>> definition file).
>>
>> On a different note, can service assemblies be scheduled for
>> automatic execution (i.e. perform this work-flow of services every
>> day at 3 a.m.)? That is another requirement of the application.
>>
>> Regards,
>> Scott
>>
>>> Is this the kind of solution you're envisioning or am I missing
>>> something?
>>>
>>>
>>> Regards,
>>>
>>> Gert
>>>
>>>
>>>
>>>
>>> Scott Johnson-16 wrote:
>>>>
>>>> I am in the process of evaluating various integration/component
>>>> technologies for a forthcoming application I will be charged with
>>>> developing.
>>>>
>>>> The purpose of the application is to be a means by which our
>>>> customers can perform batch operations on a selection of resources.
>>>> The customers define "work orders" that instruct the application to
>>>> perform a series of steps to accomplish the customer's goals. The
>>>> customers then instruct the application to perform those work
>>>> orders.
>>>> That is the most important point: this process is completely
>>>> customer-
>>>> driven and the customer can create any number of work-flows. I
>>>> cannot
>>>> hard-code a Service Assembly to, say, get text files from this FTP
>>>> location, route them through the English-to-German translator, and
>>>> put them on the local hard drive. At the time of creating the
>>>> application I don't know what the work flows are specifically (just
>>>> that they involve using the services my application provides).
>>>>
>>>> I have been looking into ESB, OSGi (both new approaches for me) or
>>>> just using hand-rolled code to solve the problem. Initially ESB and
>>>> OSGi seemed to be reasonably perfect matches, but the more I work
>>>> with an ESB solution, the more frustrated I become.
>>>>
>>>> For my prototype application I envisioned the following pieces I'd
>>>> need to create for an ESB solution:
>>>>
>>>> 1. Bridge from HTTP to JMS:
>>>> a. HTTP endpoint for inbound requests (seems a reasonable
>>>> way to
>>>> trigger the execution of a work order for this prototype)
>>>> b. EIP pipeline to transform and place request (which is the
>>>> "work
>>>> order") onto a JMS Queue
>>>> 2. JMS consumer of above JMS queue whose destination service is...
>>>> 3. Custom SE1 - A component that parses the work order and forwards
>>>> to the first component listed, which is...
>>>> 4. Custom SE2 - A component that performs the first work order
>>>> process then forwards the work order to...
>>>> 5. Custom SE3 - A component that performs the second work order
>>>> process, then forwards the work order to...
>>>> 6. Custom BC2 - An output component that places the resource to a
>>>> specific location.
>>>>
>>>> Note 1: depending on the work order, there could be any number of
>>>> custom SEs involved between steps 3 and 6 above.
>>>>
>>>> Note 2: none of the custom SE/BCs know about each other (as it
>>>> should
>>>> be) but all know about a RoutingSlip object that is passed as a
>>>> property on the ME. Each SE designates the next service to be
>>>> called
>>>> based on that routing slip (which was generated by the initial
>>>> component, #3 above) until the work order is complete.
>>>>
>>>> Note 3: I have created Service Units for all the SEs which are all
>>>> designated as providers.
>>>>
>>>> I'm having lots of issues getting this to work (some due to the
>>>> newness of ServiceMix and JBI to me, certainly) but, before I get
>>>> much farther I would like to ask: does this type of dynamic work
>>>> flow
>>>> really align with the goals of an ESB and is it well supported
>>>> or am
>>>> I barking up the wrong tree here?
>>>>
>>>> Thanks for your time,
>>>> Scott
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --View this message in context: http://www.nabble.com/Is-
>>> ServiceMix-JBI-a-Good-Fit-for-Dynamic-Processing--
>>> tf3705460s12049.html#a10364510
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
Scott Johnson, Software Developer
MediaSpan Media Software
sjohnson@mediaspansoftware.com
Re: Is ServiceMix/JBI a Good Fit for Dynamic Processing?
Posted by Gert Vanthienen <ge...@skynet.be>.
Scott,
So you want to build your SE then, that inspects your work order and
calls the required services based on the information available in the
work itself -- that wouldn't be any problem. Probably you can take a
look at how ServiceMix static routing slip implementation does this, but
instead you dynamically generate the list of exchange targets in your code.
ServiceMix ships with servicemix-quartz, which can be used to schedule
and trigger jobs.
Gert
Scott Johnson wrote:
> On May 7, 2007, at 4:09 PM, Gert Vanthienen wrote:
>
>>
>> L.S.,
>>
>>
>> I think an ESB solution, such as ServiceMix, can provide you with a
>> lot of
>> the features you require:
>> - flexible protocol handling and bridging
>> - loose coupling
>> - routing services
>> - dynamic endpoints
>>
>> Using ServiceMix as the foundation for your solution would allow you to
>> leverage these features and to invest your development efforts on the
>> SE you
>> will be using in step 3 of the flow you describe. If I understand your
>> requirements correctly, you would want to build some kind of tooling to
>> easily assemble and deploy these workflows (as service assemblies).
>>
>
> I hadn't thought about using the service assembly as the driver for
> completing a work order. In some cases our customers may build
> hundreds of work orders, and we'd have to manage a service assembly
> for each. That may be workable (although it seems more involved than
> what I was originally thinking about). My original idea was to have
> one service assembly that simply defined the various SEs, etc. needed
> and their roles and have the routing done dynamically by each SE (via
> the RoutingSlip approach I mentioned in the original mail that is
> created based on a work order definition file).
>
> On a different note, can service assemblies be scheduled for automatic
> execution (i.e. perform this work-flow of services every day at 3
> a.m.)? That is another requirement of the application.
>
> Regards,
> Scott
>
>> Is this the kind of solution you're envisioning or am I missing
>> something?
>>
>>
>> Regards,
>>
>> Gert
>>
>>
>>
>>
>> Scott Johnson-16 wrote:
>>>
>>> I am in the process of evaluating various integration/component
>>> technologies for a forthcoming application I will be charged with
>>> developing.
>>>
>>> The purpose of the application is to be a means by which our
>>> customers can perform batch operations on a selection of resources.
>>> The customers define "work orders" that instruct the application to
>>> perform a series of steps to accomplish the customer's goals. The
>>> customers then instruct the application to perform those work orders.
>>> That is the most important point: this process is completely customer-
>>> driven and the customer can create any number of work-flows. I cannot
>>> hard-code a Service Assembly to, say, get text files from this FTP
>>> location, route them through the English-to-German translator, and
>>> put them on the local hard drive. At the time of creating the
>>> application I don't know what the work flows are specifically (just
>>> that they involve using the services my application provides).
>>>
>>> I have been looking into ESB, OSGi (both new approaches for me) or
>>> just using hand-rolled code to solve the problem. Initially ESB and
>>> OSGi seemed to be reasonably perfect matches, but the more I work
>>> with an ESB solution, the more frustrated I become.
>>>
>>> For my prototype application I envisioned the following pieces I'd
>>> need to create for an ESB solution:
>>>
>>> 1. Bridge from HTTP to JMS:
>>> a. HTTP endpoint for inbound requests (seems a reasonable way to
>>> trigger the execution of a work order for this prototype)
>>> b. EIP pipeline to transform and place request (which is the "work
>>> order") onto a JMS Queue
>>> 2. JMS consumer of above JMS queue whose destination service is...
>>> 3. Custom SE1 - A component that parses the work order and forwards
>>> to the first component listed, which is...
>>> 4. Custom SE2 - A component that performs the first work order
>>> process then forwards the work order to...
>>> 5. Custom SE3 - A component that performs the second work order
>>> process, then forwards the work order to...
>>> 6. Custom BC2 - An output component that places the resource to a
>>> specific location.
>>>
>>> Note 1: depending on the work order, there could be any number of
>>> custom SEs involved between steps 3 and 6 above.
>>>
>>> Note 2: none of the custom SE/BCs know about each other (as it should
>>> be) but all know about a RoutingSlip object that is passed as a
>>> property on the ME. Each SE designates the next service to be called
>>> based on that routing slip (which was generated by the initial
>>> component, #3 above) until the work order is complete.
>>>
>>> Note 3: I have created Service Units for all the SEs which are all
>>> designated as providers.
>>>
>>> I'm having lots of issues getting this to work (some due to the
>>> newness of ServiceMix and JBI to me, certainly) but, before I get
>>> much farther I would like to ask: does this type of dynamic work flow
>>> really align with the goals of an ESB and is it well supported or am
>>> I barking up the wrong tree here?
>>>
>>> Thanks for your time,
>>> Scott
>>>
>>>
>>>
>>>
>>>
>>
>> --View this message in context:
>> http://www.nabble.com/Is-ServiceMix-JBI-a-Good-Fit-for-Dynamic-Processing--tf3705460s12049.html#a10364510
>>
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>
>
>
Re: Is ServiceMix/JBI a Good Fit for Dynamic Processing?
Posted by Scott Johnson <sj...@mediaspansoftware.com>.
On May 7, 2007, at 4:09 PM, Gert Vanthienen wrote:
>
> L.S.,
>
>
> I think an ESB solution, such as ServiceMix, can provide you with a
> lot of
> the features you require:
> - flexible protocol handling and bridging
> - loose coupling
> - routing services
> - dynamic endpoints
>
> Using ServiceMix as the foundation for your solution would allow
> you to
> leverage these features and to invest your development efforts on
> the SE you
> will be using in step 3 of the flow you describe. If I understand
> your
> requirements correctly, you would want to build some kind of
> tooling to
> easily assemble and deploy these workflows (as service assemblies).
>
I hadn't thought about using the service assembly as the driver for
completing a work order. In some cases our customers may build
hundreds of work orders, and we'd have to manage a service assembly
for each. That may be workable (although it seems more involved than
what I was originally thinking about). My original idea was to have
one service assembly that simply defined the various SEs, etc. needed
and their roles and have the routing done dynamically by each SE (via
the RoutingSlip approach I mentioned in the original mail that is
created based on a work order definition file).
On a different note, can service assemblies be scheduled for
automatic execution (i.e. perform this work-flow of services every
day at 3 a.m.)? That is another requirement of the application.
Regards,
Scott
> Is this the kind of solution you're envisioning or am I missing
> something?
>
>
> Regards,
>
> Gert
>
>
>
>
> Scott Johnson-16 wrote:
>>
>> I am in the process of evaluating various integration/component
>> technologies for a forthcoming application I will be charged with
>> developing.
>>
>> The purpose of the application is to be a means by which our
>> customers can perform batch operations on a selection of resources.
>> The customers define "work orders" that instruct the application to
>> perform a series of steps to accomplish the customer's goals. The
>> customers then instruct the application to perform those work orders.
>> That is the most important point: this process is completely
>> customer-
>> driven and the customer can create any number of work-flows. I cannot
>> hard-code a Service Assembly to, say, get text files from this FTP
>> location, route them through the English-to-German translator, and
>> put them on the local hard drive. At the time of creating the
>> application I don't know what the work flows are specifically (just
>> that they involve using the services my application provides).
>>
>> I have been looking into ESB, OSGi (both new approaches for me) or
>> just using hand-rolled code to solve the problem. Initially ESB and
>> OSGi seemed to be reasonably perfect matches, but the more I work
>> with an ESB solution, the more frustrated I become.
>>
>> For my prototype application I envisioned the following pieces I'd
>> need to create for an ESB solution:
>>
>> 1. Bridge from HTTP to JMS:
>> a. HTTP endpoint for inbound requests (seems a reasonable way to
>> trigger the execution of a work order for this prototype)
>> b. EIP pipeline to transform and place request (which is the "work
>> order") onto a JMS Queue
>> 2. JMS consumer of above JMS queue whose destination service is...
>> 3. Custom SE1 - A component that parses the work order and forwards
>> to the first component listed, which is...
>> 4. Custom SE2 - A component that performs the first work order
>> process then forwards the work order to...
>> 5. Custom SE3 - A component that performs the second work order
>> process, then forwards the work order to...
>> 6. Custom BC2 - An output component that places the resource to a
>> specific location.
>>
>> Note 1: depending on the work order, there could be any number of
>> custom SEs involved between steps 3 and 6 above.
>>
>> Note 2: none of the custom SE/BCs know about each other (as it should
>> be) but all know about a RoutingSlip object that is passed as a
>> property on the ME. Each SE designates the next service to be called
>> based on that routing slip (which was generated by the initial
>> component, #3 above) until the work order is complete.
>>
>> Note 3: I have created Service Units for all the SEs which are all
>> designated as providers.
>>
>> I'm having lots of issues getting this to work (some due to the
>> newness of ServiceMix and JBI to me, certainly) but, before I get
>> much farther I would like to ask: does this type of dynamic work flow
>> really align with the goals of an ESB and is it well supported or am
>> I barking up the wrong tree here?
>>
>> Thanks for your time,
>> Scott
>>
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Is-ServiceMix-
> JBI-a-Good-Fit-for-Dynamic-Processing--tf3705460s12049.html#a10364510
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
Re: Is ServiceMix/JBI a Good Fit for Dynamic Processing?
Posted by Gert Vanthienen <ge...@skynet.be>.
L.S.,
I think an ESB solution, such as ServiceMix, can provide you with a lot of
the features you require:
- flexible protocol handling and bridging
- loose coupling
- routing services
- dynamic endpoints
Using ServiceMix as the foundation for your solution would allow you to
leverage these features and to invest your development efforts on the SE you
will be using in step 3 of the flow you describe. If I understand your
requirements correctly, you would want to build some kind of tooling to
easily assemble and deploy these workflows (as service assemblies).
Is this the kind of solution you're envisioning or am I missing something?
Regards,
Gert
Scott Johnson-16 wrote:
>
> I am in the process of evaluating various integration/component
> technologies for a forthcoming application I will be charged with
> developing.
>
> The purpose of the application is to be a means by which our
> customers can perform batch operations on a selection of resources.
> The customers define "work orders" that instruct the application to
> perform a series of steps to accomplish the customer's goals. The
> customers then instruct the application to perform those work orders.
> That is the most important point: this process is completely customer-
> driven and the customer can create any number of work-flows. I cannot
> hard-code a Service Assembly to, say, get text files from this FTP
> location, route them through the English-to-German translator, and
> put them on the local hard drive. At the time of creating the
> application I don't know what the work flows are specifically (just
> that they involve using the services my application provides).
>
> I have been looking into ESB, OSGi (both new approaches for me) or
> just using hand-rolled code to solve the problem. Initially ESB and
> OSGi seemed to be reasonably perfect matches, but the more I work
> with an ESB solution, the more frustrated I become.
>
> For my prototype application I envisioned the following pieces I'd
> need to create for an ESB solution:
>
> 1. Bridge from HTTP to JMS:
> a. HTTP endpoint for inbound requests (seems a reasonable way to
> trigger the execution of a work order for this prototype)
> b. EIP pipeline to transform and place request (which is the "work
> order") onto a JMS Queue
> 2. JMS consumer of above JMS queue whose destination service is...
> 3. Custom SE1 - A component that parses the work order and forwards
> to the first component listed, which is...
> 4. Custom SE2 - A component that performs the first work order
> process then forwards the work order to...
> 5. Custom SE3 - A component that performs the second work order
> process, then forwards the work order to...
> 6. Custom BC2 - An output component that places the resource to a
> specific location.
>
> Note 1: depending on the work order, there could be any number of
> custom SEs involved between steps 3 and 6 above.
>
> Note 2: none of the custom SE/BCs know about each other (as it should
> be) but all know about a RoutingSlip object that is passed as a
> property on the ME. Each SE designates the next service to be called
> based on that routing slip (which was generated by the initial
> component, #3 above) until the work order is complete.
>
> Note 3: I have created Service Units for all the SEs which are all
> designated as providers.
>
> I'm having lots of issues getting this to work (some due to the
> newness of ServiceMix and JBI to me, certainly) but, before I get
> much farther I would like to ask: does this type of dynamic work flow
> really align with the goals of an ESB and is it well supported or am
> I barking up the wrong tree here?
>
> Thanks for your time,
> Scott
>
>
>
>
>
--
View this message in context: http://www.nabble.com/Is-ServiceMix-JBI-a-Good-Fit-for-Dynamic-Processing--tf3705460s12049.html#a10364510
Sent from the ServiceMix - User mailing list archive at Nabble.com.