[jira] Commented: (SM-1088) CXFbc provider should provider a targetURI element
[ https://issues.apache.org/activemq/browse/SM-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40342 ] Freeman Fang commented on SM-1088: -- we provide locationURI as provider's attribute something like cxfbc:provider wsdl=/wsdl/calculator.wsdl locationURI=http://localhost:9001/providertest; endpoint=CalculatorPort service=calculator:CalculatorService interfaceName=calculator:CalculatorPortType CXFbc provider should provider a targetURI element -- Key: SM-1088 URL: https://issues.apache.org/activemq/browse/SM-1088 Project: ServiceMix Issue Type: Improvement Components: servicemix-cxf-bc Affects Versions: 3.2 Environment: Windows XP, Servicemix 3.2 Reporter: Ryan Moquin Assignee: Freeman Fang Priority: Minor Fix For: 3.2 Even though I didn't get the cxfbc provider to work, I did notice in the XSD there doesn't appear to be an option to specify a target URI, wsdl, or useJBIWrapper. I mentioned this in the bug report to create an example, but I figured I'd open a separate issue for clarity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-1088) CXFbc provider should provider a targetURI element
[ https://issues.apache.org/activemq/browse/SM-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved SM-1088. -- Resolution: Fixed Fix Version/s: 3.2 CXFbc provider should provider a targetURI element -- Key: SM-1088 URL: https://issues.apache.org/activemq/browse/SM-1088 Project: ServiceMix Issue Type: Improvement Components: servicemix-cxf-bc Affects Versions: 3.2 Environment: Windows XP, Servicemix 3.2 Reporter: Ryan Moquin Assignee: Freeman Fang Priority: Minor Fix For: 3.2 Even though I didn't get the cxfbc provider to work, I did notice in the XSD there doesn't appear to be an option to specify a target URI, wsdl, or useJBIWrapper. I mentioned this in the bug report to create an example, but I figured I'd open a separate issue for clarity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
October board report
The report has to be submitted asap. I've written it at http://cwiki.apache.org/confluence/display/SM/2007-10-17. Please review and add anything missing asap. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4 as a distributed OSGi spring container....
On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: Bringing this thread to dev list On 10/11/07, James Strachan [EMAIL PROTECTED] wrote: We need to find a way to discover other ServiceMix instances (through ActiveMQ ? any other idea ?) Am pondering if we should have a simple POJO based discovery/heartbeat mechanism thats transport agnostic so we could use multicast, jmdns, ActiveMQ, HTTP etc. Was pondering about making something really simple in Camel/SMX4 and we take it from there etc. e.g. for a heartbeat we really just wanna do a timed send of a status message to some endpoint. This could be JMS or a POST to some URI (or even an AtomPub entry we POST). Then the server side of this thing, keeps a RAM cache of all these things and times the entires out after a while so they disappear. (Doesn't need any persistence or replication really; as if the server side fails, another one can start somewhere and after a few heartbeats its back in sync again). Then the server side - lets call it a registry (but a simple registry); can just expose these heartbeats as data in different queries. So folks can query using some mechanism for nodes of a certain type or whatnot. Let's rephrase to check there is no misunderstanding. The purpose here is to have a discovery mechanism which is somewhat independant of the protocol. So there is one server and multiple clients, each client sending its own information to the server that keeps track of them. This implies, that either * there is a single point of failure for the master which is statically configured * the client elect a master amongst themselves Yeah. I guess the two common approaches would be; * use a web server as the server via a URL (which you can have some kinda DNS/IP load balancer to deal with the master failing - though we really don't want to load balance across the master and slaves; all traffic should go to the master server at all times). On failover from master to slave it would just look like all the services died and came back again shortly afterwards. * use a JMS topic - so the 'server' is in RAM in each client (e.g. a List of the non-expired heartbeat POJOs) The latter is probably much easier to do; the former has the benefit of being able to be RESTful and so work across languages and corporate boundaries etc You could always add a RESTful facade ontop of the latter too - which would support load balancing and failover :) Once the master / registry has been identified, the client send heatbeats to it and can query it for services. I'm not sure if a push or pull model is better here: having the master send new information to the clients, or have the clients polling for new informations or simply looking up the service on demand. Yeah. I can see both being useful in different circumstances The problem with the pull approach is that we won't be able to expose remote services in the OSGi registry without hacking the registry itself. For this particular use case, it would be better to be notified of new services (or subscribing somehow) so that a client can register a new remote service in the OSGi registry, which would be available through a proxy. Yeah This heartbeat/discovery thing is pretty generic stuff really; it'd be nice if the message/data could be anything at all then we can reuse the same thing in many circumstances. e.g. we could use this to discover AMQ brokers; or CXF services of a kind of WSDL or SMX instances or OSGi containers or whatnot. +1 The blob of data that is heartbeated; and what kinds of queries on the data we need to make is kinda speciifc to different problems. e.g. in AMQ we mostly just need to get the URL to connect to the broker. We may want to include some kinda network-hop type info so we try to connect to the nearest node or something - but generally a URL is enough in AMQ-land for discovery. For SMX containers, we might as well just expose the URL to talk to it. For distributed OSGi stuff we might wanna use more complex data for the heartbeat data; so folks could search (rather like the NMR does) by service QName, interface name, endpoint name or whatever. From a low level I was wondering about a Camel factory bean in spring camel:heartbeat bean=someBeanRef property=myStatusEventObject millis=2000 uri=http://someServer.com/cheese/ This would call someBeanRef.getMyStatusEventObject() every 2 seconds and send the POJO to the endpoint URI. We could maybe wrap up this using some route? e.g. if the bean endpoint allowed for polling we could maybe do from(bean:someBeanRef?method=getMyStatusEventObjectperiod=2000).to(http://someServer.com/cheese;) though maybe a factory bean (XML element) is a bit easier - it does have better smart completion at least :) I like the idea of using camel to configure the discovery mechanism. This would be very flexible.
Re: ServiceMix 4 as a distributed OSGi spring container....
Interesting discussion :) On 11/10/2007, James Strachan [EMAIL PROTECTED] wrote: On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: Bringing this thread to dev list On 10/11/07, James Strachan [EMAIL PROTECTED] wrote: We need to find a way to discover other ServiceMix instances (through ActiveMQ ? any other idea ?) [big snip] From a low level I was wondering about a Camel factory bean in spring camel:heartbeat bean=someBeanRef property=myStatusEventObject millis=2000 uri=http://someServer.com/cheese/ This would call someBeanRef.getMyStatusEventObject() every 2 seconds and send the POJO to the endpoint URI. We could maybe wrap up this using some route? e.g. if the bean endpoint allowed for polling we could maybe do from(bean:someBeanRef?method=getMyStatusEventObjectperiod=2000).to(http://someServer.com/cheese;) though maybe a factory bean (XML element) is a bit easier - it does have better smart completion at least :) I like the idea of using camel to configure the discovery mechanism. This would be very flexible. Yeah; am thinking we could do content based routing or message translator stuff to format the POJO of the heartbeat data into different formats, sending it to different locations etc As an experiment in implementing a POJO based heartbeat mechanism thats protocol and data format independent (and can support the easy integration of EIP) I thought I'd try write a little test case in Camel. It turned out to be surprisingly easy :) from(bean:myService?methodName=status).to(mock:result); where the status() method is invoked periodically on the myService bean and then sent to the registry endpoint (a mock in this case as its a test case, but this could be activemq:topic:foo.bar etc) Here's the test case if you're interested... https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/BeanMethodHeartbeatTest.java -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com
Re: ServiceMix 4 as a distributed OSGi spring container....
I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). On 10/11/07, James Strachan [EMAIL PROTECTED] wrote: Interesting discussion :) On 11/10/2007, James Strachan [EMAIL PROTECTED] wrote: On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: Bringing this thread to dev list On 10/11/07, James Strachan [EMAIL PROTECTED] wrote: We need to find a way to discover other ServiceMix instances (through ActiveMQ ? any other idea ?) [big snip] From a low level I was wondering about a Camel factory bean in spring camel:heartbeat bean=someBeanRef property=myStatusEventObject millis=2000 uri=http://someServer.com/cheese/ This would call someBeanRef.getMyStatusEventObject() every 2 seconds and send the POJO to the endpoint URI. We could maybe wrap up this using some route? e.g. if the bean endpoint allowed for polling we could maybe do from(bean:someBeanRef?method=getMyStatusEventObjectperiod=2000).to(http://someServer.com/cheese;) though maybe a factory bean (XML element) is a bit easier - it does have better smart completion at least :) I like the idea of using camel to configure the discovery mechanism. This would be very flexible. Yeah; am thinking we could do content based routing or message translator stuff to format the POJO of the heartbeat data into different formats, sending it to different locations etc As an experiment in implementing a POJO based heartbeat mechanism thats protocol and data format independent (and can support the easy integration of EIP) I thought I'd try write a little test case in Camel. It turned out to be surprisingly easy :) from(bean:myService?methodName=status).to(mock:result); where the status() method is invoked periodically on the myService bean and then sent to the registry endpoint (a mock in this case as its a test case, but this could be activemq:topic:foo.bar etc) Here's the test case if you're interested... https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/BeanMethodHeartbeatTest.java -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4 as a distributed OSGi spring container....
On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). Yeah; it does depend on how much data we're talking about. We could slice and dice the data using URLs. e.g. the full list of services available could be posted to some, say, Atom document on some shared server; this list can be updated incrementally or in total as and when services are added or removed. Then the heartbeat could just send around a URL to the detailed information. Or the list of services available could just be dynamically generated on demand if the container exposed a web front end. (push v pull) From a client perspective, it doesn't much care - the heartbeat message contains a URL to the detailed list of actual services provided if it wishes to get more information etc. -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com
Re: ServiceMix 4 as a distributed OSGi spring container....
BTW there's a simple example of how you could write a pure POJO registry without any dependency on any particular middleware or API and wire it together with services heartbeating with Camel here... https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-jms/src/test/java/org/apache/camel/component/jms/discovery/ (though it doesn't do the timeout of heartbeat messages - it was just a simple example to show how things could be wired together really) On 11/10/2007, James Strachan [EMAIL PROTECTED] wrote: On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). Yeah; it does depend on how much data we're talking about. We could slice and dice the data using URLs. e.g. the full list of services available could be posted to some, say, Atom document on some shared server; this list can be updated incrementally or in total as and when services are added or removed. Then the heartbeat could just send around a URL to the detailed information. Or the list of services available could just be dynamically generated on demand if the container exposed a web front end. (push v pull) From a client perspective, it doesn't much care - the heartbeat message contains a URL to the detailed list of actual services provided if it wishes to get more information etc. -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com
Re: [jira] Reopened: (SM-624) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest
Guillaume My apology, it was my first attempt to contribute (i'll be more careful next time) I just realized that myself, so I'll retest all of them as well as play with the code to see if I can figure out why the are not stable. Thanks Oleg On 10/11/07, Guillaume Nodet (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/activemq/browse/SM-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Guillaume Nodet reopened SM-624: This jira issue deals with the MultipleJMSFlowTest, not the JMSFlowTest test. If you look at the core/servicemix-core pom, this test is still disabled, as are several other tests that seems to have timing issues mainly. These disabled tests are not very stable unfortunately, and they sometimes work, sometimes not. Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest --- Key: SM-624 URL: https://issues.apache.org/activemq/browse/SM-624 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Environment: Windows and linux Reporter: Fritz Oconer Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ServiceMix 4 as a distributed OSGi spring container....
On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: On 10/11/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). This was exactly the road I started going down in order to solve a couple of problems: 1) Distributing a consistent configuration across groups of nodes 2) Providing for a central registry that is replicated to other directory server instances This would optionally require a master directory server with other backup or slave servers in order to replicate the registry data. The size of the network and the criticality of the data would determine if you need to run slave servers or not. The other thing I began thinking about was using the AMQ master/slave functionality and just embedding the directory server in the master and the slaves. This would mean less moving parts and we could make any LDAP replications take place via AMQ transports. Doesn't apacheds comes with a clustering / replication solution already ? Yes, it does, but I'm not sure of it's level of efficiency at all as I've not yet looked at it. I have spoken with Ersin Er who works on directory about doing directory replication via ActiveMQ, but we haven't done any work toward it yet. So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). How about just sending the URL and a flag stating that there is an update? If one of the other servers wants the update, then they can poll that server's URL and a known topic for the actual data updates. Yeah. However, for performance reasons, it may be interesting to be able to only publish the delta in addition to provide an easy access to the whole data. Yeah, I really like that idea. It should cut down on traffic significantly. We could also expose the registry as a REST interface, but it may not be the most efficient way. Do we really need to expose the whole registry though? -- 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 as a distributed OSGi spring container....
On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: On 10/11/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). This was exactly the road I started going down in order to solve a couple of problems: 1) Distributing a consistent configuration across groups of nodes 2) Providing for a central registry that is replicated to other directory server instances What I am trying to get my head around, is if this configuration data can be abstracted up to the OSGi level or if it is specific to ServiceMix? I see the specific requirement for this data within ServiceMix itself, but with OSGi there is also the configuration admin service which is a standardized way to provide data to instances of services. I have been thinking about implementing a distributed version of these kinds of OSGi services for a long time so this could be another option. If nothing else, we could support a pluggable registry that could have different implementations depending on the deployment scenario. Just a thought. This would optionally require a master directory server with other backup or slave servers in order to replicate the registry data. The size of the network and the criticality of the data would determine if you need to run slave servers or not. The other thing I began thinking about was using the AMQ master/slave functionality and just embedding the directory server in the master and the slaves. This would mean less moving parts and we could make any LDAP replications take place via AMQ transports. Doesn't apacheds comes with a clustering / replication solution already ? Yes, and I can look into modifying this to use ActiveMQ to do the replication so that we can keep things consistent (current replication is direct TCP with Mina on each node). ApacheDS also allows replication without exposing the actual LDAP server... so it can be embedded and expose a direct JNDIContext without exposing a listener externally yet still achieve replication, which is a common use case for embedded users. So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). How about just sending the URL and a flag stating that there is an update? If one of the other servers wants the update, then they can poll that server's URL and a known topic for the actual data updates. Yeah. However, for performance reasons, it may be interesting to be able to only publish the delta in addition to provide an easy access to the whole data. I think ApacheDS does this now, but I am sure that it could be optimized to fit our needs if it doesn't already. We could also expose the registry as a REST interface, but it may not be the most efficient way. 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/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ I certainly think that ApacheDS could be of some use here, but I don't want to be pushy or biased ;-) There will certainly be some customizations for this use case, but ApacheDS is extensible via interceptors and other similar means. In addition, it might not be well known that ApacheDS is going to start moving to an OSGi container based deployment as well, so that might be useful too. I think these discussions are great and will help expose the requirements as we toss around these ideas and we can keep fine tuning the solution. Chris
