Publish - Subscribe with MSE

May 30, 2008 at 7:32 PM
Does MSE support a publish-subscribe model?
I've seen, in the internal stuff, some classes that refer to subscriptions and notifications, but I'm not sure if that's a Message Sechange type of thing, or a sus-system that allows the different services to be notified when The Catalog is updated.

The reason I'm asking is that we recently created an implementation of the Oasis WS-Typics/WS-BaseNotification and WS-BrokeredNotifcation specs. Now we are looking at using the MSE for our bus, routing the Notification Mesages through MSE.

However, if we don't have to, and the functionality already exists, then there's no point in us doing the extra work.

So, now that I've rambled a bit....is there a sublish/Subscribe system in the MSE?
Developer
May 30, 2008 at 11:00 PM
The MSE does make use of Topic based pub-sub to notify the runtimes of changes in the repository.  This is managed through the Catalog Service which has Subscribe/Unsubscribe operations.  Notifications are sent out to all subscribers of the relevant topic (i.e. EndpointUpdated, OperationUpdated).  

For our next release (should be posted later today/this weekend), the notification includes the topic and information about what Runtime/Endpoint/Operation was impacted (the 6.2 release only includes the topic).  Note however, that notifications are only sent if the repository change actually has an impact to the runtime environment.  For example, if an endpoint is updated with a new operation but no MSE Runtimes host the endpoint, no subscribers will be notified.



djessee wrote:
Does MSE support a publish-subscribe model?
I've seen, in the internal stuff, some classes that refer to subscriptions and notifications, but I'm not sure if that's a Message Sechange type of thing, or a sus-system that allows the different services to be notified when The Catalog is updated.

The reason I'm asking is that we recently created an implementation of the Oasis WS-Typics/WS-BaseNotification and WS-BrokeredNotifcation specs. Now we are looking at using the MSE for our bus, routing the Notification Mesages through MSE.

However, if we don't have to, and the functionality already exists, then there's no point in us doing the extra work.

So, now that I've rambled a bit....is there a sublish/Subscribe system in the MSE?


Jun 2, 2008 at 12:02 AM

Soooo...

The question is, is the current implementation enough for application-specific events lke CustomerChanged?

One of the more powerful aspects of the topics-based notification in WS-Topics, that we need,  is that Topics can be Imparative (the application emits a CustomerChanged Notification with the appropriate event arguments) or Declarative (the Notification Producer looks at a list of topics that have XPath statements associated with them and assigns additional topics that the originating application is not aware of).  In the case of CustomerChanged, the application would emit CustomerChanged, but the NotificationProducer Implementation will look at that and also attach the CustomerMovedToCalifornia topic and/or the CustomerMovedToDifferentState topic based on the declarative topic definitions. For example.....

<wstop:TopicNamespace xmlns:wstop="..." xmlns:cst="uri:customer">
     <wstop:Topic name="CustomerChanged" messageTypes="cst:CustomerChanged cst:NewCustomer cst:CustomerUpdated"/>
     <wstop:Topic name="CustomerMovedToNewState">
          <wstop:MessagePattern dialect="....xpath namespace here.....">
                   /cst:CustomerChanged[cst:NewLocation/@state != cst:OldLocation/state]
          </wstop:MessagePattern>
     </wstop:Topic>
</wstop:TopicNamespace>

So, how ready for Application-specific Events is the MSE?


botto wrote:
The MSE does make use of Topic based pub-sub to notify the runtimes of changes in the repository.  This is managed through the Catalog Service which has Subscribe/Unsubscribe operations.  Notifications are sent out to all subscribers of the relevant topic (i.e. EndpointUpdated, OperationUpdated).  

For our next release (should be posted later today/this weekend), the notification includes the topic and information about what Runtime/Endpoint/Operation was impacted (the 6.2 release only includes the topic).  Note however, that notifications are only sent if the repository change actually has an impact to the runtime environment.  For example, if an endpoint is updated with a new operation but no MSE Runtimes host the endpoint, no subscribers will be notified.



