[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
18 years
[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
18 years
[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
18 years
[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
18 years
[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
18 years