November 2006 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover

by timfox

"clebert.suconic(a)jboss.com" wrote : | As the implementation stands now, I guess it's not possible to have multiple nodes taking care of a single failure. | Fine. But when we do in memory message replication this becomes more important. We will want to be able to replicate messages to more than one other server, and in the case the failover server fails too, we still have the messages on the second failover node. (This is similar to buddy replication groups in JbossCache) anonymous wrote : | I can implement it through an interface/abstract class, however I don't see other policies being implemented. | See previous comment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988889#3988889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988889

19 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - event dispatcher

by tom.baeyens＠jboss.com

Today, I had the most perculiar experience. I talked to some academics about ESB technology and despite their reputation, these guys (and galls:-) had a pretty pragmatic and practical approach. I have mentioned this article about business events before. http://docs.jboss.com/jbpm/IEEE-BusinessEventDispatcher.pdf But today, they came and explained it in more depth. Here's my summary. In short, they have shown the motivation for a business event dispatcher component on the ESB. It has learned me how a simple piece of infrastructure was able to give structured approach to integration development. A business event dispatcher is a component that could be associated with an ESB just like a BPEL engine. It has a vocabulary of events that can take place. Then components can subscribe to be notified of these events. The dispatcher will be responsible for notifying the interested components. Notification can be done in different schemes: E.g. dispatcher notifies component A, which in its turn notifies component B, ... Or another scheme can be that the event dispatcher itself contacts all the registered components. These schemes can be predefined patterns or custom pieces of logic. The nice thing about this approach is that it provides a very natural separation between the lower level notification and the overall orchestration of the business events. The event dispatcher can also manage the contextual data related to business events. I also liked the development model that was given as background information with this component. Integration development process 1) First, the business event vocabulary is established 2) Second, the business event orchestration is worked out 3) Third, the notification schemes are worked out * The way that BPEL is perceived/used today, it combines business event orchestration with event notification, resulting in complex processes. Separating these concerns results into better scoping capabilities. The event dispatching approach is most appropriate if you have many systems that need to be kept in sync. That is when you will prevent cluttered BPEL processes by separating the overall business event logic from the way that components are notified of business events. * Keeps the focus on the integration. Mixing a business process modelling aspects with integration might result in a blurry context. I like very much like how the start from business events keeps the focus to the integration scope. Also the focus on the business events give a very nice basis for integration of data. The business events could be enriched with data items that comes from XML documents, database tables, java objects, ... So the underlying framework could take the sources and destination into account. A business event could be graphically shown against a W3C Schema, DB Table, java bean, ... You know those tools where you draw lines between left and right. All these different type systems could be remembered to take into account any mismatches or conversions that need to take place. Also this gives good traceability in case you want to change your central companywide business event data schema. I think that a runtime component that manages the companywide repository of business events with their associated data is very useful. Were there any other discussions or lines of thinking in that direction ? Would you guys think it is interesting to pursue such a component/development cycle on top of the ESB ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988886#3988886 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988886

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover

by clebert.suconic＠jboss.com

anonymous wrote : when node A fails over to node B, node B fails over to node C, node C fails onto node D, node D fails onto node E, node E fails onto node A | | Questions: | | Is this sufficient for our needs? The logic you described above, is what I though for the logic on fail over. anonymous wrote : Is there any sense in supporting multiple failover nodes for a single node? Or does that make no sense? | As the implementation stands now, I guess it's not possible to have multiple nodes taking care of a single failure. anonymous wrote : Should the policy really be pluggable? (Probably yes) I can implement it through an interface/abstract class, however I don't see other policies being implemented. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988883#3988883 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988883

19 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 3.2 web-console not working?

by luismolivares

Then forms made with the JBoss-IDE 2.0 Beta2 will not work on the lastest cvs? I need to start deploying a prototype for jbpm 3.2. Another question is: Can JBoss-IDE 2.0 Beta2 processes deployed on jbpm 3.1.3? Regards View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988875#3988875 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988875

19 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 3.2 web-console not working?

by david.lloyd＠jboss.com

The problem is that the task form you used is not compatible with the latest CVS of the web console. The updated websale example is in CVS head; you can rebuild that and deploy the resulting .jpdl file and it should work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988870#3988870 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988870

19 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Web unit tests

by david.lloyd＠jboss.com

I think that's a wonderful idea, but I would wait on doing any detailed test cases until after I finish the navigation work this week. It would probably be best to focus on getting the test framework up and running, and maybe make sure that it is compatible with ajax4jsf (it should be; if I recall correctly I did get javascript support working properly, but that was a couple months ago). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988860#3988860 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988860

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Branch 1_0_XARecovery

by timfox

"juha(a)jboss.org" wrote : FYI, | | Branch_1_0_XARecovery introduces a tight coupling between TransactionRepository and the currently configured MessageStore service. This is set up by the ServerPeer at startup. | I think this is correct. The message store used by transaction repository should always be the same as the one used by server peer, therefore it wouldn't be appropriate for it to be configured as a separate mbean dependency (for example), so injecting it from server peer sounds right to me. This is current how the persistence manager dependency is injected too for the same reasons. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988848#3988848 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988848

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Branch 1_0_XARecovery

by juha＠jboss.org

FYI, Branch_1_0_XARecovery introduces a tight coupling between TransactionRepository and the currently configured MessageStore service. This is set up by the ServerPeer at startup. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988845#3988845 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988845

19 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XA recovery integration

by timfox

Sounds good View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988842#3988842 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988842

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Zero turnaround Java/JBoss

by sacha.labourey＠jboss.com

Concerning the "clean redeploy" of classes, instead of relying on facing hotswap behaviour or similar, why not use a simpler approach where we would load the NEW classes in a new Classloading tree and start routing new requests to that classes tree once it has been properly loaded? The trick is to make sure that the SAME "containers" and services are able to work on multiple classes trees (and, for example, keep a single version of a cache, or a lock table, of a transaction table, etc. => services and containers would rely on specific ID, not on specific class instances) That way, if you have a long running requests being processed, this request can continue in parallel with new requests. The old request would keep using the old classes definition while new requests could use the new class definitions. That could also speed up app re-deployment A LOT: there wouldn't be this huge gap anymore between the undeploy of version 1 and the total redeploy of version 2: instead, any requests would be able to keep using version 1 while we fully load version 2 and at that time, we can do a micro-switch that would route any incomnig request to the new class tree. This could certainly be easily handled by using the per-container/per-request METADATA i.e. the class tree to use would be specified in the METADATA and used dynamically at runtime by the containers/services. That means we could also support, in a more "production" kind of environment, stable "switch of releases" i.e. JBoss ON could distribute a new version of an application to 50 nodes of a cluster, PREPARE the application by loading it in a new class tree and, once all nodes have successfuly loaded the new tree, you atomically re-route all new requests to this new app => standby mode for pre-loaded apps. This scenario is probably slightly more complex as it would probaly require a change in metadata, hence is possibly a different scenario. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988841#3988841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988841

19 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2006