Laurent:
Laurent Rieu wrote:
Hi there !
A couple of questions about Merlin :
- talking about JMX, is there anything in Merlin's roadmap regarding
a pluggable JMX administration that could provided to the embedded
components ? If so, any hint about how this could be achieved (lifecycle
extensions, specific interfaces, ...) ?
Appliance already has a lot of entry points in terms of how things can be
plugged into it to control its behavior, however, there isn't a mechanisms
to plug in management logic (yet). To make this a little clearer ...
1 manages n
Appliance ---------------------------> Component
(management of a (application logic
deployment scenario) in your component)
In the above picture we have two management concerns - first, we have management
of the appliance, and secondly, we have management of a particular instance. It
seems sensible to enable a management solution such as JMX through a pluggable
controller. A component could declare an optional "manageble" dependency which
could be treaded in a special way - namely, the optionality would be a function
of the ability of the appliance to configure itself with a controller capable of
supporting the component's management view/extension/interface.
E.g.
1 manages n
Appliance ---------------------------> Component
(management of a (application logic
deployment scenario) in your component)
^ ^
| |
* includes instrument manager <------------> * declares instrumentable
to support client's capability
instrumentable viewpoint
* includes JMX controller and <------------> * declares JMX manageable
client functionality as capability
aggregation of the view of
the components it is
managing
IMHO opinion how a component handles persistence is totally an internal implementation issue.- you're talking about several management policies of component instances, such as pooled, one per thread, singleton or transient. What about stateful components storing conversational state for a specific client, such as Stateful EJBs ?
However, conversational state is a lot more interesting because this introduces the notion of policy (protocol) shared between two systems. The approach I'm working on (DPML) deals primarily with requirements for orchestrating peer components. It involves a meta info model extension that describes the notion of a membership (which could be a very light weight association of two or more components). The membership model can be populated with data during component establishment and subsequent invocations. The notion of membership provides (a) temporal ordering, (b) privacy policies, and (c) impict and explit role assignments. Once you have membership semantic implicitly part of the component meta model you can layer on top of that a collaboration model. The collaboration model deals with loose orchestration of components that are interacting in a collaborative context. The model basically defines the rules of engagement and the model itself is accessible to peer components. This enables a component to be both defensive and aggressive in that it can ensure that peer actions performed against itself are consistent with the policy, and that the peer is also acting in accordance with the policy relative to it's context.
The real nice thing about all of this is that you can introduce a lot of intelligent behavior between incoming requests and the actual point where a component invocation occurs (e.g. stuff like dynamic access control, process auditing, flow sequencing, etc.).
However - keep in mind that I'm totally biased towards peer-to-peer distributed components (in terms of both service dependency solutions and implementation strategies) - i.e. all of the above may not correspond much with your question!
- I guess it is not possible at this point to provide my own
management policy (by providing a specific classname in the appliance
descriptor, for example) for a given composant. Am I wrong ? This could
help providing enhanced features such as the management of stateful
components.
- Regarding the URL protocol to access components deployed in Merlin,
what about providing a naming context to locate them ? I agree a URL
protocol is lighter and can easily run in a standalone application. Do you
think adding naming features would be worth the (small ?) effort ?
User's list is fine - if you switch into developing facilities then dev is probably more appropriate.I don't know if those questions should be posted on the users list... but I'm investigating Merlin and am really fond of all those concepts !
Laurent (really impressed by the Merlin stuff !)
Appreciated! Cheers, Steve.
"Schaible, J�rg" <Joerg.Schaible@g To: "Avalon framework users" <[EMAIL PROTECTED]> ft.com> cc: Subject: RE: [Newbie] Merlin demo as webapp ... what next? 02/18/2003 01:56 PM Please respond to "Avalon framework users"
Hello Ulrich,
Fair enough, but be aware that this way you are making the servlet engine the top container and embed an application server(*).Yes, but ... when do expect Merlin to be a full-featured AppServer <g>?Since an application server can not only run servlets, but also generic server applications, it is IMHO more sensible to make it the top container. Servlets are just specialized server applications.Yes again, but when I speak of integrating into a J2EE compiant servlet engine, this implies even WebLogic or WebShpere or other less known systems we have partner contracts ... these are the ones that we meet mainly in the real world. So basically, I have already full-blown appserver functionality, if I need it.Also, from application servers one can expect operational support to manage lifecycle etc. of the applications via a management console. This is something which servlet engines rarely provide and, I believe, never in a standardized way (JMX).Something like this is currently out of scope - at least in this form. Regards, J�rg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
