Re: Need SCA Notification
Hi:
Sorry for the tardiness. I put my comments inline.
- Original Message -
From: Simon Laws [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, June 27, 2007 10:57 PM
Subject: Re: Need SCA Notification
On 6/25/07, Huang Kai [EMAIL PROTECTED] wrote:
Hi, all:
I think a notification mechanism useful to let spi provider know what
is going on in the SCA container.
A notification should be sent when
Contribution/Composite/Component/Artifact start or stop. Ofcoz stop() method
in implementationProvider,bindingProvider,.. can do some work, while some
resources may be shared by or not relavant to any particular provider(
like .composite file or .class file).
So how about adding a notification interface? And
ContributionServiceImpl may be responsible for sending the notification?
this interface may look like:
public static interface ContributionListener{
void addContribution(Contribution contribution);
void removeContribution(Contribution contribution);
void addComposite(Contribution contribution, Composite composite);
void removeComposite(Contribution contribution, Composite composite);
void addComponent(Contribution contribution, Component cmp);
void removeConmponent(Contribution contribution, Component cmp);
void addArtifact(Contribution contribution, DeployedArtifact model);
void removeArtifact(Contribution contribution, DeployedArtifact model);
}
Anyone think alike?
Hi
I think you are on the right track here. Generally we need to get much
better at capturing and presenting the actions/events associated with a
running Tuscany runtime. Your list above is a great stating list of the
static configuration type events we might expect. We could extend this to
included other interesting things, for example, extensions loaded, composite
errors found, service resolution events or even implementation specific or
binding specific events such as the URLs of endpoints that are activated.
Have you come across anything else which it would be useful to raise an
event for?
A recent example is that we want to manually update an implementation file(like
a wsdl), without affecting other artifacts. And notifying the corresponding
ArtifactorProcessor to reload it seems straightforward, compared with
restarting the whole Tuscany.
I agree that a comprehensive event mechanism is needed for a SOA framework. And
surely implemenation can raise event of their own if the event has the right
format.
From an implementation point of view I don't think I would define a single
static interface. I would spin it around and define an event interface and
then allow events to be passed to some event service from where ever in the
runtime the event is generated. To describe specific events we could define
an event data structure and specialise this for the events we decide are
required. In this way we build up a catalog of events. It may be that some
other open source project defines such an event infrastructure but I would
have to go and do a few searches to find out. Do you know of anything that
would fit the bill?
The interface I mentioned in last letter is just a rougth thought. Event is
apparently much better.
I did a quick search in sourceforge, but haven't found any usable project.
In the case where Tuscany is tightly embedded we may want to wrap the event
service and provide an api to the embedding system but this should be fairly
easy to do. Do you have specific examples of how the events would be used?
Or any thoughts about how the events should be delivered?
I think by listening to event/notification providers can be coordinated in a
more flexible way. You can't know in advance who will be interested in such
event as WebServicePortClosedEvent, or a more generic event like
ArtifactUpdatedEvent( this event may sent by an implementatioProvider if it
find some sidefile has been touched, and want to notify the ModelResolver about
this change).
This event mechanism needn't to be very complicated. We could start easily.
As an aside I've been thinking similar thoughts with respect to the
distributed runtime work [1]. I haven't gone to the level of thinking about
events dealing specifically with composites, components and artifacts but no
doubt that could be useful for monitoring and controlling the activity of a
runtime node.
In the distributed runtime code that is checked in to trunk such events are
not explicitly presented but I have implement an example of how we could
implement this. For example, I need to provide configuration information to
each node in the distributed runtime so have chosen to install a system
SCA assembly to manage this for me. It currently only has one component in
it (ComponentRegistry) but allows me to build a configuration interface
without worrying about how that interface is accessed either locally or
remotely. I'm eating our own cooking here!
We could do the same
Re: Need SCA Notification
On 6/25/07, Huang Kai [EMAIL PROTECTED] wrote:
Hi, all:
I think a notification mechanism useful to let spi provider know what
is going on in the SCA container.
A notification should be sent when
Contribution/Composite/Component/Artifact start or stop. Ofcoz stop() method
in implementationProvider,bindingProvider,.. can do some work, while some
resources may be shared by or not relavant to any particular provider(
like .composite file or .class file).
So how about adding a notification interface? And
ContributionServiceImpl may be responsible for sending the notification?
this interface may look like:
public static interface ContributionListener{
void addContribution(Contribution contribution);
void removeContribution(Contribution contribution);
void addComposite(Contribution contribution, Composite composite);
void removeComposite(Contribution contribution, Composite composite);
void addComponent(Contribution contribution, Component cmp);
void removeConmponent(Contribution contribution, Component cmp);
void addArtifact(Contribution contribution, DeployedArtifact model);
void removeArtifact(Contribution contribution, DeployedArtifact model);
}
Anyone think alike?
Hi
I think you are on the right track here. Generally we need to get much
better at capturing and presenting the actions/events associated with a
running Tuscany runtime. Your list above is a great stating list of the
static configuration type events we might expect. We could extend this to
included other interesting things, for example, extensions loaded, composite
errors found, service resolution events or even implementation specific or
binding specific events such as the URLs of endpoints that are activated.
Have you come across anything else which it would be useful to raise an
event for?
From an implementation point of view I don't think I would define a single
static interface. I would spin it around and define an event interface and
then allow events to be passed to some event service from where ever in the
runtime the event is generated. To describe specific events we could define
an event data structure and specialise this for the events we decide are
required. In this way we build up a catalog of events. It may be that some
other open source project defines such an event infrastructure but I would
have to go and do a few searches to find out. Do you know of anything that
would fit the bill?
In the case where Tuscany is tightly embedded we may want to wrap the event
service and provide an api to the embedding system but this should be fairly
easy to do. Do you have specific examples of how the events would be used?
Or any thoughts about how the events should be delivered?
As an aside I've been thinking similar thoughts with respect to the
distributed runtime work [1]. I haven't gone to the level of thinking about
events dealing specifically with composites, components and artifacts but no
doubt that could be useful for monitoring and controlling the activity of a
runtime node.
In the distributed runtime code that is checked in to trunk such events are
not explicitly presented but I have implement an example of how we could
implement this. For example, I need to provide configuration information to
each node in the distributed runtime so have chosen to install a system
SCA assembly to manage this for me. It currently only has one component in
it (ComponentRegistry) but allows me to build a configuration interface
without worrying about how that interface is accessed either locally or
remotely. I'm eating our own cooking here!
We could do the same thing for the event service. In that way we could have
events being made available to the embedding system or being send out over
some management binding without having to write too much code.
What do you think? I'm keen to work with you to get an event system up and
running so let me know how you want to move this forward.
Regards
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime
Need SCA Notification
Hi, all:
I think a notification mechanism useful to let spi provider know what is
going on in the SCA container.
A notification should be sent when
Contribution/Composite/Component/Artifact start or stop. Ofcoz stop() method in
implementationProvider,bindingProvider,.. can do some work, while some
resources may be shared by or not relavant to any particular provider( like
.composite file or .class file).
So how about adding a notification interface? And ContributionServiceImpl
may be responsible for sending the notification?
this interface may look like:
public static interface ContributionListener{
void addContribution(Contribution contribution);
void removeContribution(Contribution contribution);
void addComposite(Contribution contribution, Composite composite);
void removeComposite(Contribution contribution, Composite composite);
void addComponent(Contribution contribution, Component cmp);
void removeConmponent(Contribution contribution, Component cmp);
void addArtifact(Contribution contribution, DeployedArtifact model);
void removeArtifact(Contribution contribution, DeployedArtifact model);
}
Anyone think alike?
