Re: GShell
Yeah agreed, I discovered this one too. I've played a bit with pax-runner too this week while integrating GShell. Anyway, from a gshell perspective, i have been able to have a local console running. However, it is quite heavy as you need to bring plexus, xstream, classworlds and gshell itself.I really like the fact that GShell has a nice ansi console, a nice command line management and remoting. However, I'll try to have it delegate to the felix shell instead as it is much more OSGi friendly (commands are registered in the osgi registry). On Oct 3, 2007, at 6:57 AM, Kit Plummer wrote: Im using the pax-logging stuff on a project. Very nice. Kit On Oct 2, 2007, at 5:28 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: Btw, the pax project has lots of interesting things. See http://wiki.ops4j.org/confluence/display/ops4j/Pax+RadMan and much more. On 10/3/07, Guillaume Nodet [EMAIL PROTECTED] wrote: Forwarding to the dev list... FYI, Gshell is a subproject of Geronimo providing an extensible console (local and remote), kinda like bash. -- Forwarded Message From: Guillaume Nodet [EMAIL PROTECTED] Date: Wed, 03 Oct 2007 02:11:44 +0200 To: Bruce Snyder [EMAIL PROTECTED] Conversation: On duplicating effort Subject: Re: On duplicating effort On 3/10/07 2:02, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/2/07 5:59 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: https://issues.apache.org/activemq/secure/IssueNavigator.jspa? reset=truemod e=hidesorter/order=DESCsorter/ field=priorityresolution=-1pid=10950fixfo r=11845 So are you using GShell for SM-1074? Not really. Imho, gshell is just an interface to access features provided by other mechanism. Lifecycle is really tied to OSGi lifecycle, but yeah, we need to create Gshell commands for OSGi related stuff (start / stop bundles, etc...), but we could also have a web console for that, or a JMX one... What I mean is that Gshell should remain a mean of accessing these features. We also need to add a JIRA issue for the 1.0 compatibility layer. Done, SM-1083. Btw, we should have this discussion on the dev list ;-) Guillaume -- End of Forwarded Message IONA Technologies SARL Identification: 415 295 930 R.C.S. Nanterre Siège: Immeuble Elysées La Défense, 7C place du Dôme, 92056 La Défense Cedex, France -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: question about servicemix 3.1.2 release
On Sep 12, 2007, at 8:46 AM, Freeman Fang wrote: Hi all, When are we going to release servicemix 3.1.2? As a new commiter in servicemix team, I'd like to know how is the release process looks like. If possible, shall I be release manager of this time? :-) Yeah of course you can :-) There are some instructions available at http://incubator.apache.org/ servicemix/release-guide.html but these are a bit outdated, so we'll have to update those (and maven can not really be used for creating the release)... Let me have a breakfast and write something more accurate... Any suggestion is appreciated. Best Regards Freeman -- 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: IRC session
It sounds like there is an agreement on the following hour: On Sep 3, 2007, at 10:10 AM, rs d wrote: 3 pm GMT, 11 am EST, 8 am PST -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
ServiceMix graduation postponed
Just FYI, ServiceMix graduation approval by the ASF board is postponed a bit. It has simply been forgotten during the last meeting. The next meeting should be on september the 19th... -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: daily snapshot cleanup
Maybe we should use 30 days instead of 7 in case something wrong happen. It may be safer... On Aug 29, 2007, at 9:35 AM, James Strachan wrote: I've added a crontab to clean up old snapshots from the m2 snapshot repo for ActiveMQ, Camel and ServiceMix. If anyone needs to tinker with the script its here... https://svn.apache.org/repos/asf/activemq/scripts/activemq- snapshots-clean.sh This should hopefully keep the disk usage of our snapshots down (as they were in the 22Gb range!) -- James --- http://macstrac.blogspot.com/ -- 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: 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: 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
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: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
I'm using Colloquy (http://colloquy.info/) Cheers, Guillaume Nodet On Aug 28, 2007, at 11:57 PM, Daryl Richter wrote: On Aug 28, 2007, at 8:53 AM, Nodet Guillaume wrote: On Aug 28, 2007, at 2:48 PM, Piotr Bzdyl wrote: Hi, I would also like to participate in this session. When are you going to send data about the location of the IRC session? See http://www.nabble.com/forum/ViewPost.jtp? post=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/ So, now that you are on mac, what do you use? ;) (Another IRC newbie) Cheers, Guillaume Nodet -- Daryl Email *my = [ daryl at: @eddl dot: @us ]; Weblog *blog = @”http://itsallsemantics.com”;
IRC session
Unfortunately I will be traveling until Friday evening. What about moving it to Monday instead at the same hour ? 3 pm GMT, 11 am EST, 8 am PST Sorry about that... Cheers, Guillaume Nodet
Re: ServiceMix 4.0
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
ServiceMix 4.0 api
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)
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
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: 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: 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 grid
Re: ServiceMix 4.0 and type converters
On Aug 23, 2007, at 1:48 PM, James Strachan wrote: 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? I agree. The type converter api is not necessarily the best suited for our needs here and may be more suited for converting properties rather than the body. There are lots of different things here. We need to be able to send xml documents, binary streams and POJOs: this would cover most of the needs I guess. Then, some content type may be able to be converted from one format to another: a jaxb2 pojo may be transformed to xml, a JSON stream may be converted to xml too using http://jettison.codehaus.org/), but I'm not sure how far we should go as there may be lots of different ways to convert data between different formats. Complex transformations may need to be more tightly controlled by using an endpoint. Cheers, Guillaume Nodet -- James --- http://macstrac.blogspot.com/
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 federation (was Re: ServiceMix 4.0)
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
Lifecycle and governance (was Re: ServiceMix 4.0)
Terry, I'm just starting a new thread here so that it will be easier to follow the discussions. Any ideas are welcome... Cheers, Guillaume Nodet On Aug 23, 2007, at 1:00 AM, Terry Cox wrote: Interesting. We need to have a very serious chat about application lifecycles and governance... Terry
Re: Servicemix ILog JRules
I have never used JRules, so I can't really help on this part. I guess you should try to understand how the drools component work (or try the hello world se tutorial). It should be a good basis for building a SE. Cheers, Guillaume Nodet On Aug 22, 2007, at 9:44 PM, Manjunath ShankaraReddy wrote: I am Using ILog Jrules( Rules Engine) and Servicemix ESB. I want to integrate ILOG JRules with servicemix. I am planning to create Component in Servicemix similar to Servicemix-Drools that can integrate with Jrules. Can anyone please suggest how to approach this problem?. Your help is appreciated.
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: svn commit: r566880 - /incubator/servicemix/trunk/samples/wsdl-first/wsdl-first-http-su/src/main/resources/xbean.xml
I think there is another problem here. The defaultMep should not be needed, as the BC should recognized which operation is targeted and should infer the mep automatically. If the attribute is needed, it means: 1) the request sent is not correct 2) the operation recognition mechanism is broken Cheers, Guillaume Nodet On Aug 17, 2007, at 12:57 AM, [EMAIL PROTECTED] wrote: Author: bsnyder Date: Thu Aug 16 15:57:24 2007 New Revision: 566880 URL: http://svn.apache.org/viewvc?view=revrev=566880 Log: SM-1033: WSDL-First example fails due to missing defaultMep attribute in wsdl-first-http-su's xbean.xml. Modified: incubator/servicemix/trunk/samples/wsdl-first/wsdl-first-http- su/src/main/resources/xbean.xml Modified: incubator/servicemix/trunk/samples/wsdl-first/wsdl-first- http-su/src/main/resources/xbean.xml URL: http://svn.apache.org/viewvc/incubator/servicemix/trunk/ samples/wsdl-first/wsdl-first-http-su/src/main/resources/xbean.xml? view=diffrev=566880r1=566879r2=566880 == --- incubator/servicemix/trunk/samples/wsdl-first/wsdl-first-http- su/src/main/resources/xbean.xml (original) +++ incubator/servicemix/trunk/samples/wsdl-first/wsdl-first-http- su/src/main/resources/xbean.xml Thu Aug 16 15:57:24 2007 @@ -25,6 +25,7 @@ targetService=person:PersonService role=consumer locationURI=http://0.0.0.0:8192/PersonService/; + defaultMep=http://www.w3.org/2004/08/wsdl/in-out; soap=true / /beans
Size of CXF based components
Freeman, I've just noticed that the size of the two CXF based components is very high. It seems there are lots of jars that are included but not really needed (xalan, xerces, wsdl4j, woodstox, etc...). Lots of these jars are already in ServiceMix container classpath or provided by servicemix-shared shared library. Could you take a look and try to reduce these size please? Cheers, Guillaume Nodet