djessee wrote:
Does MSE support a publish-subscribe model?
I've seen, in the internal stuff, some classes that refer to subscriptions and notifications, but I'm not sure if that's a Message Sechange type of thing, or a sus-system that allows the different services to be notified when The Catalog is updated.

The reason I'm asking is that we recently created an implementation of the Oasis WS-Typics/WS-BaseNotification and WS-BrokeredNotifcation specs. Now we are looking at using the MSE for our bus, routing the Notification Mesages through MSE.

However, if we don't have to, and the functionality already exists, then there's no point in us doing the extra work.

So, now that I've rambled a bit....is there a sublish/Subscribe system in the MSE?





Developer
Jun 2, 2008 at 4:14 PM
It's really not the intent of the MSE's pub-sub implementation to act as a generic pub-sub for other systems.  If you look at the source code for the catalog, you'll notice it has default implementations for ISubscriptionManager and INotificationManager.  ISubscriptionManager manages the list of subscribers while INotificationManager makes the determination based on a published topic, which subscribers are notified.  In these implementations there are assumptions that the topics being published are related to the MSE.  The extensibility offered in this area is so that the MSE could be modified to tap into other pub-sub systems that may be in place at an organization (typically by using its subscription store or by allowing other management systems to send notifications to the MSE Runtimes telling them to bring up/tear down an endpoint).

That being said, the source for the Catalog is available to you.  You could attempt to enhance the MSE pub-sub Subscription/NotificationManager in place but you'll risk disrupting the notification mechanism that keeps the MSE Runtime up to date.



djessee wrote:

Soooo...

The question is, is the current implementation enough for application-specific events lke CustomerChanged?

One of the more powerful aspects of the topics-based notification in WS-Topics, that we need,  is that Topics can be Imparative (the application emits a CustomerChanged Notification with the appropriate event arguments) or Declarative (the Notification Producer looks at a list of topics that have XPath statements associated with them and assigns additional topics that the originating application is not aware of).  In the case of CustomerChanged, the application would emit CustomerChanged, but the NotificationProducer Implementation will look at that and also attach the CustomerMovedToCalifornia topic and/or the CustomerMovedToDifferentState topic based on the declarative topic definitions. For example.....

<wstop:TopicNamespace xmlns:wstop="..." xmlns:cst="uri:customer">
     <wstop:Topic name="CustomerChanged" messageTypes="cst:CustomerChanged cst:NewCustomer cst:CustomerUpdated"/>
     <wstop:Topic name="CustomerMovedToNewState">
          <wstop:MessagePattern dialect="....xpath namespace here.....">
                   /cst:CustomerChanged[cst:NewLocation/@state != cst:OldLocation/state]
          </wstop:MessagePattern>
     </wstop:Topic>
</wstop:TopicNamespace>

So, how ready for Application-specific Events is the MSE?


botto wrote:
The MSE does make use of Topic based pub-sub to notify the runtimes of changes in the repository.  This is managed through the Catalog Service which has Subscribe/Unsubscribe operations.  Notifications are sent out to all subscribers of the relevant topic (i.e. EndpointUpdated, OperationUpdated).  

For our next release (should be posted later today/this weekend), the notification includes the topic and information about what Runtime/Endpoint/Operation was impacted (the 6.2 release only includes the topic).  Note however, that notifications are only sent if the repository change actually has an impact to the runtime environment.  For example, if an endpoint is updated with a new operation but no MSE Runtimes host the endpoint, no subscribers will be notified.



djessee wrote:
Does MSE support a publish-subscribe model?
I've seen, in the internal stuff, some classes that refer to subscriptions and notifications, but I'm not sure if that's a Message Sechange type of thing, or a sus-system that allows the different services to be notified when The Catalog is updated.

