Ideally you would dynamically expose all JMX operations and attributes.
In this case the MBean interface would become the SEI. It can't be completely dynamic, because the type mapping still needs to be done.
A dynamic proxy could take care of delegating webservice invocations to the corresponding MBean. This way it relieves the developer from supplying an endpoint implementation.
The sar could be packaged simliar to a war that contains webservice descriptors. The sar deployer should be able to pick it up and deploy a mbean webservice endpoint that it backed by the dynamic proxy.
The endpoint URL can be constructed dynamically from the service name.
Keep in mind that not all MBeans have interfaces, XMbeans (our implementation of ModelMBeans) get their metadata from XML, and with DynamicMBeans it can from anywhere. So your best bet is to use the standard JMX client discovery mechanism getMBeanInfo().
I think you will find that most mbeans use standard types, so initialy you could start with that. Although you could attempt to discover any custom object parameters, and build schema for it if you can, and if not serialize it and inline the serial data as a base64 value. The latter should be considered carefully since this is non-portable.
IMHO this should be done in two ways
1) We only support xmbeans that have a standard webservices element. The link should be the object name
2) JSR181 annotations on the MBean impl
Lets not have any reflection hacks.