[Heads up] ServiceMix 4.0 branch
I've made some changes this week on the 4.0 branch. The distribution is not complete yet, but the linux binary distro is usable. It starts ServiceMix with all the services so far (NMR, shell, tx manager, jmx server, jbi). It's far from being finished, but this is a good start. I will try to document things on the wiki so that we can continue the work. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0 documentation
I have create a confluence space for ServiceMix 4.0. http://cwiki.apache.org/confluence/display/SMX4/Home It is not auto-exported yet and not linked with the main site yet. As trevor said, I think it may be a good idea to create another space for ServiceMix 3.x (by copying the current one) and use the current one as the main site with a tab browsing or something like that... On 10/5/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I was wondering if we should create a separate wiki space for ServiceMix 4.0 documentation. Also I need to take a look at how the camel book works: it generates a pdf from the wiki, so maybe we could do the same... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
ServiceMix 4.0 documentation
I was wondering if we should create a separate wiki space for ServiceMix 4.0 documentation. Also I need to take a look at how the camel book works: it generates a pdf from the wiki, so maybe we could do the same... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0 modularity
On 10/4/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I'd like to make ServiceMix 4.0 as modular as possible. This would mean that ServiceMix 4.0 main distribution would come with the minimal set, while additional features could be provisioned and configured using OBR, the Deployment Admin or our provisioning system. Such features could include: * an activemq broker * an apache ds server * jbi 1.0 compatibility layer * jaxws support * ... Although from a project perspective, if we could split these features in different projects, that would make things easier to release: i.e. release a single feature at a time, rather than releasing everything each time. Kinda like maven does with its plugins. I've always thought the idea of separate release cycles for different components/features was a good one. This allows for individual components to be released as they're ready. However, I've begun to reconsider this recently. Independent component releases seem like a good idea until the developer has trouble and then begins to upgrade components independently resulting in a mish-mash of versions which can cause a laundry list of other problems. It seems to me that we should not push this responsibility onto the developer because it causes them more trouble than its worth. Not unlike recent Eclipse releases, ServiceMix is a container with many modules and I think *we* should bear the burden of making each module work together to provide an overall ServiceMix release. An alternative approach would be to mix independent component releases with overall ServiceMix releases. This would give us the ability to release components independently while still providing a major release of all components packaged together as ServiceMix, say, four times a year. Am I crazy? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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 modularity
Yes you are crazy. I have to agree - dependency hell is not something I'd like to have to overcome. Eclipse's deal is a nice example. Kit Sent from my iPhone On Oct 4, 2007, at 4:31 PM, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/4/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I'd like to make ServiceMix 4.0 as modular as possible. This would mean that ServiceMix 4.0 main distribution would come with the minimal set, while additional features could be provisioned and configured using OBR, the Deployment Admin or our provisioning system. Such features could include: * an activemq broker * an apache ds server * jbi 1.0 compatibility layer * jaxws support * ... Although from a project perspective, if we could split these features in different projects, that would make things easier to release: i.e. release a single feature at a time, rather than releasing everything each time. Kinda like maven does with its plugins. I've always thought the idea of separate release cycles for different components/features was a good one. This allows for individual components to be released as they're ready. However, I've begun to reconsider this recently. Independent component releases seem like a good idea until the developer has trouble and then begins to upgrade components independently resulting in a mish-mash of versions which can cause a laundry list of other problems. It seems to me that we should not push this responsibility onto the developer because it causes them more trouble than its worth. Not unlike recent Eclipse releases, ServiceMix is a container with many modules and I think *we* should bear the burden of making each module work together to provide an overall ServiceMix release. An alternative approach would be to mix independent component releases with overall ServiceMix releases. This would give us the ability to release components independently while still providing a major release of all components packaged together as ServiceMix, say, four times a year. Am I crazy? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! 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 modularity
On 10/4/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/4/07, Chris Custine [EMAIL PROTECTED] wrote: I agree that eventually you will have certain components that have their own release cycles seperate from the core components. I think it will take several releases of all components as an entire system before you will be comfortable splitting things into seperate sub-projects, but as the core components mature and stabilize I think it will be a natural desire to have more frequent releases of the optional components. Agreed. The dependency management issues mentioned by Bruce and Kit are valid, but don't forget that the bundles are able to specify required version information for their own dependencies. So the dependency management issue is more about shipping a properly working default configuration with the main ServiceMix distribution than about the seperate releases of components. That's a good point and something I forgot about. I guess we'll need to relax any static version requirements once the core stablizes so that we can allow a wider range of acceptable versions of various components. I like Guillaume's idea of offering a basic image that is capable of provisioning itself from a managed OBR repository. This could also allow a user to configure their own customized provisioning configuration similar to kickstart files for Linux distributions. I think you will also want to offer a fully loaded and self contained image that already has all of the components available, but the auto-provisioned basic image will be very useful for a lot of users I would think. I think this is a good paradigm as well. However, a question arose today about continuing to allow ServiceMix to be embedded in any old Java app. Some folks may want an OSGi container to be started when embedding ServiceMix, and some may not. All I'm saying is that we need to keep this in mind as a requirement because there are a fair amount of users who are embedding ServiceMix today. I have had to think about this same issue with Apache Directory Server. ApacheDS has many users that embed as well as many users of the standalone server and this will be an issue for us as we move the server to an OSGi container as well. It may be different for ServiceMix, but for ApacheDS I want to be able to offer the ability to embed without using OSGi or Spring at all. I haven't worked out all the details yet, but I am thinking about a component that contains all of the OSGi specific code and manages the server components which are just library bundles with OSGi Manifest headers so that they can also be used as simple jar files outside of OSGi. If you wanted to embed, then the OSGi component is not used, and instead you could have a facade that basically does what the standalone server does today (use Spring to load app context and wire components), or just wire the components up directly in the user's own code (ADS has people doing this as well). So this basically exposes 3 distinct use cases with progressively lower levels of integration. Now the trick is to accomplish this without introducing a maintenance nightmare. :-) Thanks, Chris
Fwd: ServiceMix 4.0 dev plan
Forwarding to the dev list ... On 9/21/07, d. santosh [EMAIL PROTECTED] wrote: Thank you, I can't assign it to myself. user id : d.santosh email id: [EMAIL PROTECTED] You should now have karma to assign issues to yourself. can you let me know the issue details which could help me in lining my investigation work , and define milestones accordingly. few points mentioned below - content of the docbook ( standard template if any to be followed) I has not been started yet. I need to have a look at the camel manual and see how it looks - topics of discussion that can be kicked off. Whatever you want. Feel free to discuss / ask anything on the dev list - prioritize the task. There's no deadline right now. - highlight or fix some early known issues. About Ode integration ? The current JBI implementation has several limitations that may be worked around using the next Ode version (mainly around transactions so that Ode would reuse a transaction started by the bus), but this is not really top priority. please suggest if you have any specific procedure that needs to be followed. Use the mailing list as your primary dev tool :-) That way, everyone can participate and help... take care Santosh R. Dubey On 9/21/07, Guillaume Nodet [EMAIL PROTECTED] wrote: Just assigned it to yourself. If you can't, give me your account and i will grant you karma. On 9/21/07, d. santosh [EMAIL PROTECTED] wrote: Hi Guillaume, I can have a look at integrating Apache ODE. (i.e. SM-1070 ODE Integration) take care Santosh R Dubey On 9/20/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I've create a few JIRAs for ServiceMix 4.0. See https://issues.apache.org/activemq/browse/SM/fixforversion/11845 If anyone wants to work on something, please assign one to yourself. I haven't put any more precise version / milestone fix yet... Feel free to comment and start discussion around each of these topics. Also, this does not include any documentation / examples etc which need to be done too. I'm thinking a docbook based users guide might be a good idea. Also, I think we should releasing milestone as soon as possible and have small release cycles -- quite the contrary we did on smx 3.x ;-) So maybe a first one in october after releasing 3.1.2 and 3.2 asap. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
ServiceMix 4.0 dev plan
I've create a few JIRAs for ServiceMix 4.0. See https://issues.apache.org/activemq/browse/SM/fixforversion/11845 If anyone wants to work on something, please assign one to yourself. I haven't put any more precise version / milestone fix yet... Feel free to comment and start discussion around each of these topics. Also, this does not include any documentation / examples etc which need to be done too. I'm thinking a docbook based users guide might be a good idea. Also, I think we should releasing milestone as soon as possible and have small release cycles -- quite the contrary we did on smx 3.x ;-) So maybe a first one in october after releasing 3.1.2 and 3.2 asap. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Do you know the probable Release Date ServiceMix 4.0?
Well, not yet as it's still a bit fuzzy... In 2008 for sure... Do you want to help on that ? On Sep 7, 2007, at 3:52 PM, Simon Sekat wrote: We are counting on using it because it supports OSGI deployment model. Thank you, -- Simon S. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0 api
Btw, I have uploaded the site for the whole project which is easier to manage. http://people.apache.org/~gnodet/servicemix-4.0-SNAPSHOT/ Cheers, Guillaume Nodet On Aug 28, 2007, at 12:11 AM, Nodet Guillaume wrote: I've refactored a few things in the api and introduced back the listeners and flows. For those who prefer to read javadoc, take a look at: http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/ The javadoc is quite low on comments right now, so if any area appears to be unclear, ask for comments and I will improve the doc asap. Although any ideas, feedback, patches are always welcome. To test the API, I have started a really dumb implementation of it in the branch, but don't expect much at this point ;-) http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/ Cheers, Guillaume Nodet
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: ServiceMix 4.0 api
I have committed a simple test showing how to expose an endpoint and how to communicate with it. See http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/core/src/test/java/org/apache/servicemix/core/ IntegrationTest.java How does it sounds ? Cheers, Guillaume Nodet On Aug 28, 2007, at 12:11 AM, Nodet Guillaume wrote: I've refactored a few things in the api and introduced back the listeners and flows. For those who prefer to read javadoc, take a look at: http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/ The javadoc is quite low on comments right now, so if any area appears to be unclear, ask for comments and I will improve the doc asap. Although any ideas, feedback, patches are always welcome. To test the API, I have started a really dumb implementation of it in the branch, but don't expect much at this point ;-) http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/ Cheers, Guillaume Nodet
Re: ServiceMix 4.0
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
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=12323536framed=yskin=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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: ServiceMix 4.0 api
Hello Guillaume, I am getting a page not found with the javadoc site. Regards, Gordon Nodet Guillaume wrote: I've refactored a few things in the api and introduced back the listeners and flows. For those who prefer to read javadoc, take a look at: http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/ The javadoc is quite low on comments right now, so if any area appears to be unclear, ask for comments and I will improve the doc asap. Although any ideas, feedback, patches are always welcome. To test the API, I have started a really dumb implementation of it in the branch, but don't expect much at this point ;-) http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/ Cheers, Guillaume Nodet .
Re: ServiceMix 4.0 api
Yeah, i moved it. Try http://people.apache.org/~gnodet/servicemix-4.0-SNAPSHOT/ The direct link to the api is: http://people.apache.org/~gnodet/servicemix-4.0-SNAPSHOT/ org.apache.servicemix.api/apidocs/index.html Cheers, Guillaume Nodet On Aug 28, 2007, at 3:02 PM, Gordon Dickens wrote: Hello Guillaume, I am getting a page not found with the javadoc site. Regards, Gordon Nodet Guillaume wrote: I've refactored a few things in the api and introduced back the listeners and flows. For those who prefer to read javadoc, take a look at: http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/ The javadoc is quite low on comments right now, so if any area appears to be unclear, ask for comments and I will improve the doc asap. Although any ideas, feedback, patches are always welcome. To test the API, I have started a really dumb implementation of it in the branch, but don't expect much at this point ;-) http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/ Cheers, Guillaume Nodet .
Re: ServiceMix 4.0
On 8/24/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/24/07, Adrian Co [EMAIL PROTECTED] 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: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
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: ServiceMix 4.0
On 8/27/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/27/07, James Strachan [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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
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 [EMAIL PROTECTED] 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: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
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 [EMAIL PROTECTED] 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
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
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 [EMAIL PROTECTED] 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
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
works for me. -brian On 8/25/07, Nodet Guillaume [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Me too. I think. -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
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 [EMAIL PROTECTED] 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
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
On Aug 23, 2007, at 11:58 AM, James Strachan wrote: On 8/22/07, Nodet Guillaume [EMAIL PROTECTED] 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
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
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)
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: ServiceMix 4.0
On Aug 23, 2007, at 4:21 PM, Bruce Snyder wrote: On 8/23/07, Kit Plummer [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! 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
Spring extensions to OSGi (was Re: ServiceMix 4.0)
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. I've been thinking about that a bit more. It seems to me that using a kind of PropertyPlaceHolder (i.e. a BeanFactoryPostProcessor) sounds like a good idea. It could check all properties and perform replacement of an url like: bundle-ext://org/test/dummy.wsdl to bundle://7.0/org/test/dummy.wsdl where 7.0 is the bundle id. Another extension could be a spring bean factory that expose a blob of xml to an url for other bundles to consume. Inside your spring definition file, one would have: smx-osgi:export-xml url=org/test/dummy.wsdl wsdl:description ... ... /wsdl:description /smx:osgi Thus a single configuration file (the spring one) could contain blob of xml (well, not only xml i guess) that could be exposed as an url. I think the first idea will prove really useful to expose a WSDL to other bundles. I'm not so sure about the second one... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Any other people interested ? +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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
On 8/24/07, Adrian Co [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: Interesting. We need to have a very serious chat
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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)
On Aug 24, 2007, at 6:44 PM, Bruce Snyder wrote: On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] 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)
On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] wrote: On Aug 24, 2007, at 6:44 PM, Bruce Snyder wrote: On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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: Spring extensions to OSGi (was Re: ServiceMix 4.0)
Guillaume, Just getting grounded... Would SM 4.0 leverage Felix to get OSGi capabilities? I took a grep through the code, it doesn't look like it uses it at all right now: [EMAIL PROTECTED]:~/dev/apache.org/servicemix- grep -r elix * and osgi appears only in the eclipse plugins. Just verifying, OSGi is a brand new dependency for SM, right? Which leads me to my second question, do you think the dependency would be a hard dependency (on the actual felix impl), or would it be implementation agnostic? (e.g. able to run on Equinox as well) I am going to pull felix now and start playing around with it. -brian On 8/24/07, Guillaume Nodet [EMAIL PROTECTED] wrote: 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. I've been thinking about that a bit more. It seems to me that using a kind of PropertyPlaceHolder (i.e. a BeanFactoryPostProcessor) sounds like a good idea. It could check all properties and perform replacement of an url like: bundle-ext://org/test/dummy.wsdl to bundle://7.0/org/test/dummy.wsdl where 7.0 is the bundle id. Another extension could be a spring bean factory that expose a blob of xml to an url for other bundles to consume. Inside your spring definition file, one would have: smx-osgi:export-xml url=org/test/dummy.wsdl wsdl:description ... ... /wsdl:description /smx:osgi Thus a single configuration file (the spring one) could contain blob of xml (well, not only xml i guess) that could be exposed as an url. I think the first idea will prove really useful to expose a WSDL to other bundles. I'm not so sure about the second one... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- 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: Spring extensions to OSGi (was Re: ServiceMix 4.0)
On 8/24/07, Brian O'Neill [EMAIL PROTECTED] wrote: Guillaume, Just getting grounded... Would SM 4.0 leverage Felix to get OSGi capabilities? I took a grep through the code, it doesn't look like it uses it at all right now: [EMAIL PROTECTED]:~/dev/apache.org/servicemix- grep -r elix * and osgi appears only in the eclipse plugins. Just verifying, OSGi is a brand new dependency for SM, right? Which leads me to my second question, do you think the dependency would be a hard dependency (on the actual felix impl), or would it be implementation agnostic? (e.g. able to run on Equinox as well) I am going to pull felix now and start playing around with it. The idea is to leverage the OSGi spec so that SMX can run on any OSGi compliant container. The first stab Guillaume and I took at experimenting with OSGi back in May was using Felix and we'd probably use Felix by default. But the idea is not to depend directly on the Felix implementation. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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: Spring extensions to OSGi (was Re: ServiceMix 4.0)
In my mind, ServiceMix will be agnostic wrt to the OSGi implementation used. At the same time, I'm thinking about creating a distribution for ServiceMix that would include Felix runtime... And yeah, OSGi has never been a dependency so far. I suggest to take a look at spring-osgi too. See http://www.springframework.org/osgi I really think we should use it. Cheers, Guillaume Nodet On Aug 24, 2007, at 7:10 PM, Brian O'Neill wrote: Guillaume, Just getting grounded... Would SM 4.0 leverage Felix to get OSGi capabilities? I took a grep through the code, it doesn't look like it uses it at all right now: [EMAIL PROTECTED]:~/dev/apache.org/servicemix- grep -r elix * and osgi appears only in the eclipse plugins. Just verifying, OSGi is a brand new dependency for SM, right? Which leads me to my second question, do you think the dependency would be a hard dependency (on the actual felix impl), or would it be implementation agnostic? (e.g. able to run on Equinox as well) I am going to pull felix now and start playing around with it. -brian On 8/24/07, Guillaume Nodet [EMAIL PROTECTED] wrote: 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. I've been thinking about that a bit more. It seems to me that using a kind of PropertyPlaceHolder (i.e. a BeanFactoryPostProcessor) sounds like a good idea. It could check all properties and perform replacement of an url like: bundle-ext://org/test/dummy.wsdl to bundle://7.0/org/test/dummy.wsdl where 7.0 is the bundle id. Another extension could be a spring bean factory that expose a blob of xml to an url for other bundles to consume. Inside your spring definition file, one would have: smx-osgi:export-xml url=org/test/dummy.wsdl wsdl:description ... ... /wsdl:description /smx:osgi Thus a single configuration file (the spring one) could contain blob of xml (well, not only xml i guess) that could be exposed as an url. I think the first idea will prove really useful to expose a WSDL to other bundles. I'm not so sure about the second one... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- 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 and federation (was Re: ServiceMix 4.0)
On Aug 24, 2007, at 7:28 PM, Kit Plummer wrote: On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] 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
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
On 8/24/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Any other people interested ? +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: ServiceMix 4.0
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 [EMAIL PROTECTED] 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
Re: ServiceMix 4.0
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
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
ServiceMix 4.0 and type converters
I thought I'd spin up another thread on this... On 8/23/07, Brian O'Neill [EMAIL PROTECTED] wrote: On 8/22/07, Nodet Guillaume [EMAIL PROTECTED] 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. Incidentally thats come up recently in Camel too; the type converter stuff is so useful, folks wanna use it for many different things when the Java class/interface is not enough to specify a conversion. e.g. convert to Java Object using JAXB2 versus serialization versus SOAP encoding I guess this is no longer type conversion, but more content conversion - so maybe a separate API is required. But certainly folks wanna be able to do things like // specify the required Java type and content type InputStream in = message.getBody(InputStream.class, application/xml); But am wondering if for things like content type / content encoding stuff we need a separate kind of mechanism than the Java type conversion stuff; or if we could just extend the model to include content type as well? -- James --- http://macstrac.blogspot.com/
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
I'd be up for a few chat sessions! On 8/23/07, Nodet Guillaume [EMAIL PROTECTED] 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
Re: ServiceMix 4.0 and type converters
On 8/23/07, James Strachan [EMAIL PROTECTED] wrote: 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. Incidentally thats come up recently in Camel too; the type converter stuff is so useful, folks wanna use it for many different things when the Java class/interface is not enough to specify a conversion. e.g. convert to Java Object using JAXB2 versus serialization versus SOAP encoding I guess this is no longer type conversion, but more content conversion - so maybe a separate API is required. But certainly folks wanna be able to do things like // specify the required Java type and content type InputStream in = message.getBody(InputStream.class, application/xml); But am wondering if for things like content type / content encoding stuff we need a separate kind of mechanism than the Java type conversion stuff; or if we could just extend the model to include content type as well? I view type conversion (e.g., java.io.File to org.xml.sax.InputSource) as being very different than content conversion (e.g., EDI to SOAP). But I do see that sometimes there is some overlap between these two concepts. Is it a good idea to lump these two together in the same API when the business purpose is distinctly different? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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
On 8/23/07, Daryl Richter [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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
On 8/23/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/23/07, Daryl Richter [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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
On 8/23/07, Kit Plummer [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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
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 [EMAIL PROTECTED] 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
On 8/22/07, Nodet Guillaume [EMAIL PROTECTED] 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
Re: ServiceMix 4.0
On Aug 22, 2007, at 11:43 PM, Bruce Snyder wrote: On 8/22/07, Nodet Guillaume [EMAIL PROTECTED] 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
Re: ServiceMix 4.0
Interesting. We need to have a very serious chat about application lifecycles and governance... Terry
Re: ServiceMix 4.0
On 8/22/07, Terry Cox [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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
On 8/22/07, Terry Cox [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
