You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Amindri Udugala <am...@gmail.com> on 2011/05/15 10:27:13 UTC
Adding JMX Capabilities for tuscany
Hello,
Here is an update of my work so far,
I created a new jmx module in the modules folder. There I created MXBean
interfaces for some runtime components,
Here are the runtime components,
EndpointReference
Message
ProviderfactoryextensionPointRuntimeComponentreference
RuntimeComponentReference
RuntimeComponentService
RuntimeWireProcessorExtensionPoint
RuntimeWireProcessor
and all other interfaces implementing ProviderFactory interface
(please mention if I need to add more runtime components)
These MXBean interfaces are implemented in classes , in "mgt" sub package
which I created in tuscany-spi-core,
I've got few more questions before proceeding....
When I was going through the Message interface, I understood that neither of
two implementation classes set the messegeID
public Object getMessageID() {
return null;
}
public void setMessageID(Object messageId) {
throw new UnsupportedOperationException();
}
Since many messages can be generated I think it is important to identify
message uniquely. When implementing the JMX management console I propose to
use JSON messages for communication (Wink can be used for this). If a user
needs to change, set or view the message body, of a particular message how
to uniquely identify the message?
The same problem exists with other interfaces (eg EndpointReference) as well
(No way to uniquely identify objects). This would not be a problem if only
one object is created from each runtime components. Or may be that I
misunderstood the whole procedure. Please correct me if I'm wrong
--
Thanks
Amindri Udugala
University of Colombo School of Computing,
Sri Lanka.
Re: Adding JMX Capabilities for tuscany
Posted by Raymond Feng <en...@gmail.com>.
Hi, Amindri.
Thanks for the update. Would you please create a patch and attach it to a JIRA so that we can review and apply. Instead of big changes, incremental progress is preferred.
For the endpoint references and endpoints, they can be identified by the structural uris. For example, componentName/serviceName#service-binding(bindingName).
Raymond Feng
Sent from my iPhone
On May 15, 2011, at 1:27 AM, Amindri Udugala <am...@gmail.com> wrote:
> Hello,
>
> Here is an update of my work so far,
>
> I created a new jmx module in the modules folder. There I created MXBean interfaces for some runtime components,
> Here are the runtime components,
> EndpointReference
> Message
> ProviderfactoryextensionPointRuntimeComponentreference
> RuntimeComponentReference
> RuntimeComponentService
> RuntimeWireProcessorExtensionPoint
> RuntimeWireProcessor
> and all other interfaces implementing ProviderFactory interface
>
> (please mention if I need to add more runtime components)
>
>
> These MXBean interfaces are implemented in classes , in "mgt" sub package which I created in tuscany-spi-core,
> I've got few more questions before proceeding....
>
> When I was going through the Message interface, I understood that neither of two implementation classes set the messegeID
>
>
> public Object getMessageID() {
> return null;
> }
>
> public void setMessageID(Object messageId) {
> throw new UnsupportedOperationException();
> }
>
>
> Since many messages can be generated I think it is important to identify message uniquely. When implementing the JMX management console I propose to use JSON messages for communication (Wink can be used for this). If a user needs to change, set or view the message body, of a particular message how to uniquely identify the message?
>
> The same problem exists with other interfaces (eg EndpointReference) as well (No way to uniquely identify objects). This would not be a problem if only one object is created from each runtime components. Or may be that I misunderstood the whole procedure. Please correct me if I'm wrong
>
>
> --
> Thanks
>
> Amindri Udugala
> University of Colombo School of Computing,
> Sri Lanka.
>
Re: Adding JMX Capabilities for tuscany
Posted by Raymond Feng <en...@gmail.com>.
Btw, I don't think we need to manage the Message objects which are created for each requests to contain context and payload.
Sent from my iPad
On May 15, 2011, at 1:27 AM, Amindri Udugala <am...@gmail.com> wrote:
> Hello,
>
> Here is an update of my work so far,
>
> I created a new jmx module in the modules folder. There I created MXBean interfaces for some runtime components,
> Here are the runtime components,
> EndpointReference
> Message
> ProviderfactoryextensionPointRuntimeComponentreference
> RuntimeComponentReference
> RuntimeComponentService
> RuntimeWireProcessorExtensionPoint
> RuntimeWireProcessor
> and all other interfaces implementing ProviderFactory interface
>
> (please mention if I need to add more runtime components)
>
>
> These MXBean interfaces are implemented in classes , in "mgt" sub package which I created in tuscany-spi-core,
> I've got few more questions before proceeding....
>
> When I was going through the Message interface, I understood that neither of two implementation classes set the messegeID
>
>
> public Object getMessageID() {
> return null;
> }
>
> public void setMessageID(Object messageId) {
> throw new UnsupportedOperationException();
> }
>
>
> Since many messages can be generated I think it is important to identify message uniquely. When implementing the JMX management console I propose to use JSON messages for communication (Wink can be used for this). If a user needs to change, set or view the message body, of a particular message how to uniquely identify the message?
>
> The same problem exists with other interfaces (eg EndpointReference) as well (No way to uniquely identify objects). This would not be a problem if only one object is created from each runtime components. Or may be that I misunderstood the whole procedure. Please correct me if I'm wrong
>
>
> --
> Thanks
>
> Amindri Udugala
> University of Colombo School of Computing,
> Sri Lanka.
>
Re: Adding JMX Capabilities for tuscany
Posted by ant elder <an...@gmail.com>.
Hi Amindri,
It could be good to also support some of the SCA domain things like
installed contributions and running composites, but you don't need to worry
about finding everything yet it might be easier to get going if you just
pick a small few and get something working for those as a first step.
I'm not sure i fully understood the comments about JSON and Wink? Was that
just in relation to access to the Message payloads?
...ant
On Sun, May 15, 2011 at 9:27 AM, Amindri Udugala
<am...@gmail.com>wrote:
> Hello,
>
> Here is an update of my work so far,
>
> I created a new jmx module in the modules folder. There I created MXBean
> interfaces for some runtime components,
> Here are the runtime components,
> EndpointReference
> Message
> ProviderfactoryextensionPointRuntimeComponentreference
> RuntimeComponentReference
> RuntimeComponentService
> RuntimeWireProcessorExtensionPoint
> RuntimeWireProcessor
> and all other interfaces implementing ProviderFactory interface
>
> (please mention if I need to add more runtime components)
>
>
> These MXBean interfaces are implemented in classes , in "mgt" sub package
> which I created in tuscany-spi-core,
> I've got few more questions before proceeding....
>
> When I was going through the Message interface, I understood that neither
> of two implementation classes set the messegeID
>
>
> public Object getMessageID() {
> return null;
> }
>
> public void setMessageID(Object messageId) {
> throw new UnsupportedOperationException();
> }
>
>
> Since many messages can be generated I think it is important to identify
> message uniquely. When implementing the JMX management console I propose to
> use JSON messages for communication (Wink can be used for this). If a user
> needs to change, set or view the message body, of a particular message how
> to uniquely identify the message?
>
> The same problem exists with other interfaces (eg EndpointReference) as
> well (No way to uniquely identify objects). This would not be a problem if
> only one object is created from each runtime components. Or may be that I
> misunderstood the whole procedure. Please correct me if I'm wrong
>
>
> --
> Thanks
>
> Amindri Udugala
> University of Colombo School of Computing,
> Sri Lanka.
>
>
Re: Adding JMX Capabilities for tuscany
Posted by Amindri Udugala <am...@gmail.com>.
Hi,
On 19 May 2011 01:21, ant elder <an...@gmail.com> wrote:
> Is this wink/json approach a replacement for or something different to
> using the JMX standard RMI connector?
>
Yes ant, you are correct. The wink/json approach can be used to can be used
to create a more user friendly GUI, but this is kept as the second step.
>
> I'm not anything like a JMX expert so don't have much idea about whats
> involved so i could be far from what you're intending but i'd thought as a
> start you might just create some tuscany mbeans and use something like mc4j
> to interact with them.
>
Thanx for the advice. I have not herd about mc4j earlier. Seems that I can
interact with mbeans easily than I though. Thanx again :)
>
> ...ant
>
> On Wed, May 18, 2011 at 3:18 AM, Amindri Udugala <amindriudugala@gmail.com
> > wrote:
>
>>
>> Hi ant,
>>
>> Wink and JSON technologies can be used to for interaction between the back
>> end runtime composites and the management console. For an example when all
>> the ProviderFactoryExtensionPoints are needed to be shown on the console, an
>> object containing all information is sent, and Wink converts it to a JSON
>> message. The console can read the JSON message and display the information.
>>
>> It can be used inthe other way roud as well. If some one starts an
>> endpoint the console send a JSON message with all relevant information, and
>> Wink decodes it to an object. Using the getter methods of the object, the
>> relevant endpoint is stopped.
>>
>> Hope that clarifies your problem.
>>
>>
>>
>>
>> On 16 May 2011 08:43, Amindri Udugala <am...@gmail.com> wrote:
>>
>>> HI Raymond.
>>>
>>> Thank you for the reply
>>>
>>> Thanks for the update. Would you please create a patch and attach it to a
>>> JIRA so that we can review and apply. Instead of big changes, incremental
>>> progress is preferred.
>>>
>>> Will soon attach a patch to, JIRA after applying some more changes
>>> For the endpoint references and endpoints, they can be identified by the
>>> structural uris. For example, componentName/serviceName#
>>> service-binding(bindingName).
>>>
>>> Btw, I don't think we need to manage the Message objects which are
>>> created for each requests to contain context and payload.
>>>
>>> Thanx for the clarification ..... :)
>>>
>>>
>>>
>>>
>>> --
>>> Thanks
>>>
>>> Amindri Udugala
>>> University of Colombo School of Computing,
>>> Sri Lanka.
>>>
>>>
>>
>>
>> --
>> Thanks
>>
>> Amindri Udugala
>> University of Colombo School of Computing,
>> Sri Lanka.
>>
>>
>
--
Thanks
Amindri Udugala
University of Colombo School of Computing,
Sri Lanka.
Re: Adding JMX Capabilities for tuscany
Posted by ant elder <an...@gmail.com>.
Is this wink/json approach a replacement for or something different to using
the JMX standard RMI connector?
I'm not anything like a JMX expert so don't have much idea about whats
involved so i could be far from what you're intending but i'd thought as a
start you might just create some tuscany mbeans and use something like mc4j
to interact with them.
...ant
On Wed, May 18, 2011 at 3:18 AM, Amindri Udugala
<am...@gmail.com>wrote:
>
> Hi ant,
>
> Wink and JSON technologies can be used to for interaction between the back
> end runtime composites and the management console. For an example when all
> the ProviderFactoryExtensionPoints are needed to be shown on the console, an
> object containing all information is sent, and Wink converts it to a JSON
> message. The console can read the JSON message and display the information.
>
> It can be used inthe other way roud as well. If some one starts an endpoint
> the console send a JSON message with all relevant information, and Wink
> decodes it to an object. Using the getter methods of the object, the
> relevant endpoint is stopped.
>
> Hope that clarifies your problem.
>
>
>
>
> On 16 May 2011 08:43, Amindri Udugala <am...@gmail.com> wrote:
>
>> HI Raymond.
>>
>> Thank you for the reply
>>
>> Thanks for the update. Would you please create a patch and attach it to a
>> JIRA so that we can review and apply. Instead of big changes, incremental
>> progress is preferred.
>>
>> Will soon attach a patch to, JIRA after applying some more changes
>> For the endpoint references and endpoints, they can be identified by the
>> structural uris. For example, componentName/serviceName#
>> service-binding(bindingName).
>>
>> Btw, I don't think we need to manage the Message objects which are created
>> for each requests to contain context and payload.
>>
>> Thanx for the clarification ..... :)
>>
>>
>>
>>
>> --
>> Thanks
>>
>> Amindri Udugala
>> University of Colombo School of Computing,
>> Sri Lanka.
>>
>>
>
>
> --
> Thanks
>
> Amindri Udugala
> University of Colombo School of Computing,
> Sri Lanka.
>
>
Re: Adding JMX Capabilities for tuscany
Posted by Amindri Udugala <am...@gmail.com>.
Hi ant,
Wink and JSON technologies can be used to for interaction between the back
end runtime composites and the management console. For an example when all
the ProviderFactoryExtensionPoints are needed to be shown on the console, an
object containing all information is sent, and Wink converts it to a JSON
message. The console can read the JSON message and display the information.
It can be used inthe other way roud as well. If some one starts an endpoint
the console send a JSON message with all relevant information, and Wink
decodes it to an object. Using the getter methods of the object, the
relevant endpoint is stopped.
Hope that clarifies your problem.
On 16 May 2011 08:43, Amindri Udugala <am...@gmail.com> wrote:
> HI Raymond.
>
> Thank you for the reply
>
> Thanks for the update. Would you please create a patch and attach it to a
> JIRA so that we can review and apply. Instead of big changes, incremental
> progress is preferred.
>
> Will soon attach a patch to, JIRA after applying some more changes
> For the endpoint references and endpoints, they can be identified by the
> structural uris. For example, componentName/serviceName#
> service-binding(bindingName).
>
> Btw, I don't think we need to manage the Message objects which are created
> for each requests to contain context and payload.
>
> Thanx for the clarification ..... :)
>
>
>
>
> --
> Thanks
>
> Amindri Udugala
> University of Colombo School of Computing,
> Sri Lanka.
>
>
--
Thanks
Amindri Udugala
University of Colombo School of Computing,
Sri Lanka.