You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Nodet Guillaume <gn...@gmail.com> on 2007/08/22 16:59:28 UTC
ServiceMix 4.0
As I explained in the other thread, I've been working on a new API
for ServiceMix 4.0.
Hopefully this will serve as an input for JBI 2.0.
This API is available at https://svn.apache.org/repos/asf/incubator/
servicemix/branches/servicemix-4.0/api
So here a few key changes:
* clean integration with OSGi
* the NormalizedMessage can contain not only XML
* no more components
* no more JBI packaging (just use OSGi bundles)
* move the Channel to the Endpoint
* use push delivery instead of pulling exchanges
* introduce a single interface for identifying the Target of an
Exchange
As we remove components, everything goes down to the endpoint which
become a key feature.
The endpoint must implement the Endpoint interface. In OSGi, the NMR
would listen to endpoints
registered in the OSGi registry and call the registry to register /
unregister the endpoints.
As part of the endpoint registration, the NMR would inject a Channel
into them, thus actually activating the
endpoint. I guess I could write a sequence diagram for that (anybody
knows a good tool for uml ?).
In a non OSGI environment, the Endpoint will be registered in the
Registry by calling the register method
somehow.
The Endpoint receives Exchange to be processed on the process method.
I think we should keep the JBI 1.0 semantics and the endpoint use the
same process as for JBI 1.0, which is
send the exchange back using the Channel (with the response / fault /
error / done). This will put the threading,
transactions and security burden on the container itself. Which
means it is easier to write JBI apps :-)
Exchanges can be created using the Channel#createExchange method.
The only change I'd like to
integrate in the messaging API is to allow for non xml payloads and
maybe untyped attachments. The body
could be converted automatically to a given type if supported (I
think Camel does it nicely, so I'm thinking of
shamelessly copying the converter layer). I have added a few helper
methods on the exchanges and
messages (copy, copyFrom, ensureReReadable, display) to ease message
management.
For the deployment part, there is no packaging anymore. One would
deploy an OSGi bundle that would
register the needed endpoints in the OSGi registry. For certain
types of endpoints, we may need an external
activation process (such as creating a server socket for listening to
HTTP requests) that may need to be shared
across endpoints of a given type. In such a case, you would deploy a
"component" that listens to new
endpoints implementing HttpEndpoint for example. When a new endpoint
is registered, the listener would
activate a server socket that could be shared across all http
endpoints. In a different way, if we have a BPEL
engine, the bpel "component" would listen for new bundles and look
for a specific file containing deployment
information. The component would register new endpoints in the OSGi
registry as needed (we could do that
for jaxws pojos using cxf for example).
So I said there is no more components, because this feature is not in
the api anymore, but we will certainly need
these components for some use cases. For simple endpoints, you
would not need any component at all.
Another benefit is that you can easily deploy a whole application
inside a single OSGi bundle. Using spring-osgi,
the bundle would just consist in a spring configuration file
containing the endpoints declaration and expose them
as OSGi services.
Of course, we need to write a JBI 1.0 compatibility layer, and we
could have an intermediate layer where SAs and
JBI components could be OSGi bundles directly, thus leveraging the
OSGi classloading mechanism.
The thing I'm not completely sure about if the Target interface which
aims to identify the target of an exchange.
I'm thinking that some metadata are associated with endpoints (like
service name, interface name, wsdl
location, etc..). These metadatas could be used to retrieve targets
using the Registry. We could plug in different
mechanisms to query the metadata (simple lookup per id, policy based,
etc...). And the result itself could be
not only a single Endpoint, but could include some policies like:
load balance between all the endpoint implementing
the given interface, etc.... Also, I think Target should be injected
on Endpoints using spring, so you would look up a
targe using a spring bean factory (or multiple ones):
<smx:endpoint-target id="my-endoint-id" />
or
<smx:interface-target name="my:qname" />
The API is quite open right now, so any ideas welcome.
I think i covered the main areas of the API. The main goal is OSGi
and leveraging it as much as possible. There are
still some gray areas: what about the start/stop/shutdown lifecycle
which may be needed in some cases as I
discovered recently (when you want to gracefully shutdown a jms
consumer without loosing the ongoing messages
for example). I also want to give due credits to James, which has
been working with me on that.
Remember that nothing can't be changed and that' s why I'm asking for
feedback at this early stage, where there are
only ideas ;-)
Feedback welcome....
Cheers,
Guillaume Nodet
Re: ServiceMix 4.0
Posted by Nodet Guillaume <gn...@gmail.com>.
On Aug 23, 2007, at 10:03 AM, Nodet Guillaume wrote:
>
> On Aug 23, 2007, at 5:41 AM, Brian O'Neill wrote:
>>
>>
>>> Exchanges can be created using the Channel#createExchange method.
>>> The only change I'd like to
>>> integrate in the messaging API is to allow for non xml payloads and
>>> maybe untyped attachments. The body
>>> could be converted automatically to a given type if supported (I
>>> think Camel does it nicely, so I'm thinking of
>>> shamelessly copying the converter layer). I have added a few helper
>>> methods on the exchanges and
>>> messages (copy, copyFrom, ensureReReadable, display) to ease message
>>> management.
>>>
>>
>> I haven't looked at Camel converters, but would you consider adding a
>> contentType and contentEncoding mimicing the headers of HTTP & SIP.
>> The endpoint can then use the type and encoding to determine how to
>> handle the content.
>
> I'm open. Would the contentType be a mime type? In such a case it
> is not
> sufficient to know how the content is represented. For example if
> the content
> type is xml, you can still have a plain stream, a Source or a DOM
> document.
> Camel converters may help here. Type converters are explained at
> http://activemq.apache.org/camel/type-converter.html
Btw, it makes me think of another related issue. Should we add
headers to the attachments, where
the attachment would be an Object + a set of headers rather than just
the object? Usually attachments
come from a mime request and some headers may be associated with
them. As anyone ever seen the
need to obtain these attachments? I know CXF keep them, so I'm quite
sure there is a good reason.
Cheers,
Guillaume Nodet
Re: ServiceMix 4.0
Posted by Nodet Guillaume <gn...@gmail.com>.
On Aug 23, 2007, at 5:41 AM, Brian O'Neill wrote:
> Fanastic. Once we get consensus on the direction (your first few
> points), I wonder if we shouldn't break this email out to discuss the
> specifics.
Yeah, good idea!
>
> On 8/22/07, Nodet Guillaume <gn...@gmail.com> wrote:
>> As I explained in the other thread, I've been working on a new API
>> for ServiceMix 4.0.
>> Hopefully this will serve as an input for JBI 2.0.
>> This API is available at https://svn.apache.org/repos/asf/incubator/
>> servicemix/branches/servicemix-4.0/api
>>
>> So here a few key changes:
>> * clean integration with OSGi
>> * the NormalizedMessage can contain not only XML
>> * no more components
>> * no more JBI packaging (just use OSGi bundles)
>> * move the Channel to the Endpoint
>> * use push delivery instead of pulling exchanges
>> * introduce a single interface for identifying the Target of an
>> Exchange
>
> Excellent! Spot on.
>
>> As we remove components, everything goes down to the endpoint which
>> become a key feature.
>>
>> The endpoint must implement the Endpoint interface. In OSGi, the NMR
>> would listen to endpoints
>> registered in the OSGi registry and call the registry to register /
>> unregister the endpoints.
>> As part of the endpoint registration, the NMR would inject a Channel
>> into them, thus actually activating the
>> endpoint. I guess I could write a sequence diagram for that (anybody
>> knows a good tool for uml ?).
>> In a non OSGI environment, the Endpoint will be registered in the
>> Registry by calling the register method
>> somehow.
>
> RE: uml tool
> Bruce, I've struggled with the same. I actually run
> Parallels/VMWare+Visio, just to keep compatibility with others I have
> to interact with. FLOSS community desperately needs a architecture
> tool.
>
>> The Endpoint receives Exchange to be processed on the process method.
>> I think we should keep the JBI 1.0 semantics and the endpoint use the
>> same process as for JBI 1.0, which is
>> send the exchange back using the Channel (with the response / fault /
>> error / done). This will put the threading,
>> transactions and security burden on the container itself. Which
>> means it is easier to write JBI apps :-)
>
> +1
>
>> Exchanges can be created using the Channel#createExchange method.
>> The only change I'd like to
>> integrate in the messaging API is to allow for non xml payloads and
>> maybe untyped attachments. The body
>> could be converted automatically to a given type if supported (I
>> think Camel does it nicely, so I'm thinking of
>> shamelessly copying the converter layer). I have added a few helper
>> methods on the exchanges and
>> messages (copy, copyFrom, ensureReReadable, display) to ease message
>> management.
>>
>
> I haven't looked at Camel converters, but would you consider adding a
> contentType and contentEncoding mimicing the headers of HTTP & SIP.
> The endpoint can then use the type and encoding to determine how to
> handle the content.
I'm open. Would the contentType be a mime type? In such a case it
is not
sufficient to know how the content is represented. For example if
the content
type is xml, you can still have a plain stream, a Source or a DOM
document.
Camel converters may help here. Type converters are explained at
http://activemq.apache.org/camel/type-converter.html
>
>> For the deployment part, there is no packaging anymore. One would
>> deploy an OSGi bundle that would
>> register the needed endpoints in the OSGi registry. For certain
>> types of endpoints, we may need an external
>> activation process (such as creating a server socket for listening to
>> HTTP requests) that may need to be shared
>> across endpoints of a given type. In such a case, you would deploy a
>> "component" that listens to new
>> endpoints implementing HttpEndpoint for example. When a new endpoint
>> is registered, the listener would
>> activate a server socket that could be shared across all http
>> endpoints. In a different way, if we have a BPEL
>> engine, the bpel "component" would listen for new bundles and look
>> for a specific file containing deployment
>> information. The component would register new endpoints in the OSGi
>> registry as needed (we could do that
>> for jaxws pojos using cxf for example).
>> So I said there is no more components, because this feature is not in
>> the api anymore, but we will certainly need
>> these components for some use cases. For simple endpoints, you
>> would not need any component at all.
>> Another benefit is that you can easily deploy a whole application
>> inside a single OSGi bundle. Using spring-osgi,
>> the bundle would just consist in a spring configuration file
>> containing the endpoints declaration and expose them
>> as OSGi services.
>
> sweet.
>
>> Of course, we need to write a JBI 1.0 compatibility layer, and we
>> could have an intermediate layer where SAs and
>> JBI components could be OSGi bundles directly, thus leveraging the
>> OSGi classloading mechanism.
>>
>> The thing I'm not completely sure about if the Target interface which
>> aims to identify the target of an exchange.
>> I'm thinking that some metadata are associated with endpoints (like
>> service name, interface name, wsdl
>> location, etc..). These metadatas could be used to retrieve targets
>> using the Registry. We could plug in different
>> mechanisms to query the metadata (simple lookup per id, policy based,
>> etc...). And the result itself could be
>> not only a single Endpoint, but could include some policies like:
>> load balance between all the endpoint implementing
>> the given interface, etc.... Also, I think Target should be injected
>> on Endpoints using spring, so you would look up a
>> targe using a spring bean factory (or multiple ones):
>> <smx:endpoint-target id="my-endoint-id" />
>> or
>> <smx:interface-target name="my:qname" />
>> The API is quite open right now, so any ideas welcome.
>>
>> I think i covered the main areas of the API. The main goal is OSGi
>> and leveraging it as much as possible. There are
>> still some gray areas: what about the start/stop/shutdown lifecycle
>> which may be needed in some cases as I
>> discovered recently (when you want to gracefully shutdown a jms
>> consumer without loosing the ongoing messages
>> for example). I also want to give due credits to James, which has
>> been working with me on that.
>> Remember that nothing can't be changed and that' s why I'm asking for
>> feedback at this early stage, where there are
>> only ideas ;-)
>>
>> Feedback welcome....
>>
>> Cheers,
>> Guillaume Nodet
>
> Any idea what the time-lines are for 4.0? or the general roadmap?
> (would you try to move some of the components over to the new API
> (with mock tests) before migrating the infrastructure? If so, i may
> be able to lend a hand there.
>
We need to flesh that out. But all help is welcome.
I'm thinking about early 2008 for the first release. JBI 2.0 and SCA
could
come late 2008.
There are a few areas where the work can be split:
* core NMR and API implementation
* port servicemix-common which will somehow be part of the container
* port the existing components (we need to define a strategy,
which one and how)
* compatibility layer
* distribution and examples
* documentation
When you say move of some of the components to the new API, are you
talking about
a JBI 1.0 compatibility layer or changing the component to support
natively the new API?
Cheers,
Guillaume Nodet
> nice work.
>
> -brian
>
> --
> Brian ONeill
> Source Equity (http://www.sourceequity.com)
> jBIZint (http://www.jbizint.org)
> Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
> mobile:215.588.6024
Re: ServiceMix 4.0
Posted by Brian O'Neill <bo...@alumni.brown.edu>.
Fanastic. Once we get consensus on the direction (your first few
points), I wonder if we shouldn't break this email out to discuss the
specifics.
On 8/22/07, Nodet Guillaume <gn...@gmail.com> wrote:
> As I explained in the other thread, I've been working on a new API
> for ServiceMix 4.0.
> Hopefully this will serve as an input for JBI 2.0.
> This API is available at https://svn.apache.org/repos/asf/incubator/
> servicemix/branches/servicemix-4.0/api
>
> So here a few key changes:
> * clean integration with OSGi
> * the NormalizedMessage can contain not only XML
> * no more components
> * no more JBI packaging (just use OSGi bundles)
> * move the Channel to the Endpoint
> * use push delivery instead of pulling exchanges
> * introduce a single interface for identifying the Target of an
> Exchange
Excellent! Spot on.
> As we remove components, everything goes down to the endpoint which
> become a key feature.
>
> The endpoint must implement the Endpoint interface. In OSGi, the NMR
> would listen to endpoints
> registered in the OSGi registry and call the registry to register /
> unregister the endpoints.
> As part of the endpoint registration, the NMR would inject a Channel
> into them, thus actually activating the
> endpoint. I guess I could write a sequence diagram for that (anybody
> knows a good tool for uml ?).
> In a non OSGI environment, the Endpoint will be registered in the
> Registry by calling the register method
> somehow.
RE: uml tool
Bruce, I've struggled with the same. I actually run
Parallels/VMWare+Visio, just to keep compatibility with others I have
to interact with. FLOSS community desperately needs a architecture
tool.
> The Endpoint receives Exchange to be processed on the process method.
> I think we should keep the JBI 1.0 semantics and the endpoint use the
> same process as for JBI 1.0, which is
> send the exchange back using the Channel (with the response / fault /
> error / done). This will put the threading,
> transactions and security burden on the container itself. Which
> means it is easier to write JBI apps :-)
+1
> Exchanges can be created using the Channel#createExchange method.
> The only change I'd like to
> integrate in the messaging API is to allow for non xml payloads and
> maybe untyped attachments. The body
> could be converted automatically to a given type if supported (I
> think Camel does it nicely, so I'm thinking of
> shamelessly copying the converter layer). I have added a few helper
> methods on the exchanges and
> messages (copy, copyFrom, ensureReReadable, display) to ease message
> management.
>
I haven't looked at Camel converters, but would you consider adding a
contentType and contentEncoding mimicing the headers of HTTP & SIP.
The endpoint can then use the type and encoding to determine how to
handle the content.
> For the deployment part, there is no packaging anymore. One would
> deploy an OSGi bundle that would
> register the needed endpoints in the OSGi registry. For certain
> types of endpoints, we may need an external
> activation process (such as creating a server socket for listening to
> HTTP requests) that may need to be shared
> across endpoints of a given type. In such a case, you would deploy a
> "component" that listens to new
> endpoints implementing HttpEndpoint for example. When a new endpoint
> is registered, the listener would
> activate a server socket that could be shared across all http
> endpoints. In a different way, if we have a BPEL
> engine, the bpel "component" would listen for new bundles and look
> for a specific file containing deployment
> information. The component would register new endpoints in the OSGi
> registry as needed (we could do that
> for jaxws pojos using cxf for example).
> So I said there is no more components, because this feature is not in
> the api anymore, but we will certainly need
> these components for some use cases. For simple endpoints, you
> would not need any component at all.
> Another benefit is that you can easily deploy a whole application
> inside a single OSGi bundle. Using spring-osgi,
> the bundle would just consist in a spring configuration file
> containing the endpoints declaration and expose them
> as OSGi services.
sweet.
> Of course, we need to write a JBI 1.0 compatibility layer, and we
> could have an intermediate layer where SAs and
> JBI components could be OSGi bundles directly, thus leveraging the
> OSGi classloading mechanism.
>
> The thing I'm not completely sure about if the Target interface which
> aims to identify the target of an exchange.
> I'm thinking that some metadata are associated with endpoints (like
> service name, interface name, wsdl
> location, etc..). These metadatas could be used to retrieve targets
> using the Registry. We could plug in different
> mechanisms to query the metadata (simple lookup per id, policy based,
> etc...). And the result itself could be
> not only a single Endpoint, but could include some policies like:
> load balance between all the endpoint implementing
> the given interface, etc.... Also, I think Target should be injected
> on Endpoints using spring, so you would look up a
> targe using a spring bean factory (or multiple ones):
> <smx:endpoint-target id="my-endoint-id" />
> or
> <smx:interface-target name="my:qname" />
> The API is quite open right now, so any ideas welcome.
>
> I think i covered the main areas of the API. The main goal is OSGi
> and leveraging it as much as possible. There are
> still some gray areas: what about the start/stop/shutdown lifecycle
> which may be needed in some cases as I
> discovered recently (when you want to gracefully shutdown a jms
> consumer without loosing the ongoing messages
> for example). I also want to give due credits to James, which has
> been working with me on that.
> Remember that nothing can't be changed and that' s why I'm asking for
> feedback at this early stage, where there are
> only ideas ;-)
>
> Feedback welcome....
>
> Cheers,
> Guillaume Nodet
Any idea what the time-lines are for 4.0? or the general roadmap?
(would you try to move some of the components over to the new API
(with mock tests) before migrating the infrastructure? If so, i may
be able to lend a hand there.
nice work.
-brian
--
Brian ONeill
Source Equity (http://www.sourceequity.com)
jBIZint (http://www.jbizint.org)
Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
mobile:215.588.6024
Re: ServiceMix 4.0
Posted by Nodet Guillaume <gn...@gmail.com>.
On Aug 22, 2007, at 11:43 PM, Bruce Snyder wrote:
> On 8/22/07, Nodet Guillaume <gn...@gmail.com> wrote:
>> As I explained in the other thread, I've been working on a new API
>> for ServiceMix 4.0.
>> Hopefully this will serve as an input for JBI 2.0.
>> This API is available at https://svn.apache.org/repos/asf/incubator/
>> servicemix/branches/servicemix-4.0/api
>>
>> So here a few key changes:
>> * clean integration with OSGi
>> * the NormalizedMessage can contain not only XML
>
> Nice!
>
>> * no more components
>> * no more JBI packaging (just use OSGi bundles)
>> * move the Channel to the Endpoint
>> * use push delivery instead of pulling exchanges
>
> This is an interesting change for sure.
>
>> * introduce a single interface for identifying the Target of an
>> Exchange
>
> How will this work? Can you explain this one a bit more?
Basically, instead of having different ways to express how the
exchange will be routed by the NMR
(using the endpoint, the service name or the interface name), there
would be only a single way to express
the destination using a Reference object (not Target, sorry). These
objects would represent either a specific
endpoint, or a service by its name or interface name, or more complex
policies that could be built.
These objects would be looked up in the Registry using a single
method. Depending on the metadata passed
to this method, you would retrieve an object that you can use as the
target.
Btw, for simple use cases, we should avoid needing a service QName +
endpoint name to uniquely identify
an endpoint. An unique ID should be sufficient. Everything else
should be optional.
Hopefuly you would not have to deal with that the lookup directly and
you would use spring beans factories
for that, so that you can easily inject References and use them as
target in your endpoints.
>
>> As we remove components, everything goes down to the endpoint which
>> become a key feature.
>>
>> The endpoint must implement the Endpoint interface. In OSGi, the NMR
>> would listen to endpoints
>> registered in the OSGi registry and call the registry to register /
>> unregister the endpoints.
>> As part of the endpoint registration, the NMR would inject a Channel
>> into them, thus actually activating the
>> endpoint. I guess I could write a sequence diagram for that (anybody
>> knows a good tool for uml ?).
>
> I've been trying to find some good UML software for a while -
> something that doesn't cost an arm and a leg, that generates sequence
> diagrams (IMO, these are invaluable!) from code and that runs on MacOS
> X. Anyone know of something that meets this criteria?
>
>> In a non OSGI environment, the Endpoint will be registered in the
>> Registry by calling the register method
>> somehow.
>
> Is there any interoperability between the OSGi registry and a UDDI
> registry?
Not really. But i'm sure we could add that as an optional feature if
needed (but does anyone
really need to use a UDDI registry?)
OSGi registry contains services implementing a java interface with
some associated metadata,
while UDDI contains xml document (and mainly WSDL in our use case).
They can complement
together, but I'd really want to keep WSDL as completely optional.
>
>> The Endpoint receives Exchange to be processed on the process method.
>> I think we should keep the JBI 1.0 semantics and the endpoint use the
>> same process as for JBI 1.0, which is
>> send the exchange back using the Channel (with the response / fault /
>> error / done). This will put the threading,
>> transactions and security burden on the container itself. Which
>> means it is easier to write JBI apps :-)
>
> This is exactly the architecture we need - a much cleaner separation.
>
>> Exchanges can be created using the Channel#createExchange method.
>> The only change I'd like to
>> integrate in the messaging API is to allow for non xml payloads and
>> maybe untyped attachments. The body
>> could be converted automatically to a given type if supported (I
>> think Camel does it nicely, so I'm thinking of
>> shamelessly copying the converter layer). I have added a few helper
>> methods on the exchanges and
>> messages (copy, copyFrom, ensureReReadable, display) to ease message
>> management.
>
> Very nice, sounds similar to Spring convenience classes.
>
>> For the deployment part, there is no packaging anymore. One would
>> deploy an OSGi bundle that would
>> register the needed endpoints in the OSGi registry. For certain
>> types of endpoints, we may need an external
>> activation process (such as creating a server socket for listening to
>> HTTP requests) that may need to be shared
>> across endpoints of a given type. In such a case, you would deploy a
>> "component" that listens to new
>> endpoints implementing HttpEndpoint for example. When a new endpoint
>> is registered, the listener would
>> activate a server socket that could be shared across all http
>> endpoints. In a different way, if we have a BPEL
>> engine, the bpel "component" would listen for new bundles and look
>> for a specific file containing deployment
>> information. The component would register new endpoints in the OSGi
>> registry as needed (we could do that
>> for jaxws pojos using cxf for example).
>> So I said there is no more components, because this feature is not in
>> the api anymore, but we will certainly need
>> these components for some use cases. For simple endpoints, you
>> would not need any component at all.
>> Another benefit is that you can easily deploy a whole application
>> inside a single OSGi bundle. Using spring-osgi,
>> the bundle would just consist in a spring configuration file
>> containing the endpoints declaration and expose them
>> as OSGi services.
>
> I'm not sure I understand this completely. Is this a type of
> interceptor or am I misunderstanding you?
Well, somewhat yeah. OSGi defines several kind of calbacks that you
can register
in the OSGi framework. They can be called when a service is
registered / unregistered,
or when a bundle is started / stopped.
>
>> Of course, we need to write a JBI 1.0 compatibility layer, and we
>> could have an intermediate layer where SAs and
>> JBI components could be OSGi bundles directly, thus leveraging the
>> OSGi classloading mechanism.
>
> Yep.
>
>> The thing I'm not completely sure about if the Target interface which
>> aims to identify the target of an exchange.
>> I'm thinking that some metadata are associated with endpoints (like
>> service name, interface name, wsdl
>> location, etc..). These metadatas could be used to retrieve targets
>> using the Registry. We could plug in different
>> mechanisms to query the metadata (simple lookup per id, policy based,
>> etc...). And the result itself could be
>> not only a single Endpoint, but could include some policies like:
>> load balance between all the endpoint implementing
>> the given interface, etc.... Also, I think Target should be injected
>> on Endpoints using spring, so you would look up a
>> targe using a spring bean factory (or multiple ones):
>> <smx:endpoint-target id="my-endoint-id" />
>> or
>> <smx:interface-target name="my:qname" />
>> The API is quite open right now, so any ideas welcome.
>
> Very nice!
>
>> I think i covered the main areas of the API. The main goal is OSGi
>> and leveraging it as much as possible. There are
>> still some gray areas: what about the start/stop/shutdown lifecycle
>> which may be needed in some cases as I
>> discovered recently (when you want to gracefully shutdown a jms
>> consumer without loosing the ongoing messages
>> for example). I also want to give due credits to James, which has
>> been working with me on that.
>> Remember that nothing can't be changed and that' s why I'm asking for
>> feedback at this early stage, where there are
>> only ideas ;-)
>
> Yes, the lifecycle is a must so that messages are not dropped. I know
> that OSGi provides a lifecycle for bundles, how does this affect what
> you mention above?
OSGi lifecycle only has two states (started / stopped) mainly (at
least for the
services). I think for some use cases, we would need three states
(started / stopped / shutdown) but I have no idea how to implement that.
Maybe going from start to stop should just be graceful enough to wait
for pending
exchanges. I will send an email to felix dev list to ask about that
at some point.
Guillaume
>
> 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: ServiceMix 4.0
Posted by Bruce Snyder <br...@gmail.com>.
On 8/22/07, Nodet Guillaume <gn...@gmail.com> wrote:
> As I explained in the other thread, I've been working on a new API
> for ServiceMix 4.0.
> Hopefully this will serve as an input for JBI 2.0.
> This API is available at https://svn.apache.org/repos/asf/incubator/
> servicemix/branches/servicemix-4.0/api
>
> So here a few key changes:
> * clean integration with OSGi
> * the NormalizedMessage can contain not only XML
Nice!
> * no more components
> * no more JBI packaging (just use OSGi bundles)
> * move the Channel to the Endpoint
> * use push delivery instead of pulling exchanges
This is an interesting change for sure.
> * introduce a single interface for identifying the Target of an
> Exchange
How will this work? Can you explain this one a bit more?
> As we remove components, everything goes down to the endpoint which
> become a key feature.
>
> The endpoint must implement the Endpoint interface. In OSGi, the NMR
> would listen to endpoints
> registered in the OSGi registry and call the registry to register /
> unregister the endpoints.
> As part of the endpoint registration, the NMR would inject a Channel
> into them, thus actually activating the
> endpoint. I guess I could write a sequence diagram for that (anybody
> knows a good tool for uml ?).
I've been trying to find some good UML software for a while -
something that doesn't cost an arm and a leg, that generates sequence
diagrams (IMO, these are invaluable!) from code and that runs on MacOS
X. Anyone know of something that meets this criteria?
> In a non OSGI environment, the Endpoint will be registered in the
> Registry by calling the register method
> somehow.
Is there any interoperability between the OSGi registry and a UDDI registry?
> The Endpoint receives Exchange to be processed on the process method.
> I think we should keep the JBI 1.0 semantics and the endpoint use the
> same process as for JBI 1.0, which is
> send the exchange back using the Channel (with the response / fault /
> error / done). This will put the threading,
> transactions and security burden on the container itself. Which
> means it is easier to write JBI apps :-)
This is exactly the architecture we need - a much cleaner separation.
> Exchanges can be created using the Channel#createExchange method.
> The only change I'd like to
> integrate in the messaging API is to allow for non xml payloads and
> maybe untyped attachments. The body
> could be converted automatically to a given type if supported (I
> think Camel does it nicely, so I'm thinking of
> shamelessly copying the converter layer). I have added a few helper
> methods on the exchanges and
> messages (copy, copyFrom, ensureReReadable, display) to ease message
> management.
Very nice, sounds similar to Spring convenience classes.
> For the deployment part, there is no packaging anymore. One would
> deploy an OSGi bundle that would
> register the needed endpoints in the OSGi registry. For certain
> types of endpoints, we may need an external
> activation process (such as creating a server socket for listening to
> HTTP requests) that may need to be shared
> across endpoints of a given type. In such a case, you would deploy a
> "component" that listens to new
> endpoints implementing HttpEndpoint for example. When a new endpoint
> is registered, the listener would
> activate a server socket that could be shared across all http
> endpoints. In a different way, if we have a BPEL
> engine, the bpel "component" would listen for new bundles and look
> for a specific file containing deployment
> information. The component would register new endpoints in the OSGi
> registry as needed (we could do that
> for jaxws pojos using cxf for example).
> So I said there is no more components, because this feature is not in
> the api anymore, but we will certainly need
> these components for some use cases. For simple endpoints, you
> would not need any component at all.
> Another benefit is that you can easily deploy a whole application
> inside a single OSGi bundle. Using spring-osgi,
> the bundle would just consist in a spring configuration file
> containing the endpoints declaration and expose them
> as OSGi services.
I'm not sure I understand this completely. Is this a type of
interceptor or am I misunderstanding you?
> Of course, we need to write a JBI 1.0 compatibility layer, and we
> could have an intermediate layer where SAs and
> JBI components could be OSGi bundles directly, thus leveraging the
> OSGi classloading mechanism.
Yep.
> The thing I'm not completely sure about if the Target interface which
> aims to identify the target of an exchange.
> I'm thinking that some metadata are associated with endpoints (like
> service name, interface name, wsdl
> location, etc..). These metadatas could be used to retrieve targets
> using the Registry. We could plug in different
> mechanisms to query the metadata (simple lookup per id, policy based,
> etc...). And the result itself could be
> not only a single Endpoint, but could include some policies like:
> load balance between all the endpoint implementing
> the given interface, etc.... Also, I think Target should be injected
> on Endpoints using spring, so you would look up a
> targe using a spring bean factory (or multiple ones):
> <smx:endpoint-target id="my-endoint-id" />
> or
> <smx:interface-target name="my:qname" />
> The API is quite open right now, so any ideas welcome.
Very nice!
> I think i covered the main areas of the API. The main goal is OSGi
> and leveraging it as much as possible. There are
> still some gray areas: what about the start/stop/shutdown lifecycle
> which may be needed in some cases as I
> discovered recently (when you want to gracefully shutdown a jms
> consumer without loosing the ongoing messages
> for example). I also want to give due credits to James, which has
> been working with me on that.
> Remember that nothing can't be changed and that' s why I'm asking for
> feedback at this early stage, where there are
> only ideas ;-)
Yes, the lifecycle is a must so that messages are not dropped. I know
that OSGi provides a lifecycle for bundles, how does this affect what
you mention above?
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: ServiceMix 4.0
Posted by Gregor Kovač <gr...@mikropis.si>.
Hi!
Sorry to drop in like this, but have you tried
http://argouml.tigris.org/ ?
Best regards,
Kovi
Dne 23.08.2007 (čet) ob 14:21 -0600 je Bruce Snyder zapisal(a):
> On 8/23/07, Kit Plummer <ki...@gmail.com> wrote:
>
> > I've used MagicDraw on OS X. It's pretty terrible...but does work for
> > sequence diagrams. I'm not sure if they have a "free" version or not.
> > Doesn't OmniGraffle do some UML stuff too?
>
> Yeah I've used MagicDraw in the past. Unfortunately the free version
> doesn't generate sequence diagrams and that's the key for me. I want
> the ability to have the tool generate UML from the source and that's
> hard to find in a free tool.
>
> Bruce
--
____________________________
|http://kovica.blogspot.com|
-----------------------------~-~-~-~-~-~-~-~-~-~-
| In A World Without Fences Who Needs Gates? |
| Experience Linux. |
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Re: ServiceMix 4.0
Posted by Guillaume Nodet <gn...@gmail.com>.
On 8/24/07, Adrian Co <ac...@exist.com> wrote:
> Not sure if this is the right forum to bring this up, but I was
> wondering if this is a good opportunity to migrate some of servicemix's
> infra to newer version.
>
> i.e.
>
> 1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
> I'm not sure if its a better option, but I did hear some good stuff
> about it.
Why not ? I'm not sure about the pros and cons here, but I'm open :-)
> 2. Upgrade to junit 4.x (Port the existing test cases maybe?)
+1 to move to junit 4 (or testng ? i haven't tried any)
>
> and maybe others.
>
> Just my 2 cents. :)
>
> Daryl Richter wrote:
> >
> > On Aug 23, 2007, at 4:21 PM, Bruce Snyder wrote:
> >
> >> On 8/23/07, Kit Plummer <ki...@gmail.com> wrote:
> >>
> >>> I've used MagicDraw on OS X. It's pretty terrible...but does work for
> >>> sequence diagrams. I'm not sure if they have a "free" version or not.
> >>> Doesn't OmniGraffle do some UML stuff too?
> >>
> >> Yeah I've used MagicDraw in the past. Unfortunately the free version
> >> doesn't generate sequence diagrams and that's the key for me. I want
> >> the ability to have the tool generate UML from the source and that's
> >> hard to find in a free tool.
> >
> > Yes, I agree. JUDE can generate UML from source, though it doesn't
> > support Java 1.5 annotations. It does make nice sequence diagrams and
> > is a nice tool to work with, in general.
> >
> >>
> >> 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/
> >
> > --
> > Daryl
> > http://itsallsemantics.com
> >
> >
> >
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0
Posted by Chris Custine <cc...@apache.org>.
I would highly recommend switching to slf4j for internal logging, and then
use the slf4j over jcl facade to permanently get rid of commons-logging. If
you are going to use OSGi in the future, you will have trouble with the
dynamic classloading issue introduced by JCL. The slf4j facade will
alleviate this because the linkage is static (based on which jar you choose
to use).
I blogged about this a while back here:
http://blog.organicelement.com/2006/12/21/commons-logging-classloader-woes
Also slf4j is fairly OSGi friendly in that it has OSGi manifest headers
already built in so you can deploy with OSGi and make the logging package
available to all bundles.
Chris
On 8/27/07, Bruce Snyder <br...@gmail.com> wrote:
>
> On 8/27/07, James Strachan <ja...@gmail.com> wrote:
>
> > > > 1. Use slf4j as the logging framework. (http://www.slf4j.org/) ->
> btw,
> > > > I'm not sure if its a better option, but I did hear some good stuff
> > > > about it.
> > >
> > > Yes, SMX should switch to using the slf4j-api which will allow any
> > > logging framework to be plugged in at deployment time.
> >
> > how's that different from commons-logging (other than adding yet
> > another dependency, since many things SMX depends on also depends on
> > commons logging)
>
> There are a lot of reasons, including an extremely good writeup about
> JCL that Ceki did back in 2004 that is available here:
>
> http://www.qos.ch/logging/thinkAgain.jsp
>
> But the most important point of all is that the use of JCL is most
> oftentimes incorrect from an architecture standpoint. At least this is
> what the creator of JCL says:
>
> '...The purpose of Commons Logging is not to somehow take the logging
> world by storm. In fact, there are very limited circumstances in which
> Commons Logging is useful. If you're building a stand-alone
> application, don't use commons-logging. If you're building an
> application server, don't use commons-logging. If you're building a
> moderately large framework, don't use commons-logging. If however,
> like the Jakarta Commons project, you're building a tiny little
> component that you intend for other developers to embed in their
> applications and frameworks, and you believe that logging information
> might be useful to those clients, and you can't be sure what logging
> framework they're going to want to use, then commons-logging might be
> useful to you...'
>
> See Rod's full blog entry here:
> http://radio.weblogs.com/0122027/2003/08/15.html
>
> 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: ServiceMix 4.0
Posted by Chris Custine <cc...@apache.org>.
Guillaume,
No problem... I think you will be happy with this choice.
Also to clarify something important, I really encourage you to replace
commons-logging-1.x.jar with jcl14-over-slf4j which implements the
commons-logging interfaces and maps them to slf4j static binding. This will
solve the problem with other projects like Spring that still use
commons-logging and provide consistency for your projects.
Cheers...
Chris
On 8/28/07, Guillaume Nodet <gn...@gmail.com> wrote:
>
> Thanks Chris !
> It seems like the experts have answered...
> So i guess we will switch to slf4j :-)
>
> Cheers,
> Guillaume Nodet
>
> On 8/28/07, Chris Custine <cc...@apache.org> wrote:
> > You are correct about OSGi having more control over classloaders, but in
> the
> > case of JCL things are a little different. Below is a link to the
> mailing
> > list thread where we went through all of this pain on the Spring-OSGi
> > project and decided to replace JCL with the slf4j facade in order to
> > eliminate the side effects caused by Spring using JCL. I think
> Spring-OSGi
> > uses slf4j natively now because of this and I believe it has been a
> > consideration for Spring itself to move to it, but I am not sure of the
> > final outcome of that discussion.
> >
> > http://tinyurl.com/3axajc
> >
> > I think the thread was cross posted to Equinox as well and a discussion
> > occured there...
> > Just google "commons logging madness" :-)
> >
> > As you said about OSGi being flexible, one nice thing about using slf4j
> in
> > OSGi is that you can have all implementation bundles (slf4j-log4j,
> > slf4j-jdk14, etc.) available in the container, and it is up to each
> bundle
> > to specify which one it imports, thereby adding it to the classloader
> > wiring. I can't remember if that is built in functionality of slf4j or
> if
> > it is something that I made work, but it is all done with manifest
> headers
> > so it is easy to do if its not shipped like that.
> >
> > Good luck!
> > Chris
> >
> > On 8/27/07, Nodet Guillaume <gn...@gmail.com> wrote:
> > >
> > > I would say the opposite. The OSGi classloaders are much more
> > > powerful and you can more easily control the visibility of classes.
> > > In addition, if JCL is required by a given bundle A, it does not
> > > mean that it will be visible by a bundle using bundle A.
> > >
> > > Obviously, this means to be tested (or maybe OSGi experts could
> > > help there...)
> > >
> > > Cheers,
> > > Guillaume Nodet
> > >
> > > On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote:
> > >
> > > > Also, moving toward an architecture based on OSGi almost guarantees
> > > > that we will run into classloader issues with JCL.
> > > >
> > > > Bruce
> > >
> > >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
Re: ServiceMix 4.0
Posted by Guillaume Nodet <gn...@gmail.com>.
So for ServiceMix 4.0, we can switch so slf4j.
The thing is that I don't really care since I came across the
pax-logging project
(http://wiki.ops4j.org/confluence/display/ops4j/Pax+Logging). This
project provides an OSGi logging service that implements JCL, j.u.l
and SLF4J. Everything is redirected to the same service using Log4J
underneath ! So we don't have to really care about which one we use,
as long as we are consistent in ServiceMix of course.
On 8/28/07, Guillaume Nodet <gn...@gmail.com> wrote:
> Thanks Chris !
> It seems like the experts have answered...
> So i guess we will switch to slf4j :-)
>
> Cheers,
> Guillaume Nodet
>
> On 8/28/07, Chris Custine <cc...@apache.org> wrote:
> > You are correct about OSGi having more control over classloaders, but in the
> > case of JCL things are a little different. Below is a link to the mailing
> > list thread where we went through all of this pain on the Spring-OSGi
> > project and decided to replace JCL with the slf4j facade in order to
> > eliminate the side effects caused by Spring using JCL. I think Spring-OSGi
> > uses slf4j natively now because of this and I believe it has been a
> > consideration for Spring itself to move to it, but I am not sure of the
> > final outcome of that discussion.
> >
> > http://tinyurl.com/3axajc
> >
> > I think the thread was cross posted to Equinox as well and a discussion
> > occured there...
> > Just google "commons logging madness" :-)
> >
> > As you said about OSGi being flexible, one nice thing about using slf4j in
> > OSGi is that you can have all implementation bundles (slf4j-log4j,
> > slf4j-jdk14, etc.) available in the container, and it is up to each bundle
> > to specify which one it imports, thereby adding it to the classloader
> > wiring. I can't remember if that is built in functionality of slf4j or if
> > it is something that I made work, but it is all done with manifest headers
> > so it is easy to do if its not shipped like that.
> >
> > Good luck!
> > Chris
> >
> > On 8/27/07, Nodet Guillaume <gn...@gmail.com> wrote:
> > >
> > > I would say the opposite. The OSGi classloaders are much more
> > > powerful and you can more easily control the visibility of classes.
> > > In addition, if JCL is required by a given bundle A, it does not
> > > mean that it will be visible by a bundle using bundle A.
> > >
> > > Obviously, this means to be tested (or maybe OSGi experts could
> > > help there...)
> > >
> > > Cheers,
> > > Guillaume Nodet
> > >
> > > On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote:
> > >
> > > > Also, moving toward an architecture based on OSGi almost guarantees
> > > > that we will run into classloader issues with JCL.
> > > >
> > > > Bruce
> > >
> > >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0
Posted by Guillaume Nodet <gn...@gmail.com>.
Thanks Chris !
It seems like the experts have answered...
So i guess we will switch to slf4j :-)
Cheers,
Guillaume Nodet
On 8/28/07, Chris Custine <cc...@apache.org> wrote:
> You are correct about OSGi having more control over classloaders, but in the
> case of JCL things are a little different. Below is a link to the mailing
> list thread where we went through all of this pain on the Spring-OSGi
> project and decided to replace JCL with the slf4j facade in order to
> eliminate the side effects caused by Spring using JCL. I think Spring-OSGi
> uses slf4j natively now because of this and I believe it has been a
> consideration for Spring itself to move to it, but I am not sure of the
> final outcome of that discussion.
>
> http://tinyurl.com/3axajc
>
> I think the thread was cross posted to Equinox as well and a discussion
> occured there...
> Just google "commons logging madness" :-)
>
> As you said about OSGi being flexible, one nice thing about using slf4j in
> OSGi is that you can have all implementation bundles (slf4j-log4j,
> slf4j-jdk14, etc.) available in the container, and it is up to each bundle
> to specify which one it imports, thereby adding it to the classloader
> wiring. I can't remember if that is built in functionality of slf4j or if
> it is something that I made work, but it is all done with manifest headers
> so it is easy to do if its not shipped like that.
>
> Good luck!
> Chris
>
> On 8/27/07, Nodet Guillaume <gn...@gmail.com> wrote:
> >
> > I would say the opposite. The OSGi classloaders are much more
> > powerful and you can more easily control the visibility of classes.
> > In addition, if JCL is required by a given bundle A, it does not
> > mean that it will be visible by a bundle using bundle A.
> >
> > Obviously, this means to be tested (or maybe OSGi experts could
> > help there...)
> >
> > Cheers,
> > Guillaume Nodet
> >
> > On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote:
> >
> > > Also, moving toward an architecture based on OSGi almost guarantees
> > > that we will run into classloader issues with JCL.
> > >
> > > Bruce
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0
Posted by Chris Custine <cc...@apache.org>.
You are correct about OSGi having more control over classloaders, but in the
case of JCL things are a little different. Below is a link to the mailing
list thread where we went through all of this pain on the Spring-OSGi
project and decided to replace JCL with the slf4j facade in order to
eliminate the side effects caused by Spring using JCL. I think Spring-OSGi
uses slf4j natively now because of this and I believe it has been a
consideration for Spring itself to move to it, but I am not sure of the
final outcome of that discussion.
http://tinyurl.com/3axajc
I think the thread was cross posted to Equinox as well and a discussion
occured there...
Just google "commons logging madness" :-)
As you said about OSGi being flexible, one nice thing about using slf4j in
OSGi is that you can have all implementation bundles (slf4j-log4j,
slf4j-jdk14, etc.) available in the container, and it is up to each bundle
to specify which one it imports, thereby adding it to the classloader
wiring. I can't remember if that is built in functionality of slf4j or if
it is something that I made work, but it is all done with manifest headers
so it is easy to do if its not shipped like that.
Good luck!
Chris
On 8/27/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> I would say the opposite. The OSGi classloaders are much more
> powerful and you can more easily control the visibility of classes.
> In addition, if JCL is required by a given bundle A, it does not
> mean that it will be visible by a bundle using bundle A.
>
> Obviously, this means to be tested (or maybe OSGi experts could
> help there...)
>
> Cheers,
> Guillaume Nodet
>
> On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote:
>
> > Also, moving toward an architecture based on OSGi almost guarantees
> > that we will run into classloader issues with JCL.
> >
> > Bruce
>
>
Re: ServiceMix 4.0
Posted by Chris Custine <cc...@apache.org>.
You are correct about OSGi having more control over classloaders, but in the
case of JCL things are a little different. Below is a link to the mailing
list thread where we went through all of this pain on the Spring-OSGi
project and decided to replace JCL with the slf4j facade in order to
eliminate the side effects caused by Spring using JCL. I think Spring-OSGi
uses slf4j natively now because of this and I believe it has been a
consideration for Spring itself to move to it, but I am not sure of the
final outcome of that discussion.
http://tinyurl.com/3axajc
I think the thread was cross posted to Equinox as well and a discussion
occured there...
Just google "commons logging madness" :-)
As you said about OSGi being flexible, one nice thing about using slf4j in
OSGi is that you can have all implementation bundles (slf4j-log4j,
slf4j-jdk14, etc.) available in the container, and it is up to each bundle
to specify which one it imports, thereby adding it to the classloader
wiring. I can't remember if that is built in functionality of slf4j or if
it is something that I made work, but it is all done with manifest headers
so it is easy to do if its not shipped like that.
Good luck!
Chris
On 8/27/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> I would say the opposite. The OSGi classloaders are much more
> powerful and you can more easily control the visibility of classes.
> In addition, if JCL is required by a given bundle A, it does not
> mean that it will be visible by a bundle using bundle A.
>
> Obviously, this means to be tested (or maybe OSGi experts could
> help there...)
>
> Cheers,
> Guillaume Nodet
>
> On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote:
>
> > Also, moving toward an architecture based on OSGi almost guarantees
> > that we will run into classloader issues with JCL.
> >
> > Bruce
>
>
Re: ServiceMix 4.0
Posted by Nodet Guillaume <gn...@gmail.com>.
I would say the opposite. The OSGi classloaders are much more
powerful and you can more easily control the visibility of classes.
In addition, if JCL is required by a given bundle A, it does not
mean that it will be visible by a bundle using bundle A.
Obviously, this means to be tested (or maybe OSGi experts could
help there...)
Cheers,
Guillaume Nodet
On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote:
> Also, moving toward an architecture based on OSGi almost guarantees
> that we will run into classloader issues with JCL.
>
> Bruce
Re: ServiceMix 4.0
Posted by Bruce Snyder <br...@gmail.com>.
On 8/27/07, Bruce Snyder <br...@gmail.com> wrote:
> On 8/27/07, James Strachan <ja...@gmail.com> wrote:
>
> > > > 1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
> > > > I'm not sure if its a better option, but I did hear some good stuff
> > > > about it.
> > >
> > > Yes, SMX should switch to using the slf4j-api which will allow any
> > > logging framework to be plugged in at deployment time.
> >
> > how's that different from commons-logging (other than adding yet
> > another dependency, since many things SMX depends on also depends on
> > commons logging)
>
> There are a lot of reasons, including an extremely good writeup about
> JCL that Ceki did back in 2004 that is available here:
>
> http://www.qos.ch/logging/thinkAgain.jsp
>
> But the most important point of all is that the use of JCL is most
> oftentimes incorrect from an architecture standpoint. At least this is
> what the creator of JCL says:
>
> '...The purpose of Commons Logging is not to somehow take the logging
> world by storm. In fact, there are very limited circumstances in which
> Commons Logging is useful. If you're building a stand-alone
> application, don't use commons-logging. If you're building an
> application server, don't use commons-logging. If you're building a
> moderately large framework, don't use commons-logging. If however,
> like the Jakarta Commons project, you're building a tiny little
> component that you intend for other developers to embed in their
> applications and frameworks, and you believe that logging information
> might be useful to those clients, and you can't be sure what logging
> framework they're going to want to use, then commons-logging might be
> useful to you...'
>
> See Rod's full blog entry here: http://radio.weblogs.com/0122027/2003/08/15.html
Also, moving toward an architecture based on OSGi almost guarantees
that we will run into classloader issues with JCL.
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: ServiceMix 4.0
Posted by Bruce Snyder <br...@gmail.com>.
On 8/27/07, James Strachan <ja...@gmail.com> wrote:
> > > 1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
> > > I'm not sure if its a better option, but I did hear some good stuff
> > > about it.
> >
> > Yes, SMX should switch to using the slf4j-api which will allow any
> > logging framework to be plugged in at deployment time.
>
> how's that different from commons-logging (other than adding yet
> another dependency, since many things SMX depends on also depends on
> commons logging)
There are a lot of reasons, including an extremely good writeup about
JCL that Ceki did back in 2004 that is available here:
http://www.qos.ch/logging/thinkAgain.jsp
But the most important point of all is that the use of JCL is most
oftentimes incorrect from an architecture standpoint. At least this is
what the creator of JCL says:
'...The purpose of Commons Logging is not to somehow take the logging
world by storm. In fact, there are very limited circumstances in which
Commons Logging is useful. If you're building a stand-alone
application, don't use commons-logging. If you're building an
application server, don't use commons-logging. If you're building a
moderately large framework, don't use commons-logging. If however,
like the Jakarta Commons project, you're building a tiny little
component that you intend for other developers to embed in their
applications and frameworks, and you believe that logging information
might be useful to those clients, and you can't be sure what logging
framework they're going to want to use, then commons-logging might be
useful to you...'
See Rod's full blog entry here: http://radio.weblogs.com/0122027/2003/08/15.html
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: ServiceMix 4.0
Posted by James Strachan <ja...@gmail.com>.
On 8/24/07, Bruce Snyder <br...@gmail.com> wrote:
> On 8/24/07, Adrian Co <ac...@exist.com> wrote:
> > Not sure if this is the right forum to bring this up, but I was
> > wondering if this is a good opportunity to migrate some of servicemix's
> > infra to newer version.
> >
> > i.e.
> >
> > 1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
> > I'm not sure if its a better option, but I did hear some good stuff
> > about it.
>
> Yes, SMX should switch to using the slf4j-api which will allow any
> logging framework to be plugged in at deployment time.
how's that different from commons-logging (other than adding yet
another dependency, since many things SMX depends on also depends on
commons logging)
--
James
-------
http://macstrac.blogspot.com/
Re: ServiceMix 4.0
Posted by Bruce Snyder <br...@gmail.com>.
On 8/24/07, Adrian Co <ac...@exist.com> wrote:
> Not sure if this is the right forum to bring this up, but I was
> wondering if this is a good opportunity to migrate some of servicemix's
> infra to newer version.
>
> i.e.
>
> 1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
> I'm not sure if its a better option, but I did hear some good stuff
> about it.
Yes, SMX should switch to using the slf4j-api which will allow any
logging framework to be plugged in at deployment time.
> 2. Upgrade to junit 4.x (Port the existing test cases maybe?)
Either JUnit 4 or TestNG. TestNG is pretty nice and very easy to use.
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: ServiceMix 4.0
Posted by Adrian Co <ac...@exist.com>.
Not sure if this is the right forum to bring this up, but I was
wondering if this is a good opportunity to migrate some of servicemix's
infra to newer version.
i.e.
1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
I'm not sure if its a better option, but I did hear some good stuff
about it.
2. Upgrade to junit 4.x (Port the existing test cases maybe?)
and maybe others.
Just my 2 cents. :)
Daryl Richter wrote:
>
> On Aug 23, 2007, at 4:21 PM, Bruce Snyder wrote:
>
>> On 8/23/07, Kit Plummer <ki...@gmail.com> wrote:
>>
>>> I've used MagicDraw on OS X. It's pretty terrible...but does work for
>>> sequence diagrams. I'm not sure if they have a "free" version or not.
>>> Doesn't OmniGraffle do some UML stuff too?
>>
>> Yeah I've used MagicDraw in the past. Unfortunately the free version
>> doesn't generate sequence diagrams and that's the key for me. I want
>> the ability to have the tool generate UML from the source and that's
>> hard to find in a free tool.
>
> Yes, I agree. JUDE can generate UML from source, though it doesn't
> support Java 1.5 annotations. It does make nice sequence diagrams and
> is a nice tool to work with, in general.
>
>>
>> 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/
>
> --
> Daryl
> http://itsallsemantics.com
>
>
>
Re: ServiceMix 4.0
Posted by Daryl Richter <ng...@comcast.net>.
On Aug 23, 2007, at 4:21 PM, Bruce Snyder wrote:
> On 8/23/07, Kit Plummer <ki...@gmail.com> wrote:
>
>> I've used MagicDraw on OS X. It's pretty terrible...but does work
>> for
>> sequence diagrams. I'm not sure if they have a "free" version or
>> not.
>> Doesn't OmniGraffle do some UML stuff too?
>
> Yeah I've used MagicDraw in the past. Unfortunately the free version
> doesn't generate sequence diagrams and that's the key for me. I want
> the ability to have the tool generate UML from the source and that's
> hard to find in a free tool.
Yes, I agree. JUDE can generate UML from source, though it doesn't
support Java 1.5 annotations. It does make nice sequence diagrams
and is a nice tool to work with, in general.
>
> 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/
--
Daryl
http://itsallsemantics.com
Re: ServiceMix 4.0
Posted by Bruce Snyder <br...@gmail.com>.
On 8/23/07, Kit Plummer <ki...@gmail.com> wrote:
> I've used MagicDraw on OS X. It's pretty terrible...but does work for
> sequence diagrams. I'm not sure if they have a "free" version or not.
> Doesn't OmniGraffle do some UML stuff too?
Yeah I've used MagicDraw in the past. Unfortunately the free version
doesn't generate sequence diagrams and that's the key for me. I want
the ability to have the tool generate UML from the source and that's
hard to find in a free tool.
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: ServiceMix 4.0
Posted by Kit Plummer <ki...@gmail.com>.
On 8/23/07, Bruce Snyder <br...@gmail.com> wrote:
>
> On 8/23/07, Daryl Richter <ng...@comcast.net> wrote:
> >
> > On Aug 22, 2007, at 10:59 AM, Nodet Guillaume wrote:
> >
> > [snip]
> >
> > > (anybody knows a good tool for uml ?).
> >
> > Take a look at JUDE Community Edition. Works great for me.
> >
> > http://jude.change-vision.com/jude-web/product/community.html
>
> Looks like JUDE requires Windoze:
>
> http://jude.change-vision.com/jude-web/product/system.html
>
> My biggest issues not finding a UML tool. It's finding a UML tool that
> generates sequence diagrams and runs on Mac OS X.
>
> 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/
>
I've used MagicDraw on OS X. It's pretty terrible...but does work for
sequence diagrams. I'm not sure if they have a "free" version or not.
Doesn't OmniGraffle do some UML stuff too?
--
Kit Plummer
Nobody-in-Charge @ Black:Hole:Logic
http://www.blackholelogic.com
Re: ServiceMix 4.0
Posted by Daryl Richter <ng...@comcast.net>.
On Aug 23, 2007, at 11:30 AM, Bruce Snyder wrote:
> On 8/23/07, Daryl Richter <ng...@comcast.net> wrote:
>>
>> On Aug 22, 2007, at 10:59 AM, Nodet Guillaume wrote:
>>
>> [snip]
>>
>>> (anybody knows a good tool for uml ?).
>>
>> Take a look at JUDE Community Edition. Works great for me.
>>
>> http://jude.change-vision.com/jude-web/product/community.html
>
> Looks like JUDE requires Windoze:
>
> http://jude.change-vision.com/jude-web/product/system.html
>
> My biggest issues not finding a UML tool. It's finding a UML tool that
> generates sequence diagrams and runs on Mac OS X.
>
Nope. It's 100% Java. I'm a on OS X myself.
> 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/
--
Daryl
Email *my = [ daryl at: @"eddl" dot: @"us" ];
Weblog *blog = @”http://itsallsemantics.com”;
Re: ServiceMix 4.0
Posted by Bruce Snyder <br...@gmail.com>.
On 8/27/07, rs d <rs...@gmail.com> wrote:
> Omondo EclipseUML is also also provides some good features. I have
> experienced for reverse engineering. Check if it suffices your need.
>
> http://www.eclipsedownload.com/download/index.html
I've already looked at Omondo long ago. It does not offer a version
that runs on MacOS X.
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: ServiceMix 4.0
Posted by rs d <rs...@gmail.com>.
Omondo EclipseUML is also also provides some good features. I have
experienced for reverse engineering. Check if it suffices your need.
http://www.eclipsedownload.com/download/index.html
d.santosh
On 8/23/07, Bruce Snyder <br...@gmail.com> wrote:
>
> On 8/23/07, Daryl Richter <ng...@comcast.net> wrote:
> >
> > On Aug 22, 2007, at 10:59 AM, Nodet Guillaume wrote:
> >
> > [snip]
> >
> > > (anybody knows a good tool for uml ?).
> >
> > Take a look at JUDE Community Edition. Works great for me.
> >
> > http://jude.change-vision.com/jude-web/product/community.html
>
> Looks like JUDE requires Windoze:
>
> http://jude.change-vision.com/jude-web/product/system.html
>
> My biggest issues not finding a UML tool. It's finding a UML tool that
> generates sequence diagrams and runs on Mac OS X.
>
> 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: ServiceMix 4.0
Posted by Bruce Snyder <br...@gmail.com>.
On 8/23/07, Daryl Richter <ng...@comcast.net> wrote:
>
> On Aug 22, 2007, at 10:59 AM, Nodet Guillaume wrote:
>
> [snip]
>
> > (anybody knows a good tool for uml ?).
>
> Take a look at JUDE Community Edition. Works great for me.
>
> http://jude.change-vision.com/jude-web/product/community.html
Looks like JUDE requires Windoze:
http://jude.change-vision.com/jude-web/product/system.html
My biggest issues not finding a UML tool. It's finding a UML tool that
generates sequence diagrams and runs on Mac OS X.
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: ServiceMix 4.0
Posted by Daryl Richter <ng...@comcast.net>.
On Aug 22, 2007, at 10:59 AM, Nodet Guillaume wrote:
[snip]
> (anybody knows a good tool for uml ?).
Take a look at JUDE Community Edition. Works great for me.
http://jude.change-vision.com/jude-web/product/community.html
[snip]
> Cheers,
> Guillaume Nodet
>
>
--
Daryl
http://itsallsemantics.com
"I see this as coming down to mutual respect. I want to respect the
others I communicate with enough to tell them my truth without
reservation and I want to respect them enough to listen to their
truth. I want to respect their good intentions enough to believe that
we can work past our disagreements."
-- Kent Beck, 2006
Re: ServiceMix 4.0
Posted by Nodet Guillaume <gn...@gmail.com>.
On Aug 23, 2007, at 11:58 AM, James Strachan wrote:
> On 8/22/07, Nodet Guillaume <gn...@gmail.com> wrote:
>> As I explained in the other thread, I've been working on a new API
>> for ServiceMix 4.0.
>> Hopefully this will serve as an input for JBI 2.0.
>> This API is available at https://svn.apache.org/repos/asf/incubator/
>> servicemix/branches/servicemix-4.0/api
>>
>> So here a few key changes:
>> * clean integration with OSGi
>> * the NormalizedMessage can contain not only XML
>> * no more components
>> * no more JBI packaging (just use OSGi bundles)
>> * move the Channel to the Endpoint
>> * use push delivery instead of pulling exchanges
>> * introduce a single interface for identifying the Target of an
>> Exchange
>
> Sounds great!
>
> How far have you got implementing this? :)
Not so far yet. I've played a bit with OSGi last month in a branch,
but not much on this very api...
>
>
>> As we remove components, everything goes down to the endpoint which
>> become a key feature.
>>
>> The endpoint must implement the Endpoint interface. In OSGi, the NMR
>> would listen to endpoints
>> registered in the OSGi registry and call the registry to register /
>> unregister the endpoints.
>> As part of the endpoint registration, the NMR would inject a Channel
>> into them, thus actually activating the
>> endpoint. I guess I could write a sequence diagram for that (anybody
>> knows a good tool for uml ?).
>> In a non OSGI environment, the Endpoint will be registered in the
>> Registry by calling the register method
>> somehow.
>>
>> The Endpoint receives Exchange to be processed on the process method.
>> I think we should keep the JBI 1.0 semantics and the endpoint use the
>> same process as for JBI 1.0, which is
>> send the exchange back using the Channel (with the response / fault /
>> error / done). This will put the threading,
>> transactions and security burden on the container itself. Which
>> means it is easier to write JBI apps :-)
>>
>> Exchanges can be created using the Channel#createExchange method.
>> The only change I'd like to
>> integrate in the messaging API is to allow for non xml payloads and
>> maybe untyped attachments. The body
>> could be converted automatically to a given type if supported (I
>> think Camel does it nicely, so I'm thinking of
>> shamelessly copying the converter layer).
>
> I'd hope we can easily just wire in camel-core as the default type
> converter layer implementation as we've got most common type
> conversions sorted now along with a simple extension mechanism to
> support any type conversions. i.e. you should be able to invoke the
> type conversion stuff without the SMX API having any hard dependency
> on Camel - let it be just an implementation detail.
Yeah, we certainly need to work on the details. I will continue
discussing
that by replying to your other email.
>
>
>> I have added a few helper
>> methods on the exchanges and
>> messages (copy, copyFrom, ensureReReadable, display) to ease message
>> management.
>>
>> For the deployment part, there is no packaging anymore. One would
>> deploy an OSGi bundle that would
>> register the needed endpoints in the OSGi registry. For certain
>> types of endpoints, we may need an external
>> activation process (such as creating a server socket for listening to
>> HTTP requests) that may need to be shared
>> across endpoints of a given type. In such a case, you would deploy a
>> "component" that listens to new
>> endpoints implementing HttpEndpoint for example. When a new endpoint
>> is registered, the listener would
>> activate a server socket that could be shared across all http
>> endpoints.
>
> Interesting differentiation between component and endpoint; I like it.
My main point is that usually an endpoint is sufficient by itself. At
least the NMR
only needs to know about endpoints. Components are needed when
additional
resources or deployment mechanism need to be handled.
>
>
>> In a different way, if we have a BPEL
>> engine, the bpel "component" would listen for new bundles and look
>> for a specific file containing deployment
>> information. The component would register new endpoints in the OSGi
>> registry as needed (we could do that
>> for jaxws pojos using cxf for example).
>
> I wonder should we come up with some standard OSGi metadata that
> components should try adopt to know when to auto-detect things like
> HttpEndpoint or BPEL. I guess component developers can do whatever
> they like but it might be nice to at least document some guidelines
> for nicely behaving components
I think if you deploy java code, you can easily use an interface to
recognize
endpoints of a certain type. This is the easiest way imho. For a
BPEL process
you can always register a BpelEndpoint that contains a pointer to the
needed
resources (bpel process and wsdls). This may not be nicest way to
handle things,
but this allow to more tightly control which endpoints are created.
If we search the
bundle for known resources (a wsdl or bpel for example), we may have
conflicts
where differents components would try to activate an endpoint for the
same resource.
Another way would be to use some metadata in the META-INF folder of
the bundle
to list the endpoints to be activated. Imo, the first solution is
the most straightforward.
>
>
>> So I said there is no more components, because this feature is not in
>> the api anymore, but we will certainly need
>> these components for some use cases. For simple endpoints, you
>> would not need any component at all.
>> Another benefit is that you can easily deploy a whole application
>> inside a single OSGi bundle. Using spring-osgi,
>> the bundle would just consist in a spring configuration file
>> containing the endpoints declaration and expose them
>> as OSGi services.
>>
>> Of course, we need to write a JBI 1.0 compatibility layer, and we
>> could have an intermediate layer where SAs and
>> JBI components could be OSGi bundles directly, thus leveraging the
>> OSGi classloading mechanism.
>>
>> The thing I'm not completely sure about if the Target interface which
>> aims to identify the target of an exchange.
>> I'm thinking that some metadata are associated with endpoints (like
>> service name, interface name, wsdl
>> location, etc..). These metadatas could be used to retrieve targets
>> using the Registry. We could plug in different
>> mechanisms to query the metadata (simple lookup per id, policy based,
>> etc...). And the result itself could be
>> not only a single Endpoint, but could include some policies like:
>> load balance between all the endpoint implementing
>> the given interface, etc.... Also, I think Target should be injected
>> on Endpoints using spring, so you would look up a
>> targe using a spring bean factory (or multiple ones):
>> <smx:endpoint-target id="my-endoint-id" />
>> or
>> <smx:interface-target name="my:qname" />
>> The API is quite open right now, so any ideas welcome.
>
> Yeah - I think usually most folks are gonna wanna work with a smart
> proxy to the available endpoints rather than the actual physical
> endpoints themselves (since in OSGi they can come and go at will).
>
> If we can express most of the query semantics in standard OSGi LDAP
> syntax, the above XML elements could just be helper classes sitting on
> top of the standard Spring-OSGi smart proxies. We'd just need our own
> smart proxy providers for more complex types of predicates; such as
> using all the endpoints which implement some kinda WS-Policy assertion
> or whatever which maybe cannot be expressed as a standard OSGi query.
>> I think i covered the main areas of the API.
>
>
> One topic not covered in this excellent post is a standard mechanism
> to provide access to other endpoint metadata (e.g. the WSDL file) -
> having that as a standard OSGi metadata would be cool (e.g. a WSDL
> URI)
Yeah, I have had a closer look at how OSGi provides URL handlers.
This is not as simple as I thought it would be. OSGI defines
a "bundle:" protocol that can be used to access resources in the bundle.
Unfortunately, the url has to contain the bundle id, which means that
the URLs have to be built dynamically. I'm sure we can create a spring
bean factory to create those dynamically though...
Or a post factory processor that would process the URIs to rewrite them
and include the bundle id.
This way, the service could contain a WSDL_URL property associated
with it (when registered in the OSGi registry) that would be a bundle
url
pointing to the wsdl inside the bundle. This would solve one of JBI
limitation
which is the ability to have complex WSDLs definitions including other
WSDL or XSD.
>
>
>> The main goal is OSGi
>> and leveraging it as much as possible. There are
>> still some gray areas: what about the start/stop/shutdown lifecycle
>> which may be needed in some cases as I
>> discovered recently (when you want to gracefully shutdown a jms
>> consumer without loosing the ongoing messages
>> for example). I also want to give due credits to James, which has
>> been working with me on that.
>
> Thanks! :)
>
>
>> Remember that nothing can't be changed and that' s why I'm asking for
>> feedback at this early stage, where there are
>> only ideas ;-)
>
> Its an awesome start! Once the basics are working we can try port some
> components across; then we might find more issues etc.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0
Posted by James Strachan <ja...@gmail.com>.
On 8/22/07, Nodet Guillaume <gn...@gmail.com> wrote:
> As I explained in the other thread, I've been working on a new API
> for ServiceMix 4.0.
> Hopefully this will serve as an input for JBI 2.0.
> This API is available at https://svn.apache.org/repos/asf/incubator/
> servicemix/branches/servicemix-4.0/api
>
> So here a few key changes:
> * clean integration with OSGi
> * the NormalizedMessage can contain not only XML
> * no more components
> * no more JBI packaging (just use OSGi bundles)
> * move the Channel to the Endpoint
> * use push delivery instead of pulling exchanges
> * introduce a single interface for identifying the Target of an
> Exchange
Sounds great!
How far have you got implementing this? :)
> As we remove components, everything goes down to the endpoint which
> become a key feature.
>
> The endpoint must implement the Endpoint interface. In OSGi, the NMR
> would listen to endpoints
> registered in the OSGi registry and call the registry to register /
> unregister the endpoints.
> As part of the endpoint registration, the NMR would inject a Channel
> into them, thus actually activating the
> endpoint. I guess I could write a sequence diagram for that (anybody
> knows a good tool for uml ?).
> In a non OSGI environment, the Endpoint will be registered in the
> Registry by calling the register method
> somehow.
>
> The Endpoint receives Exchange to be processed on the process method.
> I think we should keep the JBI 1.0 semantics and the endpoint use the
> same process as for JBI 1.0, which is
> send the exchange back using the Channel (with the response / fault /
> error / done). This will put the threading,
> transactions and security burden on the container itself. Which
> means it is easier to write JBI apps :-)
>
> Exchanges can be created using the Channel#createExchange method.
> The only change I'd like to
> integrate in the messaging API is to allow for non xml payloads and
> maybe untyped attachments. The body
> could be converted automatically to a given type if supported (I
> think Camel does it nicely, so I'm thinking of
> shamelessly copying the converter layer).
I'd hope we can easily just wire in camel-core as the default type
converter layer implementation as we've got most common type
conversions sorted now along with a simple extension mechanism to
support any type conversions. i.e. you should be able to invoke the
type conversion stuff without the SMX API having any hard dependency
on Camel - let it be just an implementation detail.
> I have added a few helper
> methods on the exchanges and
> messages (copy, copyFrom, ensureReReadable, display) to ease message
> management.
>
> For the deployment part, there is no packaging anymore. One would
> deploy an OSGi bundle that would
> register the needed endpoints in the OSGi registry. For certain
> types of endpoints, we may need an external
> activation process (such as creating a server socket for listening to
> HTTP requests) that may need to be shared
> across endpoints of a given type. In such a case, you would deploy a
> "component" that listens to new
> endpoints implementing HttpEndpoint for example. When a new endpoint
> is registered, the listener would
> activate a server socket that could be shared across all http
> endpoints.
Interesting differentiation between component and endpoint; I like it.
> In a different way, if we have a BPEL
> engine, the bpel "component" would listen for new bundles and look
> for a specific file containing deployment
> information. The component would register new endpoints in the OSGi
> registry as needed (we could do that
> for jaxws pojos using cxf for example).
I wonder should we come up with some standard OSGi metadata that
components should try adopt to know when to auto-detect things like
HttpEndpoint or BPEL. I guess component developers can do whatever
they like but it might be nice to at least document some guidelines
for nicely behaving components
> So I said there is no more components, because this feature is not in
> the api anymore, but we will certainly need
> these components for some use cases. For simple endpoints, you
> would not need any component at all.
> Another benefit is that you can easily deploy a whole application
> inside a single OSGi bundle. Using spring-osgi,
> the bundle would just consist in a spring configuration file
> containing the endpoints declaration and expose them
> as OSGi services.
>
> Of course, we need to write a JBI 1.0 compatibility layer, and we
> could have an intermediate layer where SAs and
> JBI components could be OSGi bundles directly, thus leveraging the
> OSGi classloading mechanism.
>
> The thing I'm not completely sure about if the Target interface which
> aims to identify the target of an exchange.
> I'm thinking that some metadata are associated with endpoints (like
> service name, interface name, wsdl
> location, etc..). These metadatas could be used to retrieve targets
> using the Registry. We could plug in different
> mechanisms to query the metadata (simple lookup per id, policy based,
> etc...). And the result itself could be
> not only a single Endpoint, but could include some policies like:
> load balance between all the endpoint implementing
> the given interface, etc.... Also, I think Target should be injected
> on Endpoints using spring, so you would look up a
> targe using a spring bean factory (or multiple ones):
> <smx:endpoint-target id="my-endoint-id" />
> or
> <smx:interface-target name="my:qname" />
> The API is quite open right now, so any ideas welcome.
Yeah - I think usually most folks are gonna wanna work with a smart
proxy to the available endpoints rather than the actual physical
endpoints themselves (since in OSGi they can come and go at will).
If we can express most of the query semantics in standard OSGi LDAP
syntax, the above XML elements could just be helper classes sitting on
top of the standard Spring-OSGi smart proxies. We'd just need our own
smart proxy providers for more complex types of predicates; such as
using all the endpoints which implement some kinda WS-Policy assertion
or whatever which maybe cannot be expressed as a standard OSGi query.
> I think i covered the main areas of the API.
One topic not covered in this excellent post is a standard mechanism
to provide access to other endpoint metadata (e.g. the WSDL file) -
having that as a standard OSGi metadata would be cool (e.g. a WSDL
URI)
> The main goal is OSGi
> and leveraging it as much as possible. There are
> still some gray areas: what about the start/stop/shutdown lifecycle
> which may be needed in some cases as I
> discovered recently (when you want to gracefully shutdown a jms
> consumer without loosing the ongoing messages
> for example). I also want to give due credits to James, which has
> been working with me on that.
Thanks! :)
> Remember that nothing can't be changed and that' s why I'm asking for
> feedback at this early stage, where there are
> only ideas ;-)
Its an awesome start! Once the basics are working we can try port some
components across; then we might find more issues etc.
--
James
-------
http://macstrac.blogspot.com/
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Grant M <cl...@gmail.com>.
Definitely interested. It's been a while since I've checked in on the
ServiceMix project and the directions wrt OSGi look extremely promising.
On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> Any other people interested ?
>
> Cheers,
> Guillaume Nodet
>
> On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote:
>
> > I'd be up for a few chat sessions!
> >
> > On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
> >>
> >> Btw, if there is sufficient interest, we could organize irc meetings
> >> to discuss these topics and post the log to the dev list for
> >> archiving
> >> and later discussion.
> >>
> >> Cheers,
> >> Guillaume Nodet
> >>
> >> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
> >>
> >>> As I explained in the other thread, I've been working on a new API
> >>> for ServiceMix 4.0.
> >>> Hopefully this will serve as an input for JBI 2.0.
> >>> This API is available at https://svn.apache.org/repos/asf/
> >>> incubator/servicemix/branches/servicemix-4.0/api
> >>>
> >>> So here a few key changes:
> >>> * clean integration with OSGi
> >>> * the NormalizedMessage can contain not only XML
> >>> * no more components
> >>> * no more JBI packaging (just use OSGi bundles)
> >>> * move the Channel to the Endpoint
> >>> * use push delivery instead of pulling exchanges
> >>> * introduce a single interface for identifying the Target of an
> >>> Exchange
> >>>
> >>> As we remove components, everything goes down to the endpoint which
> >>> become a key feature.
> >>>
> >>> The endpoint must implement the Endpoint interface. In OSGi, the
> >>> NMR would listen to endpoints
> >>> registered in the OSGi registry and call the registry to register /
> >>> unregister the endpoints.
> >>> As part of the endpoint registration, the NMR would inject a
> >>> Channel into them, thus actually activating the
> >>> endpoint. I guess I could write a sequence diagram for that
> >>> (anybody knows a good tool for uml ?).
> >>> In a non OSGI environment, the Endpoint will be registered in the
> >>> Registry by calling the register method
> >>> somehow.
> >>>
> >>> The Endpoint receives Exchange to be processed on the process
> >>> method.
> >>> I think we should keep the JBI 1.0 semantics and the endpoint use
> >>> the same process as for JBI 1.0, which is
> >>> send the exchange back using the Channel (with the response /
> >>> fault / error / done). This will put the threading,
> >>> transactions and security burden on the container itself. Which
> >>> means it is easier to write JBI apps :-)
> >>>
> >>> Exchanges can be created using the Channel#createExchange method.
> >>> The only change I'd like to
> >>> integrate in the messaging API is to allow for non xml payloads and
> >>> maybe untyped attachments. The body
> >>> could be converted automatically to a given type if supported (I
> >>> think Camel does it nicely, so I'm thinking of
> >>> shamelessly copying the converter layer). I have added a few
> >>> helper methods on the exchanges and
> >>> messages (copy, copyFrom, ensureReReadable, display) to ease
> >>> message management.
> >>>
> >>> For the deployment part, there is no packaging anymore. One would
> >>> deploy an OSGi bundle that would
> >>> register the needed endpoints in the OSGi registry. For certain
> >>> types of endpoints, we may need an external
> >>> activation process (such as creating a server socket for listening
> >>> to HTTP requests) that may need to be shared
> >>> across endpoints of a given type. In such a case, you would deploy
> >>> a "component" that listens to new
> >>> endpoints implementing HttpEndpoint for example. When a new
> >>> endpoint is registered, the listener would
> >>> activate a server socket that could be shared across all http
> >>> endpoints. In a different way, if we have a BPEL
> >>> engine, the bpel "component" would listen for new bundles and look
> >>> for a specific file containing deployment
> >>> information. The component would register new endpoints in the OSGi
> >>> registry as needed (we could do that
> >>> for jaxws pojos using cxf for example).
> >>> So I said there is no more components, because this feature is not
> >>> in the api anymore, but we will certainly need
> >>> these components for some use cases. For simple endpoints, you
> >>> would not need any component at all.
> >>> Another benefit is that you can easily deploy a whole application
> >>> inside a single OSGi bundle. Using spring-osgi,
> >>> the bundle would just consist in a spring configuration file
> >>> containing the endpoints declaration and expose them
> >>> as OSGi services.
> >>>
> >>> Of course, we need to write a JBI 1.0 compatibility layer, and we
> >>> could have an intermediate layer where SAs and
> >>> JBI components could be OSGi bundles directly, thus leveraging the
> >>> OSGi classloading mechanism.
> >>>
> >>> The thing I'm not completely sure about if the Target interface
> >>> which aims to identify the target of an exchange.
> >>> I'm thinking that some metadata are associated with endpoints (like
> >>> service name, interface name, wsdl
> >>> location, etc..). These metadatas could be used to retrieve
> >>> targets using the Registry. We could plug in different
> >>> mechanisms to query the metadata (simple lookup per id, policy
> >>> based, etc...). And the result itself could be
> >>> not only a single Endpoint, but could include some policies like:
> >>> load balance between all the endpoint implementing
> >>> the given interface, etc.... Also, I think Target should be
> >>> injected on Endpoints using spring, so you would look up a
> >>> targe using a spring bean factory (or multiple ones):
> >>> <smx:endpoint-target id="my-endoint-id" />
> >>> or
> >>> <smx:interface-target name="my:qname" />
> >>> The API is quite open right now, so any ideas welcome.
> >>>
> >>> I think i covered the main areas of the API. The main goal is OSGi
> >>> and leveraging it as much as possible. There are
> >>> still some gray areas: what about the start/stop/shutdown lifecycle
> >>> which may be needed in some cases as I
> >>> discovered recently (when you want to gracefully shutdown a jms
> >>> consumer without loosing the ongoing messages
> >>> for example). I also want to give due credits to James, which has
> >>> been working with me on that.
> >>> Remember that nothing can't be changed and that' s why I'm asking
> >>> for feedback at this early stage, where there are
> >>> only ideas ;-)
> >>>
> >>> Feedback welcome....
> >>>
> >>> Cheers,
> >>> Guillaume Nodet
> >>>
> >>>
> >>
> >>
>
>
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Bruce Snyder <br...@gmail.com>.
On 8/28/07, Nodet Guillaume <gn...@gmail.com> wrote:
> I'm using Colloquy (http://colloquy.info/)
Yeah, I've used it for the last few years. It's not as comprehensive
in functionality as some of the hard-core IRC clients for Linux (e.g.,
BitchX, etc.) but it's pretty nice and perfect for MacOS.
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: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
I'm using Colloquy (http://colloquy.info/)
Cheers,
Guillaume Nodet
On Aug 28, 2007, at 11:57 PM, Daryl Richter wrote:
> On Aug 28, 2007, at 8:53 AM, Nodet Guillaume wrote:
>
>>
>> On Aug 28, 2007, at 2:48 PM, Piotr Bzdyl wrote:
>>
>>> Hi,
>>>
>>> I would also like to participate in this session. When are you going
>>> to send data about the location of the IRC session?
>>
>> See http://www.nabble.com/forum/ViewPost.jtp?
>> post=12323536&framed=y&skin=12049
>> We will use the standard IRC channel:
>> see http://incubator.apache.org/servicemix/irc.html
>>
>>>
>>> I have also another question: could you recommend any easy in use
>>> IRC
>>> client (for Windows preferably)? I haven't been using IRC (except
>>> one
>>> or two times).
>>
>> Before switching to mac, I was using xchat.
>> See http://www.xchat.org/
>
> So, now that you are on mac, what do you use? ;) (Another IRC
> newbie)
>
>>
>> Cheers,
>> Guillaume Nodet
>>
>>>
>
> --
> Daryl
> Email *my = [ daryl at: @"eddl" dot: @"us" ];
> Weblog *blog = @”http://itsallsemantics.com”;
>
>
>
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Daryl Richter <ng...@comcast.net>.
On Aug 28, 2007, at 8:53 AM, Nodet Guillaume wrote:
>
> On Aug 28, 2007, at 2:48 PM, Piotr Bzdyl wrote:
>
>> Hi,
>>
>> I would also like to participate in this session. When are you going
>> to send data about the location of the IRC session?
>
> See http://www.nabble.com/forum/ViewPost.jtp?
> post=12323536&framed=y&skin=12049
> We will use the standard IRC channel:
> see http://incubator.apache.org/servicemix/irc.html
>
>>
>> I have also another question: could you recommend any easy in use IRC
>> client (for Windows preferably)? I haven't been using IRC (except one
>> or two times).
>
> Before switching to mac, I was using xchat.
> See http://www.xchat.org/
So, now that you are on mac, what do you use? ;) (Another IRC newbie)
>
> Cheers,
> Guillaume Nodet
>
>>
--
Daryl
Email *my = [ daryl at: @"eddl" dot: @"us" ];
Weblog *blog = @”http://itsallsemantics.com”;
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
On Aug 28, 2007, at 2:48 PM, Piotr Bzdyl wrote:
> Hi,
>
> I would also like to participate in this session. When are you going
> to send data about the location of the IRC session?
See http://www.nabble.com/forum/ViewPost.jtp?
post=12323536&framed=y&skin=12049
We will use the standard IRC channel:
see http://incubator.apache.org/servicemix/irc.html
>
> I have also another question: could you recommend any easy in use IRC
> client (for Windows preferably)? I haven't been using IRC (except one
> or two times).
Before switching to mac, I was using xchat.
See http://www.xchat.org/
Cheers,
Guillaume Nodet
>
> Best regards,
> Piotr
>
> On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
>> Any other people interested ?
>>
>> Cheers,
>> Guillaume Nodet
>>
>> On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote:
>>
>>> I'd be up for a few chat sessions!
>>>
>>> On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>>>
>>>> Btw, if there is sufficient interest, we could organize irc
>>>> meetings
>>>> to discuss these topics and post the log to the dev list for
>>>> archiving
>>>> and later discussion.
>>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
>>>>
>>>>> As I explained in the other thread, I've been working on a new API
>>>>> for ServiceMix 4.0.
>>>>> Hopefully this will serve as an input for JBI 2.0.
>>>>> This API is available at https://svn.apache.org/repos/asf/
>>>>> incubator/servicemix/branches/servicemix-4.0/api
>>>>>
>>>>> So here a few key changes:
>>>>> * clean integration with OSGi
>>>>> * the NormalizedMessage can contain not only XML
>>>>> * no more components
>>>>> * no more JBI packaging (just use OSGi bundles)
>>>>> * move the Channel to the Endpoint
>>>>> * use push delivery instead of pulling exchanges
>>>>> * introduce a single interface for identifying the Target of an
>>>>> Exchange
>>>>>
>>>>> As we remove components, everything goes down to the endpoint
>>>>> which
>>>>> become a key feature.
>>>>>
>>>>> The endpoint must implement the Endpoint interface. In OSGi, the
>>>>> NMR would listen to endpoints
>>>>> registered in the OSGi registry and call the registry to
>>>>> register /
>>>>> unregister the endpoints.
>>>>> As part of the endpoint registration, the NMR would inject a
>>>>> Channel into them, thus actually activating the
>>>>> endpoint. I guess I could write a sequence diagram for that
>>>>> (anybody knows a good tool for uml ?).
>>>>> In a non OSGI environment, the Endpoint will be registered in the
>>>>> Registry by calling the register method
>>>>> somehow.
>>>>>
>>>>> The Endpoint receives Exchange to be processed on the process
>>>>> method.
>>>>> I think we should keep the JBI 1.0 semantics and the endpoint use
>>>>> the same process as for JBI 1.0, which is
>>>>> send the exchange back using the Channel (with the response /
>>>>> fault / error / done). This will put the threading,
>>>>> transactions and security burden on the container itself. Which
>>>>> means it is easier to write JBI apps :-)
>>>>>
>>>>> Exchanges can be created using the Channel#createExchange method.
>>>>> The only change I'd like to
>>>>> integrate in the messaging API is to allow for non xml payloads
>>>>> and
>>>>> maybe untyped attachments. The body
>>>>> could be converted automatically to a given type if supported (I
>>>>> think Camel does it nicely, so I'm thinking of
>>>>> shamelessly copying the converter layer). I have added a few
>>>>> helper methods on the exchanges and
>>>>> messages (copy, copyFrom, ensureReReadable, display) to ease
>>>>> message management.
>>>>>
>>>>> For the deployment part, there is no packaging anymore. One would
>>>>> deploy an OSGi bundle that would
>>>>> register the needed endpoints in the OSGi registry. For certain
>>>>> types of endpoints, we may need an external
>>>>> activation process (such as creating a server socket for listening
>>>>> to HTTP requests) that may need to be shared
>>>>> across endpoints of a given type. In such a case, you would
>>>>> deploy
>>>>> a "component" that listens to new
>>>>> endpoints implementing HttpEndpoint for example. When a new
>>>>> endpoint is registered, the listener would
>>>>> activate a server socket that could be shared across all http
>>>>> endpoints. In a different way, if we have a BPEL
>>>>> engine, the bpel "component" would listen for new bundles and
>>>>> look
>>>>> for a specific file containing deployment
>>>>> information. The component would register new endpoints in the
>>>>> OSGi
>>>>> registry as needed (we could do that
>>>>> for jaxws pojos using cxf for example).
>>>>> So I said there is no more components, because this feature is not
>>>>> in the api anymore, but we will certainly need
>>>>> these components for some use cases. For simple endpoints, you
>>>>> would not need any component at all.
>>>>> Another benefit is that you can easily deploy a whole application
>>>>> inside a single OSGi bundle. Using spring-osgi,
>>>>> the bundle would just consist in a spring configuration file
>>>>> containing the endpoints declaration and expose them
>>>>> as OSGi services.
>>>>>
>>>>> Of course, we need to write a JBI 1.0 compatibility layer, and we
>>>>> could have an intermediate layer where SAs and
>>>>> JBI components could be OSGi bundles directly, thus leveraging the
>>>>> OSGi classloading mechanism.
>>>>>
>>>>> The thing I'm not completely sure about if the Target interface
>>>>> which aims to identify the target of an exchange.
>>>>> I'm thinking that some metadata are associated with endpoints
>>>>> (like
>>>>> service name, interface name, wsdl
>>>>> location, etc..). These metadatas could be used to retrieve
>>>>> targets using the Registry. We could plug in different
>>>>> mechanisms to query the metadata (simple lookup per id, policy
>>>>> based, etc...). And the result itself could be
>>>>> not only a single Endpoint, but could include some policies like:
>>>>> load balance between all the endpoint implementing
>>>>> the given interface, etc.... Also, I think Target should be
>>>>> injected on Endpoints using spring, so you would look up a
>>>>> targe using a spring bean factory (or multiple ones):
>>>>> <smx:endpoint-target id="my-endoint-id" />
>>>>> or
>>>>> <smx:interface-target name="my:qname" />
>>>>> The API is quite open right now, so any ideas welcome.
>>>>>
>>>>> I think i covered the main areas of the API. The main goal is
>>>>> OSGi
>>>>> and leveraging it as much as possible. There are
>>>>> still some gray areas: what about the start/stop/shutdown
>>>>> lifecycle
>>>>> which may be needed in some cases as I
>>>>> discovered recently (when you want to gracefully shutdown a jms
>>>>> consumer without loosing the ongoing messages
>>>>> for example). I also want to give due credits to James, which has
>>>>> been working with me on that.
>>>>> Remember that nothing can't be changed and that' s why I'm asking
>>>>> for feedback at this early stage, where there are
>>>>> only ideas ;-)
>>>>>
>>>>> Feedback welcome....
>>>>>
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Piotr Bzdyl <pi...@bzdyl.net>.
Hi,
I would also like to participate in this session. When are you going
to send data about the location of the IRC session?
I have also another question: could you recommend any easy in use IRC
client (for Windows preferably)? I haven't been using IRC (except one
or two times).
Best regards,
Piotr
On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
> Any other people interested ?
>
> Cheers,
> Guillaume Nodet
>
> On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote:
>
> > I'd be up for a few chat sessions!
> >
> > On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
> >>
> >> Btw, if there is sufficient interest, we could organize irc meetings
> >> to discuss these topics and post the log to the dev list for
> >> archiving
> >> and later discussion.
> >>
> >> Cheers,
> >> Guillaume Nodet
> >>
> >> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
> >>
> >>> As I explained in the other thread, I've been working on a new API
> >>> for ServiceMix 4.0.
> >>> Hopefully this will serve as an input for JBI 2.0.
> >>> This API is available at https://svn.apache.org/repos/asf/
> >>> incubator/servicemix/branches/servicemix-4.0/api
> >>>
> >>> So here a few key changes:
> >>> * clean integration with OSGi
> >>> * the NormalizedMessage can contain not only XML
> >>> * no more components
> >>> * no more JBI packaging (just use OSGi bundles)
> >>> * move the Channel to the Endpoint
> >>> * use push delivery instead of pulling exchanges
> >>> * introduce a single interface for identifying the Target of an
> >>> Exchange
> >>>
> >>> As we remove components, everything goes down to the endpoint which
> >>> become a key feature.
> >>>
> >>> The endpoint must implement the Endpoint interface. In OSGi, the
> >>> NMR would listen to endpoints
> >>> registered in the OSGi registry and call the registry to register /
> >>> unregister the endpoints.
> >>> As part of the endpoint registration, the NMR would inject a
> >>> Channel into them, thus actually activating the
> >>> endpoint. I guess I could write a sequence diagram for that
> >>> (anybody knows a good tool for uml ?).
> >>> In a non OSGI environment, the Endpoint will be registered in the
> >>> Registry by calling the register method
> >>> somehow.
> >>>
> >>> The Endpoint receives Exchange to be processed on the process
> >>> method.
> >>> I think we should keep the JBI 1.0 semantics and the endpoint use
> >>> the same process as for JBI 1.0, which is
> >>> send the exchange back using the Channel (with the response /
> >>> fault / error / done). This will put the threading,
> >>> transactions and security burden on the container itself. Which
> >>> means it is easier to write JBI apps :-)
> >>>
> >>> Exchanges can be created using the Channel#createExchange method.
> >>> The only change I'd like to
> >>> integrate in the messaging API is to allow for non xml payloads and
> >>> maybe untyped attachments. The body
> >>> could be converted automatically to a given type if supported (I
> >>> think Camel does it nicely, so I'm thinking of
> >>> shamelessly copying the converter layer). I have added a few
> >>> helper methods on the exchanges and
> >>> messages (copy, copyFrom, ensureReReadable, display) to ease
> >>> message management.
> >>>
> >>> For the deployment part, there is no packaging anymore. One would
> >>> deploy an OSGi bundle that would
> >>> register the needed endpoints in the OSGi registry. For certain
> >>> types of endpoints, we may need an external
> >>> activation process (such as creating a server socket for listening
> >>> to HTTP requests) that may need to be shared
> >>> across endpoints of a given type. In such a case, you would deploy
> >>> a "component" that listens to new
> >>> endpoints implementing HttpEndpoint for example. When a new
> >>> endpoint is registered, the listener would
> >>> activate a server socket that could be shared across all http
> >>> endpoints. In a different way, if we have a BPEL
> >>> engine, the bpel "component" would listen for new bundles and look
> >>> for a specific file containing deployment
> >>> information. The component would register new endpoints in the OSGi
> >>> registry as needed (we could do that
> >>> for jaxws pojos using cxf for example).
> >>> So I said there is no more components, because this feature is not
> >>> in the api anymore, but we will certainly need
> >>> these components for some use cases. For simple endpoints, you
> >>> would not need any component at all.
> >>> Another benefit is that you can easily deploy a whole application
> >>> inside a single OSGi bundle. Using spring-osgi,
> >>> the bundle would just consist in a spring configuration file
> >>> containing the endpoints declaration and expose them
> >>> as OSGi services.
> >>>
> >>> Of course, we need to write a JBI 1.0 compatibility layer, and we
> >>> could have an intermediate layer where SAs and
> >>> JBI components could be OSGi bundles directly, thus leveraging the
> >>> OSGi classloading mechanism.
> >>>
> >>> The thing I'm not completely sure about if the Target interface
> >>> which aims to identify the target of an exchange.
> >>> I'm thinking that some metadata are associated with endpoints (like
> >>> service name, interface name, wsdl
> >>> location, etc..). These metadatas could be used to retrieve
> >>> targets using the Registry. We could plug in different
> >>> mechanisms to query the metadata (simple lookup per id, policy
> >>> based, etc...). And the result itself could be
> >>> not only a single Endpoint, but could include some policies like:
> >>> load balance between all the endpoint implementing
> >>> the given interface, etc.... Also, I think Target should be
> >>> injected on Endpoints using spring, so you would look up a
> >>> targe using a spring bean factory (or multiple ones):
> >>> <smx:endpoint-target id="my-endoint-id" />
> >>> or
> >>> <smx:interface-target name="my:qname" />
> >>> The API is quite open right now, so any ideas welcome.
> >>>
> >>> I think i covered the main areas of the API. The main goal is OSGi
> >>> and leveraging it as much as possible. There are
> >>> still some gray areas: what about the start/stop/shutdown lifecycle
> >>> which may be needed in some cases as I
> >>> discovered recently (when you want to gracefully shutdown a jms
> >>> consumer without loosing the ongoing messages
> >>> for example). I also want to give due credits to James, which has
> >>> been working with me on that.
> >>> Remember that nothing can't be changed and that' s why I'm asking
> >>> for feedback at this early stage, where there are
> >>> only ideas ;-)
> >>>
> >>> Feedback welcome....
> >>>
> >>> Cheers,
> >>> Guillaume Nodet
> >>>
> >>>
> >>
> >>
>
>
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Daryl Richter <ng...@comcast.net>.
On Aug 25, 2007, at 2:12 AM, Nodet Guillaume wrote:
> Ok, sounds like we have enough people.
> So we just need to find a data and an hour.
> What about Friday 3 pm GMT, 11 am EST, 8 am PST
> Adrian, I'm not sure how to find a time that would suits you...
> Other propositions are welcome...
+1
>
> Cheers,
> Guillaume Nodet
>
>
--
Daryl
http://itsallsemantics.com
"Under capitalism, man exploits man.
Under communism, it's just the opposite."
-- John Kenneth Galbraith
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Kit Plummer <ki...@gmail.com>.
Me too. I think.
--
Kit Plummer
Nobody-in-Charge @ Black:Hole:Logic
http://www.blackholelogic.com
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Brian O'Neill <bo...@alumni.brown.edu>.
works for me.
-brian
On 8/25/07, Nodet Guillaume <gn...@gmail.com> wrote:
> Ok, sounds like we have enough people.
> So we just need to find a data and an hour.
> What about Friday 3 pm GMT, 11 am EST, 8 am PST
> Adrian, I'm not sure how to find a time that would suits you...
> Other propositions are welcome...
>
> Cheers,
> Guillaume Nodet
>
> On Aug 24, 2007, at 11:04 AM, Nodet Guillaume wrote:
>
> > Any other people interested ?
> >
> > Cheers,
> > Guillaume Nodet
> >
> > On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote:
> >
> >> I'd be up for a few chat sessions!
> >>
> >> On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
> >>>
> >>> Btw, if there is sufficient interest, we could organize irc meetings
> >>> to discuss these topics and post the log to the dev list for
> >>> archiving
> >>> and later discussion.
> >>>
> >>> Cheers,
> >>> Guillaume Nodet
> >>>
> >>> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
> >>>
> >>>> As I explained in the other thread, I've been working on a new API
> >>>> for ServiceMix 4.0.
> >>>> Hopefully this will serve as an input for JBI 2.0.
> >>>> This API is available at https://svn.apache.org/repos/asf/
> >>>> incubator/servicemix/branches/servicemix-4.0/api
> >>>>
> >>>> So here a few key changes:
> >>>> * clean integration with OSGi
> >>>> * the NormalizedMessage can contain not only XML
> >>>> * no more components
> >>>> * no more JBI packaging (just use OSGi bundles)
> >>>> * move the Channel to the Endpoint
> >>>> * use push delivery instead of pulling exchanges
> >>>> * introduce a single interface for identifying the Target of an
> >>>> Exchange
> >>>>
> >>>> As we remove components, everything goes down to the endpoint which
> >>>> become a key feature.
> >>>>
> >>>> The endpoint must implement the Endpoint interface. In OSGi, the
> >>>> NMR would listen to endpoints
> >>>> registered in the OSGi registry and call the registry to register /
> >>>> unregister the endpoints.
> >>>> As part of the endpoint registration, the NMR would inject a
> >>>> Channel into them, thus actually activating the
> >>>> endpoint. I guess I could write a sequence diagram for that
> >>>> (anybody knows a good tool for uml ?).
> >>>> In a non OSGI environment, the Endpoint will be registered in the
> >>>> Registry by calling the register method
> >>>> somehow.
> >>>>
> >>>> The Endpoint receives Exchange to be processed on the process
> >>>> method.
> >>>> I think we should keep the JBI 1.0 semantics and the endpoint use
> >>>> the same process as for JBI 1.0, which is
> >>>> send the exchange back using the Channel (with the response /
> >>>> fault / error / done). This will put the threading,
> >>>> transactions and security burden on the container itself. Which
> >>>> means it is easier to write JBI apps :-)
> >>>>
> >>>> Exchanges can be created using the Channel#createExchange method.
> >>>> The only change I'd like to
> >>>> integrate in the messaging API is to allow for non xml payloads and
> >>>> maybe untyped attachments. The body
> >>>> could be converted automatically to a given type if supported (I
> >>>> think Camel does it nicely, so I'm thinking of
> >>>> shamelessly copying the converter layer). I have added a few
> >>>> helper methods on the exchanges and
> >>>> messages (copy, copyFrom, ensureReReadable, display) to ease
> >>>> message management.
> >>>>
> >>>> For the deployment part, there is no packaging anymore. One would
> >>>> deploy an OSGi bundle that would
> >>>> register the needed endpoints in the OSGi registry. For certain
> >>>> types of endpoints, we may need an external
> >>>> activation process (such as creating a server socket for listening
> >>>> to HTTP requests) that may need to be shared
> >>>> across endpoints of a given type. In such a case, you would deploy
> >>>> a "component" that listens to new
> >>>> endpoints implementing HttpEndpoint for example. When a new
> >>>> endpoint is registered, the listener would
> >>>> activate a server socket that could be shared across all http
> >>>> endpoints. In a different way, if we have a BPEL
> >>>> engine, the bpel "component" would listen for new bundles and look
> >>>> for a specific file containing deployment
> >>>> information. The component would register new endpoints in the OSGi
> >>>> registry as needed (we could do that
> >>>> for jaxws pojos using cxf for example).
> >>>> So I said there is no more components, because this feature is not
> >>>> in the api anymore, but we will certainly need
> >>>> these components for some use cases. For simple endpoints, you
> >>>> would not need any component at all.
> >>>> Another benefit is that you can easily deploy a whole application
> >>>> inside a single OSGi bundle. Using spring-osgi,
> >>>> the bundle would just consist in a spring configuration file
> >>>> containing the endpoints declaration and expose them
> >>>> as OSGi services.
> >>>>
> >>>> Of course, we need to write a JBI 1.0 compatibility layer, and we
> >>>> could have an intermediate layer where SAs and
> >>>> JBI components could be OSGi bundles directly, thus leveraging the
> >>>> OSGi classloading mechanism.
> >>>>
> >>>> The thing I'm not completely sure about if the Target interface
> >>>> which aims to identify the target of an exchange.
> >>>> I'm thinking that some metadata are associated with endpoints (like
> >>>> service name, interface name, wsdl
> >>>> location, etc..). These metadatas could be used to retrieve
> >>>> targets using the Registry. We could plug in different
> >>>> mechanisms to query the metadata (simple lookup per id, policy
> >>>> based, etc...). And the result itself could be
> >>>> not only a single Endpoint, but could include some policies like:
> >>>> load balance between all the endpoint implementing
> >>>> the given interface, etc.... Also, I think Target should be
> >>>> injected on Endpoints using spring, so you would look up a
> >>>> targe using a spring bean factory (or multiple ones):
> >>>> <smx:endpoint-target id="my-endoint-id" />
> >>>> or
> >>>> <smx:interface-target name="my:qname" />
> >>>> The API is quite open right now, so any ideas welcome.
> >>>>
> >>>> I think i covered the main areas of the API. The main goal is OSGi
> >>>> and leveraging it as much as possible. There are
> >>>> still some gray areas: what about the start/stop/shutdown lifecycle
> >>>> which may be needed in some cases as I
> >>>> discovered recently (when you want to gracefully shutdown a jms
> >>>> consumer without loosing the ongoing messages
> >>>> for example). I also want to give due credits to James, which has
> >>>> been working with me on that.
> >>>> Remember that nothing can't be changed and that' s why I'm asking
> >>>> for feedback at this early stage, where there are
> >>>> only ideas ;-)
> >>>>
> >>>> Feedback welcome....
> >>>>
> >>>> Cheers,
> >>>> Guillaume Nodet
> >>>>
> >>>>
> >>>
> >>>
> >
>
>
--
Brian ONeill
Source Equity (http://www.sourceequity.com)
jBIZint (http://www.jbizint.org)
Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
mobile:215.588.6024
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Adrian Co <ac...@exist.com>.
It's fine. I'll try to join in when I can or just read the logs. :)
Nodet Guillaume wrote:
> Ok, sounds like we have enough people.
> So we just need to find a data and an hour.
> What about Friday 3 pm GMT, 11 am EST, 8 am PST
> Adrian, I'm not sure how to find a time that would suits you...
> Other propositions are welcome...
>
> Cheers,
> Guillaume Nodet
>
> On Aug 24, 2007, at 11:04 AM, Nodet Guillaume wrote:
>
>> Any other people interested ?
>>
>> Cheers,
>> Guillaume Nodet
>>
>> On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote:
>>
>>> I'd be up for a few chat sessions!
>>>
>>> On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>>>
>>>> Btw, if there is sufficient interest, we could organize irc meetings
>>>> to discuss these topics and post the log to the dev list for archiving
>>>> and later discussion.
>>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
>>>>
>>>>> As I explained in the other thread, I've been working on a new API
>>>>> for ServiceMix 4.0.
>>>>> Hopefully this will serve as an input for JBI 2.0.
>>>>> This API is available at https://svn.apache.org/repos/asf/
>>>>> incubator/servicemix/branches/servicemix-4.0/api
>>>>>
>>>>> So here a few key changes:
>>>>> * clean integration with OSGi
>>>>> * the NormalizedMessage can contain not only XML
>>>>> * no more components
>>>>> * no more JBI packaging (just use OSGi bundles)
>>>>> * move the Channel to the Endpoint
>>>>> * use push delivery instead of pulling exchanges
>>>>> * introduce a single interface for identifying the Target of an
>>>>> Exchange
>>>>>
>>>>> As we remove components, everything goes down to the endpoint which
>>>>> become a key feature.
>>>>>
>>>>> The endpoint must implement the Endpoint interface. In OSGi, the
>>>>> NMR would listen to endpoints
>>>>> registered in the OSGi registry and call the registry to register /
>>>>> unregister the endpoints.
>>>>> As part of the endpoint registration, the NMR would inject a
>>>>> Channel into them, thus actually activating the
>>>>> endpoint. I guess I could write a sequence diagram for that
>>>>> (anybody knows a good tool for uml ?).
>>>>> In a non OSGI environment, the Endpoint will be registered in the
>>>>> Registry by calling the register method
>>>>> somehow.
>>>>>
>>>>> The Endpoint receives Exchange to be processed on the process method.
>>>>> I think we should keep the JBI 1.0 semantics and the endpoint use
>>>>> the same process as for JBI 1.0, which is
>>>>> send the exchange back using the Channel (with the response /
>>>>> fault / error / done). This will put the threading,
>>>>> transactions and security burden on the container itself. Which
>>>>> means it is easier to write JBI apps :-)
>>>>>
>>>>> Exchanges can be created using the Channel#createExchange method.
>>>>> The only change I'd like to
>>>>> integrate in the messaging API is to allow for non xml payloads and
>>>>> maybe untyped attachments. The body
>>>>> could be converted automatically to a given type if supported (I
>>>>> think Camel does it nicely, so I'm thinking of
>>>>> shamelessly copying the converter layer). I have added a few
>>>>> helper methods on the exchanges and
>>>>> messages (copy, copyFrom, ensureReReadable, display) to ease
>>>>> message management.
>>>>>
>>>>> For the deployment part, there is no packaging anymore. One would
>>>>> deploy an OSGi bundle that would
>>>>> register the needed endpoints in the OSGi registry. For certain
>>>>> types of endpoints, we may need an external
>>>>> activation process (such as creating a server socket for listening
>>>>> to HTTP requests) that may need to be shared
>>>>> across endpoints of a given type. In such a case, you would deploy
>>>>> a "component" that listens to new
>>>>> endpoints implementing HttpEndpoint for example. When a new
>>>>> endpoint is registered, the listener would
>>>>> activate a server socket that could be shared across all http
>>>>> endpoints. In a different way, if we have a BPEL
>>>>> engine, the bpel "component" would listen for new bundles and look
>>>>> for a specific file containing deployment
>>>>> information. The component would register new endpoints in the OSGi
>>>>> registry as needed (we could do that
>>>>> for jaxws pojos using cxf for example).
>>>>> So I said there is no more components, because this feature is not
>>>>> in the api anymore, but we will certainly need
>>>>> these components for some use cases. For simple endpoints, you
>>>>> would not need any component at all.
>>>>> Another benefit is that you can easily deploy a whole application
>>>>> inside a single OSGi bundle. Using spring-osgi,
>>>>> the bundle would just consist in a spring configuration file
>>>>> containing the endpoints declaration and expose them
>>>>> as OSGi services.
>>>>>
>>>>> Of course, we need to write a JBI 1.0 compatibility layer, and we
>>>>> could have an intermediate layer where SAs and
>>>>> JBI components could be OSGi bundles directly, thus leveraging the
>>>>> OSGi classloading mechanism.
>>>>>
>>>>> The thing I'm not completely sure about if the Target interface
>>>>> which aims to identify the target of an exchange.
>>>>> I'm thinking that some metadata are associated with endpoints (like
>>>>> service name, interface name, wsdl
>>>>> location, etc..). These metadatas could be used to retrieve
>>>>> targets using the Registry. We could plug in different
>>>>> mechanisms to query the metadata (simple lookup per id, policy
>>>>> based, etc...). And the result itself could be
>>>>> not only a single Endpoint, but could include some policies like:
>>>>> load balance between all the endpoint implementing
>>>>> the given interface, etc.... Also, I think Target should be
>>>>> injected on Endpoints using spring, so you would look up a
>>>>> targe using a spring bean factory (or multiple ones):
>>>>> <smx:endpoint-target id="my-endoint-id" />
>>>>> or
>>>>> <smx:interface-target name="my:qname" />
>>>>> The API is quite open right now, so any ideas welcome.
>>>>>
>>>>> I think i covered the main areas of the API. The main goal is OSGi
>>>>> and leveraging it as much as possible. There are
>>>>> still some gray areas: what about the start/stop/shutdown lifecycle
>>>>> which may be needed in some cases as I
>>>>> discovered recently (when you want to gracefully shutdown a jms
>>>>> consumer without loosing the ongoing messages
>>>>> for example). I also want to give due credits to James, which has
>>>>> been working with me on that.
>>>>> Remember that nothing can't be changed and that' s why I'm asking
>>>>> for feedback at this early stage, where there are
>>>>> only ideas ;-)
>>>>>
>>>>> Feedback welcome....
>>>>>
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>>
>>>>>
>>>>
>>>>
>>
>
>
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Bruce Snyder <br...@gmail.com>.
On 8/25/07, Nodet Guillaume <gn...@gmail.com> wrote:
> Ok, sounds like we have enough people.
> So we just need to find a data and an hour.
> What about Friday 3 pm GMT, 11 am EST, 8 am PST
> Adrian, I'm not sure how to find a time that would suits you...
> Other propositions are welcome...
+1
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: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
Ok, sounds like we have enough people.
So we just need to find a data and an hour.
What about Friday 3 pm GMT, 11 am EST, 8 am PST
Adrian, I'm not sure how to find a time that would suits you...
Other propositions are welcome...
Cheers,
Guillaume Nodet
On Aug 24, 2007, at 11:04 AM, Nodet Guillaume wrote:
> Any other people interested ?
>
> Cheers,
> Guillaume Nodet
>
> On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote:
>
>> I'd be up for a few chat sessions!
>>
>> On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>>
>>> Btw, if there is sufficient interest, we could organize irc meetings
>>> to discuss these topics and post the log to the dev list for
>>> archiving
>>> and later discussion.
>>>
>>> Cheers,
>>> Guillaume Nodet
>>>
>>> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
>>>
>>>> As I explained in the other thread, I've been working on a new API
>>>> for ServiceMix 4.0.
>>>> Hopefully this will serve as an input for JBI 2.0.
>>>> This API is available at https://svn.apache.org/repos/asf/
>>>> incubator/servicemix/branches/servicemix-4.0/api
>>>>
>>>> So here a few key changes:
>>>> * clean integration with OSGi
>>>> * the NormalizedMessage can contain not only XML
>>>> * no more components
>>>> * no more JBI packaging (just use OSGi bundles)
>>>> * move the Channel to the Endpoint
>>>> * use push delivery instead of pulling exchanges
>>>> * introduce a single interface for identifying the Target of an
>>>> Exchange
>>>>
>>>> As we remove components, everything goes down to the endpoint which
>>>> become a key feature.
>>>>
>>>> The endpoint must implement the Endpoint interface. In OSGi, the
>>>> NMR would listen to endpoints
>>>> registered in the OSGi registry and call the registry to register /
>>>> unregister the endpoints.
>>>> As part of the endpoint registration, the NMR would inject a
>>>> Channel into them, thus actually activating the
>>>> endpoint. I guess I could write a sequence diagram for that
>>>> (anybody knows a good tool for uml ?).
>>>> In a non OSGI environment, the Endpoint will be registered in the
>>>> Registry by calling the register method
>>>> somehow.
>>>>
>>>> The Endpoint receives Exchange to be processed on the process
>>>> method.
>>>> I think we should keep the JBI 1.0 semantics and the endpoint use
>>>> the same process as for JBI 1.0, which is
>>>> send the exchange back using the Channel (with the response /
>>>> fault / error / done). This will put the threading,
>>>> transactions and security burden on the container itself. Which
>>>> means it is easier to write JBI apps :-)
>>>>
>>>> Exchanges can be created using the Channel#createExchange method.
>>>> The only change I'd like to
>>>> integrate in the messaging API is to allow for non xml payloads and
>>>> maybe untyped attachments. The body
>>>> could be converted automatically to a given type if supported (I
>>>> think Camel does it nicely, so I'm thinking of
>>>> shamelessly copying the converter layer). I have added a few
>>>> helper methods on the exchanges and
>>>> messages (copy, copyFrom, ensureReReadable, display) to ease
>>>> message management.
>>>>
>>>> For the deployment part, there is no packaging anymore. One would
>>>> deploy an OSGi bundle that would
>>>> register the needed endpoints in the OSGi registry. For certain
>>>> types of endpoints, we may need an external
>>>> activation process (such as creating a server socket for listening
>>>> to HTTP requests) that may need to be shared
>>>> across endpoints of a given type. In such a case, you would deploy
>>>> a "component" that listens to new
>>>> endpoints implementing HttpEndpoint for example. When a new
>>>> endpoint is registered, the listener would
>>>> activate a server socket that could be shared across all http
>>>> endpoints. In a different way, if we have a BPEL
>>>> engine, the bpel "component" would listen for new bundles and look
>>>> for a specific file containing deployment
>>>> information. The component would register new endpoints in the OSGi
>>>> registry as needed (we could do that
>>>> for jaxws pojos using cxf for example).
>>>> So I said there is no more components, because this feature is not
>>>> in the api anymore, but we will certainly need
>>>> these components for some use cases. For simple endpoints, you
>>>> would not need any component at all.
>>>> Another benefit is that you can easily deploy a whole application
>>>> inside a single OSGi bundle. Using spring-osgi,
>>>> the bundle would just consist in a spring configuration file
>>>> containing the endpoints declaration and expose them
>>>> as OSGi services.
>>>>
>>>> Of course, we need to write a JBI 1.0 compatibility layer, and we
>>>> could have an intermediate layer where SAs and
>>>> JBI components could be OSGi bundles directly, thus leveraging the
>>>> OSGi classloading mechanism.
>>>>
>>>> The thing I'm not completely sure about if the Target interface
>>>> which aims to identify the target of an exchange.
>>>> I'm thinking that some metadata are associated with endpoints (like
>>>> service name, interface name, wsdl
>>>> location, etc..). These metadatas could be used to retrieve
>>>> targets using the Registry. We could plug in different
>>>> mechanisms to query the metadata (simple lookup per id, policy
>>>> based, etc...). And the result itself could be
>>>> not only a single Endpoint, but could include some policies like:
>>>> load balance between all the endpoint implementing
>>>> the given interface, etc.... Also, I think Target should be
>>>> injected on Endpoints using spring, so you would look up a
>>>> targe using a spring bean factory (or multiple ones):
>>>> <smx:endpoint-target id="my-endoint-id" />
>>>> or
>>>> <smx:interface-target name="my:qname" />
>>>> The API is quite open right now, so any ideas welcome.
>>>>
>>>> I think i covered the main areas of the API. The main goal is OSGi
>>>> and leveraging it as much as possible. There are
>>>> still some gray areas: what about the start/stop/shutdown lifecycle
>>>> which may be needed in some cases as I
>>>> discovered recently (when you want to gracefully shutdown a jms
>>>> consumer without loosing the ongoing messages
>>>> for example). I also want to give due credits to James, which has
>>>> been working with me on that.
>>>> Remember that nothing can't be changed and that' s why I'm asking
>>>> for feedback at this early stage, where there are
>>>> only ideas ;-)
>>>>
>>>> Feedback welcome....
>>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>>
>>>
>>>
>
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by rs d <rs...@gmail.com>.
I would like to attend this even.
Please let me know the details.
On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> Any other people interested ?
>
> Cheers,
> Guillaume Nodet
>
> On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote:
>
> > I'd be up for a few chat sessions!
> >
> > On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
> >>
> >> Btw, if there is sufficient interest, we could organize irc meetings
> >> to discuss these topics and post the log to the dev list for
> >> archiving
> >> and later discussion.
> >>
> >> Cheers,
> >> Guillaume Nodet
> >>
> >> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
> >>
> >>> As I explained in the other thread, I've been working on a new API
> >>> for ServiceMix 4.0.
> >>> Hopefully this will serve as an input for JBI 2.0.
> >>> This API is available at https://svn.apache.org/repos/asf/
> >>> incubator/servicemix/branches/servicemix-4.0/api
> >>>
> >>> So here a few key changes:
> >>> * clean integration with OSGi
> >>> * the NormalizedMessage can contain not only XML
> >>> * no more components
> >>> * no more JBI packaging (just use OSGi bundles)
> >>> * move the Channel to the Endpoint
> >>> * use push delivery instead of pulling exchanges
> >>> * introduce a single interface for identifying the Target of an
> >>> Exchange
> >>>
> >>> As we remove components, everything goes down to the endpoint which
> >>> become a key feature.
> >>>
> >>> The endpoint must implement the Endpoint interface. In OSGi, the
> >>> NMR would listen to endpoints
> >>> registered in the OSGi registry and call the registry to register /
> >>> unregister the endpoints.
> >>> As part of the endpoint registration, the NMR would inject a
> >>> Channel into them, thus actually activating the
> >>> endpoint. I guess I could write a sequence diagram for that
> >>> (anybody knows a good tool for uml ?).
> >>> In a non OSGI environment, the Endpoint will be registered in the
> >>> Registry by calling the register method
> >>> somehow.
> >>>
> >>> The Endpoint receives Exchange to be processed on the process
> >>> method.
> >>> I think we should keep the JBI 1.0 semantics and the endpoint use
> >>> the same process as for JBI 1.0, which is
> >>> send the exchange back using the Channel (with the response /
> >>> fault / error / done). This will put the threading,
> >>> transactions and security burden on the container itself. Which
> >>> means it is easier to write JBI apps :-)
> >>>
> >>> Exchanges can be created using the Channel#createExchange method.
> >>> The only change I'd like to
> >>> integrate in the messaging API is to allow for non xml payloads and
> >>> maybe untyped attachments. The body
> >>> could be converted automatically to a given type if supported (I
> >>> think Camel does it nicely, so I'm thinking of
> >>> shamelessly copying the converter layer). I have added a few
> >>> helper methods on the exchanges and
> >>> messages (copy, copyFrom, ensureReReadable, display) to ease
> >>> message management.
> >>>
> >>> For the deployment part, there is no packaging anymore. One would
> >>> deploy an OSGi bundle that would
> >>> register the needed endpoints in the OSGi registry. For certain
> >>> types of endpoints, we may need an external
> >>> activation process (such as creating a server socket for listening
> >>> to HTTP requests) that may need to be shared
> >>> across endpoints of a given type. In such a case, you would deploy
> >>> a "component" that listens to new
> >>> endpoints implementing HttpEndpoint for example. When a new
> >>> endpoint is registered, the listener would
> >>> activate a server socket that could be shared across all http
> >>> endpoints. In a different way, if we have a BPEL
> >>> engine, the bpel "component" would listen for new bundles and look
> >>> for a specific file containing deployment
> >>> information. The component would register new endpoints in the OSGi
> >>> registry as needed (we could do that
> >>> for jaxws pojos using cxf for example).
> >>> So I said there is no more components, because this feature is not
> >>> in the api anymore, but we will certainly need
> >>> these components for some use cases. For simple endpoints, you
> >>> would not need any component at all.
> >>> Another benefit is that you can easily deploy a whole application
> >>> inside a single OSGi bundle. Using spring-osgi,
> >>> the bundle would just consist in a spring configuration file
> >>> containing the endpoints declaration and expose them
> >>> as OSGi services.
> >>>
> >>> Of course, we need to write a JBI 1.0 compatibility layer, and we
> >>> could have an intermediate layer where SAs and
> >>> JBI components could be OSGi bundles directly, thus leveraging the
> >>> OSGi classloading mechanism.
> >>>
> >>> The thing I'm not completely sure about if the Target interface
> >>> which aims to identify the target of an exchange.
> >>> I'm thinking that some metadata are associated with endpoints (like
> >>> service name, interface name, wsdl
> >>> location, etc..). These metadatas could be used to retrieve
> >>> targets using the Registry. We could plug in different
> >>> mechanisms to query the metadata (simple lookup per id, policy
> >>> based, etc...). And the result itself could be
> >>> not only a single Endpoint, but could include some policies like:
> >>> load balance between all the endpoint implementing
> >>> the given interface, etc.... Also, I think Target should be
> >>> injected on Endpoints using spring, so you would look up a
> >>> targe using a spring bean factory (or multiple ones):
> >>> <smx:endpoint-target id="my-endoint-id" />
> >>> or
> >>> <smx:interface-target name="my:qname" />
> >>> The API is quite open right now, so any ideas welcome.
> >>>
> >>> I think i covered the main areas of the API. The main goal is OSGi
> >>> and leveraging it as much as possible. There are
> >>> still some gray areas: what about the start/stop/shutdown lifecycle
> >>> which may be needed in some cases as I
> >>> discovered recently (when you want to gracefully shutdown a jms
> >>> consumer without loosing the ongoing messages
> >>> for example). I also want to give due credits to James, which has
> >>> been working with me on that.
> >>> Remember that nothing can't be changed and that' s why I'm asking
> >>> for feedback at this early stage, where there are
> >>> only ideas ;-)
> >>>
> >>> Feedback welcome....
> >>>
> >>> Cheers,
> >>> Guillaume Nodet
> >>>
> >>>
> >>
> >>
>
>
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Kit Plummer <ki...@gmail.com>.
On 8/24/07, Bruce Snyder <br...@gmail.com> wrote:
>
> On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
> > Any other people interested ?
>
> +1
>
> 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/
>
Here here.
--
Kit Plummer
Nobody-in-Charge @ Black:Hole:Logic
http://www.blackholelogic.com
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Bruce Snyder <br...@gmail.com>.
On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
> Any other people interested ?
+1
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: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Adrian Co <ac...@exist.com>.
I'm interested too.
Brian O'Neill wrote:
> Yes. I'm in.
>
> -brian
>
> On 8/24/07, Gordon Dickens <gd...@anexinet.com> wrote:
>
>> I too would like to listen in.
>>
>> Regards,
>> Gordon
>>
>> Daryl Richter wrote:
>>
>>> On Aug 24, 2007, at 5:04 AM, Nodet Guillaume wrote:
>>>
>>>
>>>
>>>> Any other people interested ?
>>>>
>>>>
>>>>
>>> I wouldn't mind listening in. We are in the very early stages of a
>>> ServiceMix implementation, though, so I don't have a lot of
>>> opinions... yet. :)
>>>
>>>
>>>
>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Daryl
>>> http://itsallsemantics.com
>>>
>>> "We want great men who, when fortune frowns, will not be discouraged."
>>> -- Colonel Henry Knox, 1776
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Brian O'Neill <bo...@alumni.brown.edu>.
Yes. I'm in.
-brian
On 8/24/07, Gordon Dickens <gd...@anexinet.com> wrote:
> I too would like to listen in.
>
> Regards,
> Gordon
>
> Daryl Richter wrote:
> > On Aug 24, 2007, at 5:04 AM, Nodet Guillaume wrote:
> >
> >
> >> Any other people interested ?
> >>
> >>
> >
> > I wouldn't mind listening in. We are in the very early stages of a
> > ServiceMix implementation, though, so I don't have a lot of
> > opinions... yet. :)
> >
> >
> >
> >> Cheers,
> >> Guillaume Nodet
> >>
> >>
> >>
> > --
> > Daryl
> > http://itsallsemantics.com
> >
> > "We want great men who, when fortune frowns, will not be discouraged."
> > -- Colonel Henry Knox, 1776
> >
> >
> >
> >
> >
> >
> >
> >
>
>
--
Brian ONeill
Source Equity (http://www.sourceequity.com)
jBIZint (http://www.jbizint.org)
Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
mobile:215.588.6024
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Gordon Dickens <gd...@anexinet.com>.
I too would like to listen in.
Regards,
Gordon
Daryl Richter wrote:
> On Aug 24, 2007, at 5:04 AM, Nodet Guillaume wrote:
>
>
>> Any other people interested ?
>>
>>
>
> I wouldn't mind listening in. We are in the very early stages of a
> ServiceMix implementation, though, so I don't have a lot of
> opinions... yet. :)
>
>
>
>> Cheers,
>> Guillaume Nodet
>>
>>
>>
> --
> Daryl
> http://itsallsemantics.com
>
> "We want great men who, when fortune frowns, will not be discouraged."
> -- Colonel Henry Knox, 1776
>
>
>
>
>
>
>
>
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Daryl Richter <ng...@comcast.net>.
On Aug 24, 2007, at 5:04 AM, Nodet Guillaume wrote:
> Any other people interested ?
>
I wouldn't mind listening in. We are in the very early stages of a
ServiceMix implementation, though, so I don't have a lot of
opinions... yet. :)
> Cheers,
> Guillaume Nodet
>
>
--
Daryl
http://itsallsemantics.com
"We want great men who, when fortune frowns, will not be discouraged."
-- Colonel Henry Knox, 1776
IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
Any other people interested ?
Cheers,
Guillaume Nodet
On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote:
> I'd be up for a few chat sessions!
>
> On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>
>> Btw, if there is sufficient interest, we could organize irc meetings
>> to discuss these topics and post the log to the dev list for
>> archiving
>> and later discussion.
>>
>> Cheers,
>> Guillaume Nodet
>>
>> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
>>
>>> As I explained in the other thread, I've been working on a new API
>>> for ServiceMix 4.0.
>>> Hopefully this will serve as an input for JBI 2.0.
>>> This API is available at https://svn.apache.org/repos/asf/
>>> incubator/servicemix/branches/servicemix-4.0/api
>>>
>>> So here a few key changes:
>>> * clean integration with OSGi
>>> * the NormalizedMessage can contain not only XML
>>> * no more components
>>> * no more JBI packaging (just use OSGi bundles)
>>> * move the Channel to the Endpoint
>>> * use push delivery instead of pulling exchanges
>>> * introduce a single interface for identifying the Target of an
>>> Exchange
>>>
>>> As we remove components, everything goes down to the endpoint which
>>> become a key feature.
>>>
>>> The endpoint must implement the Endpoint interface. In OSGi, the
>>> NMR would listen to endpoints
>>> registered in the OSGi registry and call the registry to register /
>>> unregister the endpoints.
>>> As part of the endpoint registration, the NMR would inject a
>>> Channel into them, thus actually activating the
>>> endpoint. I guess I could write a sequence diagram for that
>>> (anybody knows a good tool for uml ?).
>>> In a non OSGI environment, the Endpoint will be registered in the
>>> Registry by calling the register method
>>> somehow.
>>>
>>> The Endpoint receives Exchange to be processed on the process
>>> method.
>>> I think we should keep the JBI 1.0 semantics and the endpoint use
>>> the same process as for JBI 1.0, which is
>>> send the exchange back using the Channel (with the response /
>>> fault / error / done). This will put the threading,
>>> transactions and security burden on the container itself. Which
>>> means it is easier to write JBI apps :-)
>>>
>>> Exchanges can be created using the Channel#createExchange method.
>>> The only change I'd like to
>>> integrate in the messaging API is to allow for non xml payloads and
>>> maybe untyped attachments. The body
>>> could be converted automatically to a given type if supported (I
>>> think Camel does it nicely, so I'm thinking of
>>> shamelessly copying the converter layer). I have added a few
>>> helper methods on the exchanges and
>>> messages (copy, copyFrom, ensureReReadable, display) to ease
>>> message management.
>>>
>>> For the deployment part, there is no packaging anymore. One would
>>> deploy an OSGi bundle that would
>>> register the needed endpoints in the OSGi registry. For certain
>>> types of endpoints, we may need an external
>>> activation process (such as creating a server socket for listening
>>> to HTTP requests) that may need to be shared
>>> across endpoints of a given type. In such a case, you would deploy
>>> a "component" that listens to new
>>> endpoints implementing HttpEndpoint for example. When a new
>>> endpoint is registered, the listener would
>>> activate a server socket that could be shared across all http
>>> endpoints. In a different way, if we have a BPEL
>>> engine, the bpel "component" would listen for new bundles and look
>>> for a specific file containing deployment
>>> information. The component would register new endpoints in the OSGi
>>> registry as needed (we could do that
>>> for jaxws pojos using cxf for example).
>>> So I said there is no more components, because this feature is not
>>> in the api anymore, but we will certainly need
>>> these components for some use cases. For simple endpoints, you
>>> would not need any component at all.
>>> Another benefit is that you can easily deploy a whole application
>>> inside a single OSGi bundle. Using spring-osgi,
>>> the bundle would just consist in a spring configuration file
>>> containing the endpoints declaration and expose them
>>> as OSGi services.
>>>
>>> Of course, we need to write a JBI 1.0 compatibility layer, and we
>>> could have an intermediate layer where SAs and
>>> JBI components could be OSGi bundles directly, thus leveraging the
>>> OSGi classloading mechanism.
>>>
>>> The thing I'm not completely sure about if the Target interface
>>> which aims to identify the target of an exchange.
>>> I'm thinking that some metadata are associated with endpoints (like
>>> service name, interface name, wsdl
>>> location, etc..). These metadatas could be used to retrieve
>>> targets using the Registry. We could plug in different
>>> mechanisms to query the metadata (simple lookup per id, policy
>>> based, etc...). And the result itself could be
>>> not only a single Endpoint, but could include some policies like:
>>> load balance between all the endpoint implementing
>>> the given interface, etc.... Also, I think Target should be
>>> injected on Endpoints using spring, so you would look up a
>>> targe using a spring bean factory (or multiple ones):
>>> <smx:endpoint-target id="my-endoint-id" />
>>> or
>>> <smx:interface-target name="my:qname" />
>>> The API is quite open right now, so any ideas welcome.
>>>
>>> I think i covered the main areas of the API. The main goal is OSGi
>>> and leveraging it as much as possible. There are
>>> still some gray areas: what about the start/stop/shutdown lifecycle
>>> which may be needed in some cases as I
>>> discovered recently (when you want to gracefully shutdown a jms
>>> consumer without loosing the ongoing messages
>>> for example). I also want to give due credits to James, which has
>>> been working with me on that.
>>> Remember that nothing can't be changed and that' s why I'm asking
>>> for feedback at this early stage, where there are
>>> only ideas ;-)
>>>
>>> Feedback welcome....
>>>
>>> Cheers,
>>> Guillaume Nodet
>>>
>>>
>>
>>
Re: ServiceMix 4.0
Posted by Kit Plummer <ki...@gmail.com>.
I'd be up for a few chat sessions!
On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> Btw, if there is sufficient interest, we could organize irc meetings
> to discuss these topics and post the log to the dev list for archiving
> and later discussion.
>
> Cheers,
> Guillaume Nodet
>
> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
>
> > As I explained in the other thread, I've been working on a new API
> > for ServiceMix 4.0.
> > Hopefully this will serve as an input for JBI 2.0.
> > This API is available at https://svn.apache.org/repos/asf/
> > incubator/servicemix/branches/servicemix-4.0/api
> >
> > So here a few key changes:
> > * clean integration with OSGi
> > * the NormalizedMessage can contain not only XML
> > * no more components
> > * no more JBI packaging (just use OSGi bundles)
> > * move the Channel to the Endpoint
> > * use push delivery instead of pulling exchanges
> > * introduce a single interface for identifying the Target of an
> > Exchange
> >
> > As we remove components, everything goes down to the endpoint which
> > become a key feature.
> >
> > The endpoint must implement the Endpoint interface. In OSGi, the
> > NMR would listen to endpoints
> > registered in the OSGi registry and call the registry to register /
> > unregister the endpoints.
> > As part of the endpoint registration, the NMR would inject a
> > Channel into them, thus actually activating the
> > endpoint. I guess I could write a sequence diagram for that
> > (anybody knows a good tool for uml ?).
> > In a non OSGI environment, the Endpoint will be registered in the
> > Registry by calling the register method
> > somehow.
> >
> > The Endpoint receives Exchange to be processed on the process method.
> > I think we should keep the JBI 1.0 semantics and the endpoint use
> > the same process as for JBI 1.0, which is
> > send the exchange back using the Channel (with the response /
> > fault / error / done). This will put the threading,
> > transactions and security burden on the container itself. Which
> > means it is easier to write JBI apps :-)
> >
> > Exchanges can be created using the Channel#createExchange method.
> > The only change I'd like to
> > integrate in the messaging API is to allow for non xml payloads and
> > maybe untyped attachments. The body
> > could be converted automatically to a given type if supported (I
> > think Camel does it nicely, so I'm thinking of
> > shamelessly copying the converter layer). I have added a few
> > helper methods on the exchanges and
> > messages (copy, copyFrom, ensureReReadable, display) to ease
> > message management.
> >
> > For the deployment part, there is no packaging anymore. One would
> > deploy an OSGi bundle that would
> > register the needed endpoints in the OSGi registry. For certain
> > types of endpoints, we may need an external
> > activation process (such as creating a server socket for listening
> > to HTTP requests) that may need to be shared
> > across endpoints of a given type. In such a case, you would deploy
> > a "component" that listens to new
> > endpoints implementing HttpEndpoint for example. When a new
> > endpoint is registered, the listener would
> > activate a server socket that could be shared across all http
> > endpoints. In a different way, if we have a BPEL
> > engine, the bpel "component" would listen for new bundles and look
> > for a specific file containing deployment
> > information. The component would register new endpoints in the OSGi
> > registry as needed (we could do that
> > for jaxws pojos using cxf for example).
> > So I said there is no more components, because this feature is not
> > in the api anymore, but we will certainly need
> > these components for some use cases. For simple endpoints, you
> > would not need any component at all.
> > Another benefit is that you can easily deploy a whole application
> > inside a single OSGi bundle. Using spring-osgi,
> > the bundle would just consist in a spring configuration file
> > containing the endpoints declaration and expose them
> > as OSGi services.
> >
> > Of course, we need to write a JBI 1.0 compatibility layer, and we
> > could have an intermediate layer where SAs and
> > JBI components could be OSGi bundles directly, thus leveraging the
> > OSGi classloading mechanism.
> >
> > The thing I'm not completely sure about if the Target interface
> > which aims to identify the target of an exchange.
> > I'm thinking that some metadata are associated with endpoints (like
> > service name, interface name, wsdl
> > location, etc..). These metadatas could be used to retrieve
> > targets using the Registry. We could plug in different
> > mechanisms to query the metadata (simple lookup per id, policy
> > based, etc...). And the result itself could be
> > not only a single Endpoint, but could include some policies like:
> > load balance between all the endpoint implementing
> > the given interface, etc.... Also, I think Target should be
> > injected on Endpoints using spring, so you would look up a
> > targe using a spring bean factory (or multiple ones):
> > <smx:endpoint-target id="my-endoint-id" />
> > or
> > <smx:interface-target name="my:qname" />
> > The API is quite open right now, so any ideas welcome.
> >
> > I think i covered the main areas of the API. The main goal is OSGi
> > and leveraging it as much as possible. There are
> > still some gray areas: what about the start/stop/shutdown lifecycle
> > which may be needed in some cases as I
> > discovered recently (when you want to gracefully shutdown a jms
> > consumer without loosing the ongoing messages
> > for example). I also want to give due credits to James, which has
> > been working with me on that.
> > Remember that nothing can't be changed and that' s why I'm asking
> > for feedback at this early stage, where there are
> > only ideas ;-)
> >
> > Feedback welcome....
> >
> > Cheers,
> > Guillaume Nodet
> >
> >
>
>
Re: ServiceMix 4.0
Posted by Terry Cox <te...@meta-concepts.com>.
Feel free to let me know when this is scheduled and I will try and
attend.
Terry
Re: ServiceMix 4.0
Posted by Nodet Guillaume <gn...@gmail.com>.
Btw, if there is sufficient interest, we could organize irc meetings
to discuss these topics and post the log to the dev list for archiving
and later discussion.
Cheers,
Guillaume Nodet
On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote:
> As I explained in the other thread, I've been working on a new API
> for ServiceMix 4.0.
> Hopefully this will serve as an input for JBI 2.0.
> This API is available at https://svn.apache.org/repos/asf/
> incubator/servicemix/branches/servicemix-4.0/api
>
> So here a few key changes:
> * clean integration with OSGi
> * the NormalizedMessage can contain not only XML
> * no more components
> * no more JBI packaging (just use OSGi bundles)
> * move the Channel to the Endpoint
> * use push delivery instead of pulling exchanges
> * introduce a single interface for identifying the Target of an
> Exchange
>
> As we remove components, everything goes down to the endpoint which
> become a key feature.
>
> The endpoint must implement the Endpoint interface. In OSGi, the
> NMR would listen to endpoints
> registered in the OSGi registry and call the registry to register /
> unregister the endpoints.
> As part of the endpoint registration, the NMR would inject a
> Channel into them, thus actually activating the
> endpoint. I guess I could write a sequence diagram for that
> (anybody knows a good tool for uml ?).
> In a non OSGI environment, the Endpoint will be registered in the
> Registry by calling the register method
> somehow.
>
> The Endpoint receives Exchange to be processed on the process method.
> I think we should keep the JBI 1.0 semantics and the endpoint use
> the same process as for JBI 1.0, which is
> send the exchange back using the Channel (with the response /
> fault / error / done). This will put the threading,
> transactions and security burden on the container itself. Which
> means it is easier to write JBI apps :-)
>
> Exchanges can be created using the Channel#createExchange method.
> The only change I'd like to
> integrate in the messaging API is to allow for non xml payloads and
> maybe untyped attachments. The body
> could be converted automatically to a given type if supported (I
> think Camel does it nicely, so I'm thinking of
> shamelessly copying the converter layer). I have added a few
> helper methods on the exchanges and
> messages (copy, copyFrom, ensureReReadable, display) to ease
> message management.
>
> For the deployment part, there is no packaging anymore. One would
> deploy an OSGi bundle that would
> register the needed endpoints in the OSGi registry. For certain
> types of endpoints, we may need an external
> activation process (such as creating a server socket for listening
> to HTTP requests) that may need to be shared
> across endpoints of a given type. In such a case, you would deploy
> a "component" that listens to new
> endpoints implementing HttpEndpoint for example. When a new
> endpoint is registered, the listener would
> activate a server socket that could be shared across all http
> endpoints. In a different way, if we have a BPEL
> engine, the bpel "component" would listen for new bundles and look
> for a specific file containing deployment
> information. The component would register new endpoints in the OSGi
> registry as needed (we could do that
> for jaxws pojos using cxf for example).
> So I said there is no more components, because this feature is not
> in the api anymore, but we will certainly need
> these components for some use cases. For simple endpoints, you
> would not need any component at all.
> Another benefit is that you can easily deploy a whole application
> inside a single OSGi bundle. Using spring-osgi,
> the bundle would just consist in a spring configuration file
> containing the endpoints declaration and expose them
> as OSGi services.
>
> Of course, we need to write a JBI 1.0 compatibility layer, and we
> could have an intermediate layer where SAs and
> JBI components could be OSGi bundles directly, thus leveraging the
> OSGi classloading mechanism.
>
> The thing I'm not completely sure about if the Target interface
> which aims to identify the target of an exchange.
> I'm thinking that some metadata are associated with endpoints (like
> service name, interface name, wsdl
> location, etc..). These metadatas could be used to retrieve
> targets using the Registry. We could plug in different
> mechanisms to query the metadata (simple lookup per id, policy
> based, etc...). And the result itself could be
> not only a single Endpoint, but could include some policies like:
> load balance between all the endpoint implementing
> the given interface, etc.... Also, I think Target should be
> injected on Endpoints using spring, so you would look up a
> targe using a spring bean factory (or multiple ones):
> <smx:endpoint-target id="my-endoint-id" />
> or
> <smx:interface-target name="my:qname" />
> The API is quite open right now, so any ideas welcome.
>
> I think i covered the main areas of the API. The main goal is OSGi
> and leveraging it as much as possible. There are
> still some gray areas: what about the start/stop/shutdown lifecycle
> which may be needed in some cases as I
> discovered recently (when you want to gracefully shutdown a jms
> consumer without loosing the ongoing messages
> for example). I also want to give due credits to James, which has
> been working with me on that.
> Remember that nothing can't be changed and that' s why I'm asking
> for feedback at this early stage, where there are
> only ideas ;-)
>
> Feedback welcome....
>
> Cheers,
> Guillaume Nodet
>
>
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Posted by Bruce Snyder <br...@gmail.com>.
On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> On Aug 24, 2007, at 6:44 PM, Bruce Snyder wrote:
>
> > On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
> >>
> >> On the registry side, I think one of the main problem is that there
> >> is no way to tell the
> >> difference between an endpoint that goes down because the server is
> >> no more
> >> accessibe (it will be up again at a later time) or because the
> >> endpoint has been
> >> undeployed. Imho, this is a key requirement to be able to make
> >> routing decisions.
> >> I don't know yet how to handle this problem: if a server has been
> >> shutdown, it may
> >> never go up again... So i'm still not sure how to handle the
> >> problem :-(
> >
> > This is one place where a proper registry might be useful. If the
> > registry handles metadata for a given component, it can provide this
> > type of finer grained information to anyone that is interested. E.g.,
> > if a component is undeployed, the deployer tells the registry that
> > componentX is being undeployed and the registry would store that
> > information. When componentX comes back online it tells the registry
> > and the registry updates the metadata.
> >
>
> I agree, but it may not even be sufficient. Let's take the example
> of Kit.
> This environment is very dynamic and instances will not even say
> that the endpoints are undeployed. They are just gone and may never
> appear again. Another example: if you use a cluster of servers and you
> want to bring one down, will you really undeploy everything or just shut
> ServiceMix down ?
>
> So I'm not sure you can really know wether a service will come up at a
> later time. This requires much more knowledge that ServiceMix can
> have. I guess we could have a default behavior that would say when a
> server goes down if the endpoints should be considered temporarily
> unavailable or permanently lost.
Well, if it's gone, it's gone. That component cannot be used. I was
assuming that this status would be used to determine how to handle
messages destined for a component that is not online. E.g.:
a) componentX is marked as undeployed in the registry so it's gone and
messages should not be held for it
b) componentX is marked as stopped in the registry which means it will
be started up again at a later time, so hold messages for it until it
comes back online
This means that certain states assume certain behavior that might work
in a manner similar to a lifecycle. E.g., if a component is in the
process of being started up, messages destined for that component
should be held until the component is fully started.
> We currently don't have such a feature in the JMS/JCA flows, but we
> definitely need something around that...
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: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
On Aug 24, 2007, at 6:44 PM, Bruce Snyder wrote:
> On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>
>> On the registry side, I think one of the main problem is that there
>> is no way to tell the
>> difference between an endpoint that goes down because the server is
>> no more
>> accessibe (it will be up again at a later time) or because the
>> endpoint has been
>> undeployed. Imho, this is a key requirement to be able to make
>> routing decisions.
>> I don't know yet how to handle this problem: if a server has been
>> shutdown, it may
>> never go up again... So i'm still not sure how to handle the
>> problem :-(
>
> This is one place where a proper registry might be useful. If the
> registry handles metadata for a given component, it can provide this
> type of finer grained information to anyone that is interested. E.g.,
> if a component is undeployed, the deployer tells the registry that
> componentX is being undeployed and the registry would store that
> information. When componentX comes back online it tells the registry
> and the registry updates the metadata.
>
I agree, but it may not even be sufficient. Let's take the example
of Kit.
This environment is very dynamic and instances will not even say
that the endpoints are undeployed. They are just gone and may never
appear again. Another example: if you use a cluster of servers and you
want to bring one down, will you really undeploy everything or just shut
ServiceMix down ?
So I'm not sure you can really know wether a service will come up at a
later time. This requires much more knowledge that ServiceMix can
have. I guess we could have a default behavior that would say when a
server goes down if the endpoints should be considered temporarily
unavailable or permanently lost.
We currently don't have such a feature in the JMS/JCA flows, but we
definitely need something around that...
Cheers,
Guillaume Nodet
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Posted by Bruce Snyder <br...@gmail.com>.
On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
> So if i understand you correctly, you are mostly concerned of enhancing
> the JMS flow in the following areas:
> * avoid ping/pong and lower bandwidth requirement
> (avoid sending the whole exchange and only send the actual data)
> * enhance security (authentication, encryption ?)
> * enhance the endoint registry wrt to services or instances going
> up and down
>
>
> Did I catch you correcty ?
>
> For the bandwidh requirement, I'm sure we can do that and reconstruct
> a fake
> exchange on the other side. We would loose informations wrt to the
> input message
> but I don't think this would be too much a problem. For the ping/
> pong stuff, I'm sure
> we can find a way to optimize it somehow. We may have troubles
> handling the
> InOptionalOut pattern though, as you don't really know if you will
> receive an Out
> message or nothing, but for the other simple patterns (InOnly and
> InOut) it should
> be quite easy to send back the exchange with a DONE status just after
> having send
> the jms message containing the In or Out.
>
> On the security subject, I know there is lots to do, but this is an
> area i'm not so familiar
> with. My biggest concern is that we security can be applied at the
> connection level
> or at the message level. NMR-NMR security for the JMS flow could be
> delegated
> to ActiveMQ i guess (using AMQ security features).
An interceptor framework might help this situation where the necessary
authentication and authorization interceptors could be added to handle
the situation. Then it's just up to the implementation of each.
> On the registry side, I think one of the main problem is that there
> is no way to tell the
> difference between an endpoint that goes down because the server is
> no more
> accessibe (it will be up again at a later time) or because the
> endpoint has been
> undeployed. Imho, this is a key requirement to be able to make
> routing decisions.
> I don't know yet how to handle this problem: if a server has been
> shutdown, it may
> never go up again... So i'm still not sure how to handle the problem :-(
This is one place where a proper registry might be useful. If the
registry handles metadata for a given component, it can provide this
type of finer grained information to anyone that is interested. E.g.,
if a component is undeployed, the deployer tells the registry that
componentX is being undeployed and the registry would store that
information. When componentX comes back online it tells the registry
and the registry updates the metadata.
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: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
On Aug 24, 2007, at 7:28 PM, Kit Plummer wrote:
> On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>
>> So if i understand you correctly, you are mostly concerned of
>> enhancing
>> the JMS flow in the following areas:
>> * avoid ping/pong and lower bandwidth requirement
>> (avoid sending the whole exchange and only send the actual
>> data)
>> * enhance security (authentication, encryption ?)
>> * enhance the endoint registry wrt to services or instances going
>> up and down
>
>
>
> Did I catch you correcty ?
>
>
> Yes. The registry piece is a little interesting for us to.
> Because we
> are integrating "hardware" via service components we've had to
> abstract the
> notion of capabilities. It would be nice if the registry were
> extensible.
If we leverage the OSGi registry, you can associate a bunch of metadata
to each service registered in the registry (in our cases, endpoints).
Cheers,
Guillaume Nodet
>
> For the bandwidh requirement, I'm sure we can do that and reconstruct
>> a fake
>> exchange on the other side. We would loose informations wrt to the
>> input message
>> but I don't think this would be too much a problem. For the ping/
>> pong stuff, I'm sure
>> we can find a way to optimize it somehow. We may have troubles
>> handling the
>> InOptionalOut pattern though, as you don't really know if you will
>> receive an Out
>> message or nothing, but for the other simple patterns (InOnly and
>> InOut) it should
>> be quite easy to send back the exchange with a DONE status just after
>> having send
>> the jms message containing the In or Out.
>
>
> I think as long as everything is optional wrt to optimizations the
> fact that
> it may exclude various patterns is acceptable. We've done
> everything in an
> InOnly world.
>
>
> On the security subject, I know there is lots to do, but this is an
>> area i'm not so familiar
>> with. My biggest concern is that we security can be applied at the
>> connection level
>> or at the message level. NMR-NMR security for the JMS flow could be
>> delegated
>> to ActiveMQ i guess (using AMQ security features).
>
>
> Agreed. It is now...the Network of Brokers feature. But, there is
> not
> really any concept of policy.
>
> On the registry side, I think one of the main problem is that there
>> is no way to tell the
>> difference between an endpoint that goes down because the server is
>> no more
>> accessibe (it will be up again at a later time) or because the
>> endpoint has been
>> undeployed. Imho, this is a key requirement to be able to make
>> routing decisions.
>> I don't know yet how to handle this problem: if a server has been
>> shutdown, it may
>> never go up again...
>
>
> Yeh, like if it has been blown up by an IED...
>
>> So i'm still not sure how to handle the problem :-(
> Yep, you are right. Right now if we undeploy a service assembly, its
> endpoint still exists, and messages are still routed to it. Could
> just be a
> bug. ; }
>
> I'm sure more discussion on this will follow.
>
>
> Cheers,
>> Guillaume Nodet
>>
>> On Aug 23, 2007, at 3:35 PM, Kit Plummer wrote:
>>
>>> Sure Guillaume.
>>>
>>> Maybe the best thing to do is explain the concept...and what we've
>>> done to
>>> meet our requirements.
>>>
>>> It is actually quite simple. We needed to be able to connect two
>>> computers
>>> together via TCP/IP, and have a publisher on one system, the
>>> consumer on the
>>> other. Granted we've got lot's of both on each - but, the premise
>>> is that
>>> link between is transparent.
>>>
>>> Currently, we are using a feature of ActiveMQ called "Network of
>>> Brokers"
>>> (NoB) to create a mapping of destinations/endpoints.
>>>
>>> Where it gets really complicated is when we only want to allow a
>>> specific
>>> MEPs to cross the NoB connection. In this example, bandwidth is
>>> not a
>>> commodity and must be tightly constrained. We were tolerant of all
>>> the SEDA
>>> flow handshaking, but I believe it would be nice if InOnly MEPS
>>> really were
>>> just a single transmission (turning off levels of reliability/
>>> durability).
>>> Also, in our environment multicast isn't possible, and the networks
>>> are
>>> fairly ad-hoc...meaning not stable. Plus, we need to know about
>>> the state
>>> of the link.
>>>
>>> Service registration happens also in different configurations. For
>>> example,
>>> one topology we support is a hierarchical flow (master-slaves).
>>> Imagine a
>>> simple sensor net. There would be a single point at the top, where
>>> are data
>>> were to be aggregated. So, in this example the NoBs need to support
>>> "followers" only communicating with their "leader"...and the
>>> "leader" only
>>> communicating with its "leader". But, there might also be a need
>>> to have
>>> "shared" data that is available on all platforms in network
>>> (health, state,
>>> etc.). Ding lifecycle.
>>>
>>> I could keep going...but, am curious if anyone else looks at it
>>> this way.
>>> Obviously, the notion of simple performance scalability is one way
>>> to look
>>> at. There is a lot of capability in the NoB, but I think it falls
>>> a bit
>>> short. There are a few features that we'd like to see, that would
>>> help us
>>> federate better. BC/SE/SA-level authentication to the bus, as
>>> well as
>>> platform-to-platform, or NMR-to-NMR authentication would be very
>>> helpful.
>>> We've been looking at grid/cluster-like capabilities too - for
>>> example, if
>>> one platform is maxed out from a processing perspective, sending
>>> the SA and
>>> the message/task to another platform in network automatically.
>>>
>>> Thanks for taking the time to do this.
>>>
>>> On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>>>
>>>> Hi Kit,
>>>>
>>>> I'm quite sure you would have a very valuable input there, given
>>>> your
>>>> experience
>>>> on ServiceMix. So I'm starting this new thread. Would you mind
>>>> throwing a few
>>>> ideas there ?
>>>>
>>>> Cheers,
>>>> Guillaume Nodet
>>>>
>>>>
>>>> On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote:
>>>>
>>>>> On 8/22/07, Terry Cox <te...@meta-concepts.com> wrote:
>>>>>>
>>>>>> Interesting.
>>>>>>
>>>>>> We need to have a very serious chat about application lifecycles
>>>>>> and
>>>>>> governance...
>>>>>>
>>>>>> Terry
>>>>>>
>>>>>
>>>>>
>>>>> And Federating...distribution of the NMR across n-platforms!
>>>>>
>>>>> --
>>>>> Kit Plummer
>>>>> Nobody-in-Charge @ Black:Hole:Logic
>>>>> http://www.blackholelogic.com
>>>>
>>>>
>>
>>
>
>
> --
> Kit Plummer
> Nobody-in-Charge @ Black:Hole:Logic
> http://www.blackholelogic.com
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Posted by Kit Plummer <ki...@gmail.com>.
On 8/24/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> So if i understand you correctly, you are mostly concerned of enhancing
> the JMS flow in the following areas:
> * avoid ping/pong and lower bandwidth requirement
> (avoid sending the whole exchange and only send the actual data)
> * enhance security (authentication, encryption ?)
> * enhance the endoint registry wrt to services or instances going
> up and down
Did I catch you correcty ?
Yes. The registry piece is a little interesting for us to. Because we
are integrating "hardware" via service components we've had to abstract the
notion of capabilities. It would be nice if the registry were extensible.
For the bandwidh requirement, I'm sure we can do that and reconstruct
> a fake
> exchange on the other side. We would loose informations wrt to the
> input message
> but I don't think this would be too much a problem. For the ping/
> pong stuff, I'm sure
> we can find a way to optimize it somehow. We may have troubles
> handling the
> InOptionalOut pattern though, as you don't really know if you will
> receive an Out
> message or nothing, but for the other simple patterns (InOnly and
> InOut) it should
> be quite easy to send back the exchange with a DONE status just after
> having send
> the jms message containing the In or Out.
I think as long as everything is optional wrt to optimizations the fact that
it may exclude various patterns is acceptable. We've done everything in an
InOnly world.
On the security subject, I know there is lots to do, but this is an
> area i'm not so familiar
> with. My biggest concern is that we security can be applied at the
> connection level
> or at the message level. NMR-NMR security for the JMS flow could be
> delegated
> to ActiveMQ i guess (using AMQ security features).
Agreed. It is now...the Network of Brokers feature. But, there is not
really any concept of policy.
On the registry side, I think one of the main problem is that there
> is no way to tell the
> difference between an endpoint that goes down because the server is
> no more
> accessibe (it will be up again at a later time) or because the
> endpoint has been
> undeployed. Imho, this is a key requirement to be able to make
> routing decisions.
> I don't know yet how to handle this problem: if a server has been
> shutdown, it may
> never go up again...
Yeh, like if it has been blown up by an IED...
> So i'm still not sure how to handle the problem :-(
Yep, you are right. Right now if we undeploy a service assembly, its
endpoint still exists, and messages are still routed to it. Could just be a
bug. ; }
I'm sure more discussion on this will follow.
Cheers,
> Guillaume Nodet
>
> On Aug 23, 2007, at 3:35 PM, Kit Plummer wrote:
>
> > Sure Guillaume.
> >
> > Maybe the best thing to do is explain the concept...and what we've
> > done to
> > meet our requirements.
> >
> > It is actually quite simple. We needed to be able to connect two
> > computers
> > together via TCP/IP, and have a publisher on one system, the
> > consumer on the
> > other. Granted we've got lot's of both on each - but, the premise
> > is that
> > link between is transparent.
> >
> > Currently, we are using a feature of ActiveMQ called "Network of
> > Brokers"
> > (NoB) to create a mapping of destinations/endpoints.
> >
> > Where it gets really complicated is when we only want to allow a
> > specific
> > MEPs to cross the NoB connection. In this example, bandwidth is not a
> > commodity and must be tightly constrained. We were tolerant of all
> > the SEDA
> > flow handshaking, but I believe it would be nice if InOnly MEPS
> > really were
> > just a single transmission (turning off levels of reliability/
> > durability).
> > Also, in our environment multicast isn't possible, and the networks
> > are
> > fairly ad-hoc...meaning not stable. Plus, we need to know about
> > the state
> > of the link.
> >
> > Service registration happens also in different configurations. For
> > example,
> > one topology we support is a hierarchical flow (master-slaves).
> > Imagine a
> > simple sensor net. There would be a single point at the top, where
> > are data
> > were to be aggregated. So, in this example the NoBs need to support
> > "followers" only communicating with their "leader"...and the
> > "leader" only
> > communicating with its "leader". But, there might also be a need
> > to have
> > "shared" data that is available on all platforms in network
> > (health, state,
> > etc.). Ding lifecycle.
> >
> > I could keep going...but, am curious if anyone else looks at it
> > this way.
> > Obviously, the notion of simple performance scalability is one way
> > to look
> > at. There is a lot of capability in the NoB, but I think it falls
> > a bit
> > short. There are a few features that we'd like to see, that would
> > help us
> > federate better. BC/SE/SA-level authentication to the bus, as well as
> > platform-to-platform, or NMR-to-NMR authentication would be very
> > helpful.
> > We've been looking at grid/cluster-like capabilities too - for
> > example, if
> > one platform is maxed out from a processing perspective, sending
> > the SA and
> > the message/task to another platform in network automatically.
> >
> > Thanks for taking the time to do this.
> >
> > On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
> >>
> >> Hi Kit,
> >>
> >> I'm quite sure you would have a very valuable input there, given your
> >> experience
> >> on ServiceMix. So I'm starting this new thread. Would you mind
> >> throwing a few
> >> ideas there ?
> >>
> >> Cheers,
> >> Guillaume Nodet
> >>
> >>
> >> On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote:
> >>
> >>> On 8/22/07, Terry Cox <te...@meta-concepts.com> wrote:
> >>>>
> >>>> Interesting.
> >>>>
> >>>> We need to have a very serious chat about application lifecycles
> >>>> and
> >>>> governance...
> >>>>
> >>>> Terry
> >>>>
> >>>
> >>>
> >>> And Federating...distribution of the NMR across n-platforms!
> >>>
> >>> --
> >>> Kit Plummer
> >>> Nobody-in-Charge @ Black:Hole:Logic
> >>> http://www.blackholelogic.com
> >>
> >>
>
>
--
Kit Plummer
Nobody-in-Charge @ Black:Hole:Logic
http://www.blackholelogic.com
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Posted by David Jencks <da...@yahoo.com>.
On Aug 24, 2007, at 3:03 AM, Nodet Guillaume wrote:
> So if i understand you correctly, you are mostly concerned of
> enhancing
> the JMS flow in the following areas:
> * avoid ping/pong and lower bandwidth requirement
> (avoid sending the whole exchange and only send the actual data)
> * enhance security (authentication, encryption ?)
> * enhance the endoint registry wrt to services or instances going
> up and down
>
>
> Did I catch you correcty ?
>
> For the bandwidh requirement, I'm sure we can do that and
> reconstruct a fake
> exchange on the other side. We would loose informations wrt to the
> input message
> but I don't think this would be too much a problem. For the ping/
> pong stuff, I'm sure
> we can find a way to optimize it somehow. We may have troubles
> handling the
> InOptionalOut pattern though, as you don't really know if you will
> receive an Out
> message or nothing, but for the other simple patterns (InOnly and
> InOut) it should
> be quite easy to send back the exchange with a DONE status just
> after having send
> the jms message containing the In or Out.
>
> On the security subject, I know there is lots to do, but this is an
> area i'm not so familiar
> with. My biggest concern is that we security can be applied at the
> connection level
> or at the message level. NMR-NMR security for the JMS flow could
> be delegated
> to ActiveMQ i guess (using AMQ security features).
You may want to look into the CORBA csiv2 framework for some ideas on
how to simultaneously deal with authentication of both the client/
server and user. I'm not suggesting that you use CORBA as a
transport but the concepts might be useful.
thanks
david jencks
>
> On the registry side, I think one of the main problem is that there
> is no way to tell the
> difference between an endpoint that goes down because the server is
> no more
> accessibe (it will be up again at a later time) or because the
> endpoint has been
> undeployed. Imho, this is a key requirement to be able to make
> routing decisions.
> I don't know yet how to handle this problem: if a server has been
> shutdown, it may
> never go up again... So i'm still not sure how to handle the
> problem :-(
>
> Cheers,
> Guillaume Nodet
>
> On Aug 23, 2007, at 3:35 PM, Kit Plummer wrote:
>
>> Sure Guillaume.
>>
>> Maybe the best thing to do is explain the concept...and what we've
>> done to
>> meet our requirements.
>>
>> It is actually quite simple. We needed to be able to connect two
>> computers
>> together via TCP/IP, and have a publisher on one system, the
>> consumer on the
>> other. Granted we've got lot's of both on each - but, the premise
>> is that
>> link between is transparent.
>>
>> Currently, we are using a feature of ActiveMQ called "Network of
>> Brokers"
>> (NoB) to create a mapping of destinations/endpoints.
>>
>> Where it gets really complicated is when we only want to allow a
>> specific
>> MEPs to cross the NoB connection. In this example, bandwidth is
>> not a
>> commodity and must be tightly constrained. We were tolerant of
>> all the SEDA
>> flow handshaking, but I believe it would be nice if InOnly MEPS
>> really were
>> just a single transmission (turning off levels of reliability/
>> durability).
>> Also, in our environment multicast isn't possible, and the
>> networks are
>> fairly ad-hoc...meaning not stable. Plus, we need to know about
>> the state
>> of the link.
>>
>> Service registration happens also in different configurations.
>> For example,
>> one topology we support is a hierarchical flow (master-slaves).
>> Imagine a
>> simple sensor net. There would be a single point at the top,
>> where are data
>> were to be aggregated. So, in this example the NoBs need to support
>> "followers" only communicating with their "leader"...and the
>> "leader" only
>> communicating with its "leader". But, there might also be a need
>> to have
>> "shared" data that is available on all platforms in network
>> (health, state,
>> etc.). Ding lifecycle.
>>
>> I could keep going...but, am curious if anyone else looks at it
>> this way.
>> Obviously, the notion of simple performance scalability is one way
>> to look
>> at. There is a lot of capability in the NoB, but I think it falls
>> a bit
>> short. There are a few features that we'd like to see, that would
>> help us
>> federate better. BC/SE/SA-level authentication to the bus, as
>> well as
>> platform-to-platform, or NMR-to-NMR authentication would be very
>> helpful.
>> We've been looking at grid/cluster-like capabilities too - for
>> example, if
>> one platform is maxed out from a processing perspective, sending
>> the SA and
>> the message/task to another platform in network automatically.
>>
>> Thanks for taking the time to do this.
>>
>> On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>>
>>> Hi Kit,
>>>
>>> I'm quite sure you would have a very valuable input there, given
>>> your
>>> experience
>>> on ServiceMix. So I'm starting this new thread. Would you mind
>>> throwing a few
>>> ideas there ?
>>>
>>> Cheers,
>>> Guillaume Nodet
>>>
>>>
>>> On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote:
>>>
>>>> On 8/22/07, Terry Cox <te...@meta-concepts.com> wrote:
>>>>>
>>>>> Interesting.
>>>>>
>>>>> We need to have a very serious chat about application
>>>>> lifecycles and
>>>>> governance...
>>>>>
>>>>> Terry
>>>>>
>>>>
>>>>
>>>> And Federating...distribution of the NMR across n-platforms!
>>>>
>>>> --
>>>> Kit Plummer
>>>> Nobody-in-Charge @ Black:Hole:Logic
>>>> http://www.blackholelogic.com
>>>
>>>
>
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
So if i understand you correctly, you are mostly concerned of enhancing
the JMS flow in the following areas:
* avoid ping/pong and lower bandwidth requirement
(avoid sending the whole exchange and only send the actual data)
* enhance security (authentication, encryption ?)
* enhance the endoint registry wrt to services or instances going
up and down
Did I catch you correcty ?
For the bandwidh requirement, I'm sure we can do that and reconstruct
a fake
exchange on the other side. We would loose informations wrt to the
input message
but I don't think this would be too much a problem. For the ping/
pong stuff, I'm sure
we can find a way to optimize it somehow. We may have troubles
handling the
InOptionalOut pattern though, as you don't really know if you will
receive an Out
message or nothing, but for the other simple patterns (InOnly and
InOut) it should
be quite easy to send back the exchange with a DONE status just after
having send
the jms message containing the In or Out.
On the security subject, I know there is lots to do, but this is an
area i'm not so familiar
with. My biggest concern is that we security can be applied at the
connection level
or at the message level. NMR-NMR security for the JMS flow could be
delegated
to ActiveMQ i guess (using AMQ security features).
On the registry side, I think one of the main problem is that there
is no way to tell the
difference between an endpoint that goes down because the server is
no more
accessibe (it will be up again at a later time) or because the
endpoint has been
undeployed. Imho, this is a key requirement to be able to make
routing decisions.
I don't know yet how to handle this problem: if a server has been
shutdown, it may
never go up again... So i'm still not sure how to handle the problem :-(
Cheers,
Guillaume Nodet
On Aug 23, 2007, at 3:35 PM, Kit Plummer wrote:
> Sure Guillaume.
>
> Maybe the best thing to do is explain the concept...and what we've
> done to
> meet our requirements.
>
> It is actually quite simple. We needed to be able to connect two
> computers
> together via TCP/IP, and have a publisher on one system, the
> consumer on the
> other. Granted we've got lot's of both on each - but, the premise
> is that
> link between is transparent.
>
> Currently, we are using a feature of ActiveMQ called "Network of
> Brokers"
> (NoB) to create a mapping of destinations/endpoints.
>
> Where it gets really complicated is when we only want to allow a
> specific
> MEPs to cross the NoB connection. In this example, bandwidth is not a
> commodity and must be tightly constrained. We were tolerant of all
> the SEDA
> flow handshaking, but I believe it would be nice if InOnly MEPS
> really were
> just a single transmission (turning off levels of reliability/
> durability).
> Also, in our environment multicast isn't possible, and the networks
> are
> fairly ad-hoc...meaning not stable. Plus, we need to know about
> the state
> of the link.
>
> Service registration happens also in different configurations. For
> example,
> one topology we support is a hierarchical flow (master-slaves).
> Imagine a
> simple sensor net. There would be a single point at the top, where
> are data
> were to be aggregated. So, in this example the NoBs need to support
> "followers" only communicating with their "leader"...and the
> "leader" only
> communicating with its "leader". But, there might also be a need
> to have
> "shared" data that is available on all platforms in network
> (health, state,
> etc.). Ding lifecycle.
>
> I could keep going...but, am curious if anyone else looks at it
> this way.
> Obviously, the notion of simple performance scalability is one way
> to look
> at. There is a lot of capability in the NoB, but I think it falls
> a bit
> short. There are a few features that we'd like to see, that would
> help us
> federate better. BC/SE/SA-level authentication to the bus, as well as
> platform-to-platform, or NMR-to-NMR authentication would be very
> helpful.
> We've been looking at grid/cluster-like capabilities too - for
> example, if
> one platform is maxed out from a processing perspective, sending
> the SA and
> the message/task to another platform in network automatically.
>
> Thanks for taking the time to do this.
>
> On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
>>
>> Hi Kit,
>>
>> I'm quite sure you would have a very valuable input there, given your
>> experience
>> on ServiceMix. So I'm starting this new thread. Would you mind
>> throwing a few
>> ideas there ?
>>
>> Cheers,
>> Guillaume Nodet
>>
>>
>> On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote:
>>
>>> On 8/22/07, Terry Cox <te...@meta-concepts.com> wrote:
>>>>
>>>> Interesting.
>>>>
>>>> We need to have a very serious chat about application lifecycles
>>>> and
>>>> governance...
>>>>
>>>> Terry
>>>>
>>>
>>>
>>> And Federating...distribution of the NMR across n-platforms!
>>>
>>> --
>>> Kit Plummer
>>> Nobody-in-Charge @ Black:Hole:Logic
>>> http://www.blackholelogic.com
>>
>>
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Posted by Kit Plummer <ki...@gmail.com>.
Sure Guillaume.
Maybe the best thing to do is explain the concept...and what we've done to
meet our requirements.
It is actually quite simple. We needed to be able to connect two computers
together via TCP/IP, and have a publisher on one system, the consumer on the
other. Granted we've got lot's of both on each - but, the premise is that
link between is transparent.
Currently, we are using a feature of ActiveMQ called "Network of Brokers"
(NoB) to create a mapping of destinations/endpoints.
Where it gets really complicated is when we only want to allow a specific
MEPs to cross the NoB connection. In this example, bandwidth is not a
commodity and must be tightly constrained. We were tolerant of all the SEDA
flow handshaking, but I believe it would be nice if InOnly MEPS really were
just a single transmission (turning off levels of reliability/durability).
Also, in our environment multicast isn't possible, and the networks are
fairly ad-hoc...meaning not stable. Plus, we need to know about the state
of the link.
Service registration happens also in different configurations. For example,
one topology we support is a hierarchical flow (master-slaves). Imagine a
simple sensor net. There would be a single point at the top, where are data
were to be aggregated. So, in this example the NoBs need to support
"followers" only communicating with their "leader"...and the "leader" only
communicating with its "leader". But, there might also be a need to have
"shared" data that is available on all platforms in network (health, state,
etc.). Ding lifecycle.
I could keep going...but, am curious if anyone else looks at it this way.
Obviously, the notion of simple performance scalability is one way to look
at. There is a lot of capability in the NoB, but I think it falls a bit
short. There are a few features that we'd like to see, that would help us
federate better. BC/SE/SA-level authentication to the bus, as well as
platform-to-platform, or NMR-to-NMR authentication would be very helpful.
We've been looking at grid/cluster-like capabilities too - for example, if
one platform is maxed out from a processing perspective, sending the SA and
the message/task to another platform in network automatically.
Thanks for taking the time to do this.
On 8/23/07, Nodet Guillaume <gn...@gmail.com> wrote:
>
> Hi Kit,
>
> I'm quite sure you would have a very valuable input there, given your
> experience
> on ServiceMix. So I'm starting this new thread. Would you mind
> throwing a few
> ideas there ?
>
> Cheers,
> Guillaume Nodet
>
>
> On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote:
>
> > On 8/22/07, Terry Cox <te...@meta-concepts.com> wrote:
> >>
> >> Interesting.
> >>
> >> We need to have a very serious chat about application lifecycles and
> >> governance...
> >>
> >> Terry
> >>
> >
> >
> > And Federating...distribution of the NMR across n-platforms!
> >
> > --
> > Kit Plummer
> > Nobody-in-Charge @ Black:Hole:Logic
> > http://www.blackholelogic.com
>
>
ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
Hi Kit,
I'm quite sure you would have a very valuable input there, given your
experience
on ServiceMix. So I'm starting this new thread. Would you mind
throwing a few
ideas there ?
Cheers,
Guillaume Nodet
On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote:
> On 8/22/07, Terry Cox <te...@meta-concepts.com> wrote:
>>
>> Interesting.
>>
>> We need to have a very serious chat about application lifecycles and
>> governance...
>>
>> Terry
>>
>
>
> And Federating...distribution of the NMR across n-platforms!
>
> --
> Kit Plummer
> Nobody-in-Charge @ Black:Hole:Logic
> http://www.blackholelogic.com
Re: ServiceMix 4.0
Posted by Kit Plummer <ki...@gmail.com>.
On 8/22/07, Terry Cox <te...@meta-concepts.com> wrote:
>
> Interesting.
>
> We need to have a very serious chat about application lifecycles and
> governance...
>
> Terry
>
And Federating...distribution of the NMR across n-platforms!
--
Kit Plummer
Nobody-in-Charge @ Black:Hole:Logic
http://www.blackholelogic.com
Lifecycle and governance (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
Terry,
I'm just starting a new thread here so that it will be easier to
follow the discussions.
Any ideas are welcome...
Cheers,
Guillaume Nodet
On Aug 23, 2007, at 1:00 AM, Terry Cox wrote:
> Interesting.
>
> We need to have a very serious chat about application lifecycles
> and governance...
>
> Terry
Re: ServiceMix 4.0
Posted by Bruce Snyder <br...@gmail.com>.
On 8/22/07, Terry Cox <te...@meta-concepts.com> wrote:
> Interesting.
>
> We need to have a very serious chat about application lifecycles and
> governance...
Now is the time.
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: ServiceMix 4.0
Posted by Terry Cox <te...@meta-concepts.com>.
Interesting.
We need to have a very serious chat about application lifecycles and
governance...
Terry