The reason I'm asking is that we recently created an implementation of the Oasis WS-Typics/WS-BaseNotification and WS-BrokeredNotifcation specs. Now we are looking at using the MSE for our bus, routing the Notification Mesages through MSE.

However, if we don't have to, and the functionality already exists, then there's no point in us doing the extra work.

So, now that I've rambled a bit....is there a sublish/Subscribe system in the MSE?








Jun 2, 2008 at 4:42 PM

Grooviness.

We'll keep our pub-sub manager in place, but expose it through the MSE


botto wrote:
It's really not the intent of the MSE's pub-sub implementation to act as a generic pub-sub for other systems.  If you look at the source code for the catalog, you'll notice it has default implementations for ISubscriptionManager and INotificationManager.  ISubscriptionManager manages the list of subscribers while INotificationManager makes the determination based on a published topic, which subscribers are notified.  In these implementations there are assumptions that the topics being published are related to the MSE.  The extensibility offered in this area is so that the MSE could be modified to tap into other pub-sub systems that may be in place at an organization (typically by using its subscription store or by allowing other management systems to send notifications to the MSE Runtimes telling them to bring up/tear down an endpoint).

That being said, the source for the Catalog is available to you.  You could attempt to enhance the MSE pub-sub Subscription/NotificationManager in place but you'll risk disrupting the notification mechanism that keeps the MSE Runtime up to date.



djessee wrote:

Soooo...

The question is, is the current implementation enough for application-specific events lke CustomerChanged?

One of the more powerful aspects of the topics-based notification in WS-Topics, that we need,  is that Topics can be Imparative (the application emits a CustomerChanged Notification with the appropriate event arguments) or Declarative (the Notification Producer looks at a list of topics that have XPath statements associated with them and assigns additional topics that the originating application is not aware of).  In the case of CustomerChanged, the application would emit CustomerChanged, but the NotificationProducer Implementation will look at that and also attach the CustomerMovedToCalifornia topic and/or the CustomerMovedToDifferentState topic based on the declarative topic definitions. For example.....

<wstop:TopicNamespace xmlns:wstop="..." xmlns:cst="uri:customer">
     <wstop:Topic name="CustomerChanged" messageTypes="cst:CustomerChanged cst:NewCustomer cst:CustomerUpdated"/>
     <wstop:Topic name="CustomerMovedToNewState">
          <wstop:MessagePattern dialect="....xpath namespace here.....">
                   /cst:CustomerChanged[cst:NewLocation/@state != cst:OldLocation/state]
          </wstop:MessagePattern>
     </wstop:Topic>
</wstop:TopicNamespace>

So, how ready for Application-specific Events is the MSE?


botto wrote:
The MSE does make use of Topic based pub-sub to notify the runtimes of changes in the repository.  This is managed through the Catalog Service which has Subscribe/Unsubscribe operations.  Notifications are sent out to all subscribers of the relevant topic (i.e. EndpointUpdated, OperationUpdated).  

For our next release (should be posted later today/this weekend), the notification includes the topic and information about what Runtime/Endpoint/Operation was impacted (the 6.2 release only includes the topic).  Note however, that notifications are only sent if the repository change actually has an impact to the runtime environment.  For example, if an endpoint is updated with a new operation but no MSE Runtimes host the endpoint, no subscribers will be notified.



djessee wrote:
Does MSE support a publish-subscribe model?
I've seen, in the internal stuff, some classes that refer to subscriptions and notifications, but I'm not sure if that's a Message Sechange type of thing, or a sus-system that allows the different services to be notified when The Catalog is updated.

The reason I'm asking is that we recently created an implementation of the Oasis WS-Typics/WS-BaseNotification and WS-BrokeredNotifcation specs. Now we are looking at using the MSE for our bus, routing the Notification Mesages through MSE.

However, if we don't have to, and the functionality already exists, then there's no point in us doing the extra work.

So, now that I've rambled a bit....is there a sublish/Subscribe system in the MSE?