Next Release

[juha]

... will be tagged this Friday. So get your stuff in the CVS.

;-)

-- Juha

[tom.elrod]

Guessing I can leave out my detection/heartbeat stuff? Been trying to catch up with WSDL and UDDI (almost there). Seems like it might be difficult to bend it into something we could use for detection since it seems really focused on providing services at a business level. Still need to figure out how to even run our own internal UDDI registry (so far, only see how to register with IBM's test registry).

Also finally got your JMX book, but have not had a chance to read through it yet. However, I have been thinking more about the InvocationHandler and like the approach as it allows to easily switch out connector protocol implementation. Just have not figured out how to handle notification callbacks (which would also solve heartbeat). Of course we could have notification (and heartbeat) use direct point-to-point communication once the connector client/server has been established as well.

Also don't know enough about the different security authentication models we would want to use (as mentioned before being in each of the remote calls). Can you give me a better idea of what we would want to support? Depending on how many different models we would want to support, we could probably keep all this logic/processing within the actual base MBeanServerInvoker.

[adrian.brock]

What time GMT? After 19:00 is ok for me :-)

I've just about got my stuff to a compitable state.
This is the default domain processing, and other fixes
to the MBeanServer for compliance/robustness.

Basic queryMBeans/Names is working but not the
javax.management.Query support
This is mainly Trevor's code, with a few small
fixes I found during testing.

I could try to get some Query stuff working tonight,
I've got the framework in place.

I'm still trying to track down a 50ms overhead
in the default domain invocations.

Regards,
Adrian

[squirest]

Adrian,

A 50ms (per 100000 right?) sounds small enough to not be spurious object creation - more like an inefficient algorithm.

Check it in and we'll look it over. Remember we've got more than 6 seconds per 100000 to play with compared to the RI. The rest of JBoss isn't going to notice 50ms.

Also what exactly do you mean "few small fixes I found during testing"? My code is always perfect! I'm reminded of the klingon programmer email that makes the rounds every once in a while ;-)

Trev

[adrian.brock]

Hi Trevor,

Look in the spec for "" as a pattern. :p
It's above the laser/printer examples.

The other "fixes" are for default domain, but you'd
already commented in the code that it didn't work :-;

The 50ms/100000 is weird. I've *stared* at the code
and I can't see it??
I'll profile it tonight.

Regards,
Adrian

[juha]

> What time GMT? After 19:00 is ok for me :-)

After 19:00 it is then.

>
> I've just about got my stuff to a compitable state.
> This is the default domain processing, and other
> fixes to the MBeanServer for compliance/robustness.
>
> Basic queryMBeans/Names is working but not the javax.management.Query support
> This is mainly Trevor's code, with a few small fixes I found during testing.
>
> I could try to get some Query stuff working tonight,
> I've got the framework in place.

If you get some basic queries in there, I'll make it a beta release and branch for next version.

-- Juha

[juha]

> Guessing I can leave out my detection/heartbeat stuff?

Sure. We'll make a new release once they're in the CVS.

> Been trying to catch up with WSDL and UDDI
> (almost there). Seems like it might be difficult to
> bend it into something we could use for detection
> since it seems really focused on providing services
> at a business level.

Yep (service discovery, right?). For this, UDDI really doesn't seem to address the things we're interested in. It doesn't attempt to address runtime (dynamic) discovery but compile time (development time) discovery as far as I can tell. There was a reference mentioning IBM is doing some research with dynamic service discovery but I didn't follow it any further.

We should probably implement the simple metadata based discovery that was briefly mentioned in the emails, to get something simple that works in most cases. At least Trevor seemed to be in favor, IIRC.

> Still need to figure out how to even run our own internal UDDI registry (so far, only see how to register with IBM's test registry).

Probably should pick up one of the open source UDDI server implementations (pUDDIng, UDDI4j) and wrap it as an MBean so it can be registered and used by other components. For example, a WSDL adaptor could then take the JMX metadata, convert it to WSDL and export it as a tModel to UDDI registry.

> However, I have been thinking more about the InvocationHandler and like
> the approach as it allows to easily switch out connector protocol implementation. Just have not
> figured out how to handle notification callbacks (which would also solve heartbeat). Of course we
> could have notification (and heartbeat) use direct point-to-point communication once the connector
> client/server has been established as well.

Sure. Pay attention to how the notifications can be configured by the client (to work with firewalls, etc) and keep the API minimal, as the next JMX spec version will probably include remote notification definition. With small API the future spec adaptation will be easier.

> Also don't know enough about the different security
> authentication models we would want to use (as
> mentioned before being in each of the remote calls).

JAAS for authentication and authorization to control MBean attribute and operation access. This work will mostly go on the server side in the mx.interceptor.SecurityInterceptor. In the connector you will need to extract the credentials/principal in the Proxy and attach it as part of the MI context.

Connectors need also encrypt the serialized data: SSLSocketFactory for RMI, SOAP has its own security spec I think (don't know if it's ready), JMS can probably rely on the messaging server to secure the payload (again issue of jmx client config to be able to use a secured channel for communication, both invocations and notifications).

-- Juha