[Design of JBoss Web Services] - Re: ws-eventing clustering problem
by heiko.braun＠jboss.com
Your approach is perfectly valid. I just think that the problem is not directly related to WS-Eventing. It's more an addressing problem.
Two simple use cases:
1.) client send's subscribe request
1.1 ) loadbalancer points it to node A
1.3) event source on node A addresses the subscription manager (node B) HA-Singleton through HA-JNDI
1.4) event source sends SM EPR (node B) to client
2.) client send's renew
2.1) loadbalancer points it to node C
2.3) EXCEPTION: no subscription manager on node C
OK. So far you are right.
The load balancer doesn't know about the addressing porperties.
But JBossWS does. Currently we can dispatch beased on WS-Addressing properties. I think this should be extended to fully support virtual addresses within a cluster topology.
IMO this problem is not related to WS-Eventing in particular.
It's a WS-Addressing problem that occurs in any cluster toplogy and should addressed there.
Therefore i'd favor a common solution that's build around WS-Addressing and thus supports any WS-* extension which is composed with WSA.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989720#3989720
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989720
17 years, 6 months
[Design of JBoss Web Services] - Re: ws-eventing clustering problem
by heiko.braun＠jboss.com
Thanks for the detailed explanation. Now i clearly see the problem.
The eventing specs allow for SubscriptionManager interposition. This means you can have multiple event sources being handled by just one subscription manager. In composition with WS-Addressing a subscription response contains the subscription manager EPR (endpoint reference). Which basically is the URL plus reference parameters.
Applying this idea to your cluster topology means that you would have a single SubscriptionManager instance running on a particular node, addressed through WS-Addressing.
Still this lacks some features that would need to be implemented:
- SubscriptionManager runs HA-Singleton
- There would only be one EventDispatcher, available through HA-JNDI
- Event sources need to know the subscription manager EPR details. This could be propagated through HA-JNDI.
Does this make sense to you?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989686#3989686
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989686
17 years, 6 months
[Design of JBoss Web Services] - ws-eventing clustering problem
by maeste
As Heiko asked me some times ago I tried to describe in deep when ws-eventing SubscriptionManager need to be clustered in our opinion. I wrote a post on our blog describing the problem and our proposed solution including a Sequence diagram to help me in the description.
I reported here the text of the post, but I kindly suggest to read the post on the blog, because the Sequence Diagram is very useful IMHO.
Let me know if you prefer me to transfer it to a wiki page. The post is this one:
http://www.javalinux.it/blogs/index.php?title=ws_eventing_clustering_prob...
Of course we would have fun to work on this issue.
* Subscription on one of the clustered environment's machine
DESCRIPTION: when a client subscribes to our ws-eventing service the load balancer sends his requests to a real server that receives the subscription and store it locally (in current jbossws eventing implementation this is achieved using a Map owned by SubscriptionManagerMbean). An event source generates a notification and delegates its notification to jbossws; but in a cluster environment this event source could use a different real server knowing nothing about the subscriber. The notification would be lost. See messages from 1 to 5 in the above diagram. Of course a very similar situation may happen when renewing a subscription: a renew message cold be send to a server different from the one that received the first subscription, resulting in subscription renew failure. The client will receive an "Unable to renew" exception, and on the server side the subscription will expire for timeout! All notifications are lost until client re-subscribe to the right real server. See messages from 6 to 13 in the above diagram.
PROPOSED SOLUTION: These two problems could be solved clustering the SubscriptionMap. The easiest solution would probably be arranged using HAJNDI to store subscriptions. Of course the use of a local Map instead of HAJNDI have to be configured at deploy time.
* Shutdown of one of the cluster's machine
DESCRIPTION: SubscriptionManagerMbean sends notifications to remove every subscriptions when it is stopped or the real server it runs on shutdowns. But in a cluster environment other servers continue to work and potentially to send notifications. Those notifications will be lost. See messages from 14 to 26 in the above diagram.
PROPOSED SOLUTION: SubscriptionManagerMbeans have to be clustered and have to exchange their status before they can decide to send this kind of notifications. The solution could be implemented using jGroups (of course), but it needs further investigations and discussions, mainly to understand if SubscriptionManager is the only part of jbossws needing clustered solutions
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989678#3989678
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989678
17 years, 6 months
RE: [jbossws-dev] Status and things to come
by Jason T. Greene
> -----Original Message-----
> From: jbossws-dev-bounces(a)lists.jboss.org [mailto:jbossws-dev-
> bounces(a)lists.jboss.org] On Behalf Of Thomas Diesler
> Sent: Thursday, November 23, 2006 7:30 AM
> To: jbossws-dev(a)lists.jboss.org
> Subject: [jbossws-dev] Status and things to come
>
- snip -
>
> What is important, is that we make good progress on the CTS. Jason is
> still coordinating this effort. I will be back from a short holiday on
> 4-Dec-2006 and take over from Jason then. Everybody, please help Jason
> to get CTS stuff resolved - good luck.
>
> cheers
> -thomas
Thanks Thomas,
Also, it's a US Holiday today and tomorrow, and I am currently visiting
family, so I won't be able to make any significant progress till Monday.
Have a good vacation,
-Jason
17 years, 6 months
Status and things to come
by Thomas Diesler
Folks,
during this week I migrated the 1.0.4 functionality to trunk. AFAIm
aware of there is nothing missing from trunk that works in jbossws-1.0,
except XOP.
Heiko, the JAXRPC XOP functionality still needs to be merged to trunk
although this is not so important right now.
http://jira.jboss.org/jira/browse/JBWS-1313
JAXWS XOP needs to be implemented as well, but this is also not so
important unless we see it in the CTS.
What is important, is that we make good progress on the CTS. Jason is
still coordinating this effort. I will be back from a short holiday on
4-Dec-2006 and take over from Jason then. Everybody, please help Jason
to get CTS stuff resolved - good luck.
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Leadthis
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years, 6 months
[Design of JBoss Web Services] - JAXRPC / JAXWS terminology
by thomas.diesler＠jboss.com
Jason sais:
In order to avoid confusion, I think it is important that we stop
referring to JAX-RPC deployments as "JSR-109 deployments". It's not
really correct since JSR-109 governs EE integration for both JAX-WS and
JAX-RPC. Instead, we should just call them "JAX-RPC deployments"
Also, I think it is important that we make a clear distinction between
JAX-WS and JSR-181. We should refer to the annotated endpoints that are
in JBossWS 2.0.x as "JAX-WS endpoints", and only use the term "JSR-181
endpoints" to refer to the old JAX-RPC based preview technology that was
in 1.0.x.
So these two changes leave us with the following deployment types
JAX-WS - 2.0.x
JSR-181 - 1.0.x only
JAX-RPC - 1.0.x and 2.0.x
This usage of terminology should be consistent in both our code and
documentation.
As part of my work in JBCTS-414 and the eventual SPI, I have refactored
the metadata builders. This also included renaming them to match this
terminology change. I also have split them into separate packages so
that each deployment type can eventually be pluggable.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988153#3988153
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988153
17 years, 6 months
