July 2008 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Prototype for Management API for JBM 2

by jmesnil

I've created a branch with a prototype code for JBM 2 Management API: https://svn.jboss.org/repos/messaging/branches/Branch_JBMESSAGING-1303 It follows the management API specified in http://wiki.jboss.org/wiki/JBM2Management The code is not complete but there is already enough to get a feel on how JBM2 will be managed. The steps are: * svn co https://svn.jboss.org/repos/messaging/branches/Branch_JBMESSAGING-1303 * ant runServer * in another shell, start jconsole and connect to the "Local" JVM. * go to the "MBeans" tab * all JBM2 resources are under "org.jboss.messaging" some of the things to show how JBM2 will be managed: * for "JMS > Server" MBean, go to the "Operations" tab and create a JMS Queue "foo" (if you hover on the "createQueue" button or the "name" & "jndiBinding" labels, you will have tooltips appear to describe the operation and its parameters) -> the Queue will appear in "JMS > Queue" -> an Address and a Queue will also be manageable in "Core > Address" and "Core > Queue" * go to "JMS > Queue > MyQueue" and double-click on "MessageCount" value * run "ant perfListener" & "ant perfSender" -> the messageCount will be be displayed as a chart to show the size of the queue as messages are produced/consumed * run "ant durSubExample" * go to "JMS > Topic > testTopic" and click on the "Operations" tab * invoke "listDurablesSubscribers" to have a dialog with info about the durable subscriber * go to "Core > Queue > topicjms.testTopic > myclientid.myuniqueid" to see the Core queue associated to the durable subscriber About the code ----------------- All the management API are in: * o.j.m.core.management for the Core resources * o.j.m.jms.server.management for the JMS resources implementations are in the impl subpackages MBeans are registered/unregistered as their managed resources are created/destroyed. This is done through the ManagementRegistration (resp. JMSManagementRegistration) interface for the Core (resp. JMS) resources which are injected in the code (e.g. PostOffice.setManagementRegistration() & StorageManager.setManagementRegistration()) Code can be completely unit tested using mock (see MessagingControlTest for an example) since the MBean implementations are only thin wrappers on the resources (+ user validation & open type conversion) Open Issues -------------- Some of the things I need to prototype: * Notifications (e.g. when a queue is created/destroyed) will be centralized on the Core server & JMS server MBeans * I'm not convinced that exposing an Address is correct or not. The only important information on the Address MBean is the roles associated to the Address. Adding/removing a role only makes sense for an address, not for a queue. A possibility is to get rid of the Address MBean, move the add/remove role to the Core Server MBean (with an adress parameter) and moved roleInfos to the Queue MBeans (I prefer to have them as attributes than operation on the Server MBean for usability sake) I plan to continue committing in this branch and once the team agreed on the API and implementation, I'll merge it into the trunk Any comments/critics/feedback is welcomed View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165039#4165039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165039

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by kukeltje

That shoud have been: GPD (jPDL, executable) vs BPMN (XMI, analysis) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165003#4165003 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165003

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by kukeltje

Heiko, I think you should check out Toms' blog. It contains several topics on BPMN related 'issues' that can give you at least the basic understanding on GPD vs BPMN. Discussing it afterwards (in a new topic?) would be good. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165001#4165001 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165001

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by heiko.braun＠jboss.com

What's the purpose of having GPD along with a BPMN editor? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164970#4164970 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164970

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by koen.aers＠jboss.com

To add to Tom's latest comment: one of the JBDS developers (Grid Qian) is currently investigating the possibilities for an export wizard from the STP BPMN designer to jPDL that is consumable by the GPD. Regards, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164967#4164967 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164967

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

i didn't yet get to mention my view on how we should support BPMN. I think we should have a (one-way) BPMN to jPDL export functionality in the STP BPMN designer. That fits right into our vision and strategy. Analysts can then model freely in BPMN. When they're done, they can give that BPMN analysis model as part of the requirements input to the development team. Then the development team can do an export to jPDL and further make the process executable. After that, further iterations all happen on the jPDL executable process. The analysts will now still recognize the jPDL diagram. They still can discuss it. But further iterations will not be synchronized back to the original BPMN analysis model. (just like no one would keep their analysis UML class diagrams in sync with the implementation UML diagrams.) Once the tranlation is done to an executable process language, it becomes software is it comes under the control of the development team. That is the bigger picture in which I see the value of a BPMN to jPDL export functionality. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164955#4164955 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164955

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

