The implementation details that surround the Observer pattern are also applicable to the Publish/Subscribe pattern. By moving the responsibilities for publishing events out of the entity that originates the events, you need to understand some additional implementation details that are not as intuitive as when the business entity holds the event information and the subscriber lists:
The subscription lists should be persistent: With Web Services, it is unlikely that publishers, subscribers, and the event service itself reside in a single process. This creates an issue if the event service crashes or goes down for maintenance while the subscribers and publishers do not. The expectation of publishers and subscribers will be that they do not have to register again with the event service. This is even truer if the publisher and subscriber do not notice that the event service went offline. Assuming the event service is a Java implementation, simple object-relational mapping mechanisms or even XML binding techniques may be sufficient to provide the persistence across restarts of the event service.
The event service can quickly become a bottleneck between publishers and subscribers: Unlike the observer, all events in a system end up funneling through a couple of methods using a few subscription tables that could become hard pressed to keep up with requests . Some ways to alleviate this problem are to have multiple event services, use multiple threads within the event service, or build in some complex load balancing techniques. On the other hand, if you treat the event service as near-real-time data transfer and not real-time data transfer, your clients should be fine as long as you do not actually lose events or their subscriptions.
Consider the event data structure and topic as part of the interface: Unlike the Observer pattern, the event service in a Publish/Subscribe pattern serves more than one type of event. In fact, in extreme cases, developers can build the event service separately from the applications that use the event service to publish events. Therefore, there are no semantically rich operations on the event service. You should consider the event identifiers and the event data as part of the publisher's interface and contract to ensure that a subscriber has a stable definition from which to program.