"alex.guizar(a)jboss.com" wrote : BPMN is a vendor specification. It addresses BPM requirements from the perspective of those vendors who wrote it, not necessarily from the perspective of users. Even if significant research has gone into it, that does not mean it addresses the needs of the jBPM community. | | There are many elements in BPMN 1.1 that have neither been implemented nor requested in jPDL. Examples include the message flow, lanes within pools, and several event triggers and gateway types. Plus, BPMN defines the model semantics but does not address the execution. It is like having the Java Language Spec without the JVM Spec. Some vendors, e.g. Intalio, use BPEL as the execution spec. However, BPEL addresses orchestration, not workflow, and does not really fill the bill. | | I see no advantage in centering our execution design on BPMN: it imposes extraneous requirements and shreds no light on our particular challenges. I believe we should center it on our experiences with jBPM 3, and take BPMN compatibility as a secondary criterion. great concrete explanation of my high level fluffy talk :-) +1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164952#4164952 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164952

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : Quoting Bruce Silver: | | anonymous wrote : | | BPMN is a modeling notation more than just a diagram, since each element has defined process semantics, abstracted from implementation details but BPMN has no official XML schema, i.e. no interchange format. | | [...] | | Bottom line is that neither XPDL nor BPEL today meets the real need of the BPM community, which is a portable serialization of process models not diagrams, models that is independent of implementation architecture. | | | | Taken from: | http://www.brsilver.com/wordpress/2007/03/21/the-real-issues-with-xpdl-bp... | | I agree. BPMN is indeed the only standard that has a real focus on the BPM community. But Bruce's opinion is just one in a very crowdy and dissonant metal rock band. http://blog.lombardicto.com/ http://www.brsilver.com/wordpress/2008/07/14/manchurian-candidate-in-the-... http://www.infoq.com/news/2008/07/BPMNDebate http://www.infoq.com/news/2008/05/BPMN20 http://www.column2.com/2008/03/the-great-bpmn-debate/ So my conclusion is that BPM landscape is not mature at all and the current standards are not viable candidates to limit ourselves to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164951#4164951 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164951

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

"estaub" wrote : I understand that we don't want to try to morph BPMN into an executable language, but I don't understand your objection to using it as a conceptual basis for the API. | Decade ago it was XPDL, Yesterday BPEL, today BPMN and tomorrow it might be BPDM. None of the standardization efforts take into account the dual nature of BPMN. We bring a completely different vision. We're the only ones (ok i'm biased) that accept the different nature of analysis and implementation. I think we are far ahead in terms of dealing with the differences between analysis and implementation. The standards and the bigger part of the market today still think of BPM in terms of analysts that create executable diagrams. Then they think in terms of a monolithic system in a specific environment like e.g. an ESB. I don't have fate in what came out of committees with this background so far. In other words, the BPM space today is not mature at all so it's not good to focus on one of the attempts on the way to maturity. So I will not take a name only because it is BPMN. For each concept, we need to find an appropriate and unambiguous name. Is that the same name as in BPMN, the better. Another point is that the API mainly exposes runtime datastructures and only to a lesser extend the process definition datastructures. The standards are only taking into account the process definition data structures. We will be the ones that show how analysis diagrams can be made executable in a realistic setting. And we're going to bring those ideas to the masses. I don't think its appropriate to focus on one of the specifications that doesn't see our realistic and practical approach to BPM. "estaub" wrote : Do you see a lot of mismatch between BPMN and JPDL? Or does it seem arcane? Or something else? | On the surface, the resemblance is there. But the more you go into the details, the bigger the differences. ...and that is for good reason. BPMN is focussed on analysis. It doesn't have exact execution semantics. And adding those would be a flaw IMO as analysts should be able to model freely without being constraint by the runtime execution of that diagram. Introducing different levels into BPMN could be a viable strategy. So as it is today, there is a lot of mismatch between BPMN and jPDL. BPMN is for analysts (human-to-human communication). jPDL is an executable process language (human-to-computer communication aka software) If BPMN would be changed so that it fits onto jPDL, then BPMN would become less suitable for analysts. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164948#4164948 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164948

17 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by alex.guizar＠jboss.com

BPMN is a vendor specification. It addresses BPM requirements from the perspective of those vendors who wrote it, not necessarily from the perspective of users. Even if significant research has gone into it, that does not mean it addresses the needs of the jBPM community. There are many elements in BPMN 1.1 that have neither been implemented nor requested in jPDL. Examples include the message flow, lanes within pools, and several event triggers and gateway types. Plus, BPMN defines the model semantics but does not address the execution. It is like having the Java Language Spec without the JVM Spec. Some vendors, e.g. Intalio, use BPEL as the execution spec. However, BPEL addresses orchestration, not workflow, and does not really fill the bill. I see no advantage in centering our execution design on BPMN: it imposes extraneous requirements and shreds no light on our particular challenges. I believe we should center it on our experiences with jBPM 3, and take BPMN compatibility as a secondary criterion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164933#4164933 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4164933

17 years, 8 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 July 2008