Use case for Publish/Subscribe - Push Model

I have this first use case scenario.
 
There are several internal systems (all modeled as web services) within an
organization to perform different employee related functions.   These
systems have evolved and or have been added separately and in some cases
perform duplicate functions or retain duplicate information.  There is an HR
system that maintains general information about an employee and his
dependents.  There is a payroll system that keeps the payroll related
information necessary to cut paychecks.  There is a corporate directory that
is used by the corporation to search employees and finally there is a
security system that provides authentication/authorization services for
other internal systems.
 
When a new employee is hired, all these systems need to be updated with
various relevant pieces of information.  Similarly, when an employee is
separated from the company, these systems have to be updated again with that
information.  The corporation decides that the way to integrate these
systems is by enabling real-time data sharing between them.  In the simplest
approach the company decides to build a web service that collects and
disseminates employee related information to interested web services.  Once
done, the HR system can publish employee related information to this service
and the payroll system, corporate directory and the security service can
subscribe to that information.  
 
There are several application design issues that are irrelevant here.  The
issue that is relevant here is for that web service to be able to expose an
interface that the publisher can use to publish and register an interest in
subscription and the subscribers to receive events. 
 
There are obviously other issues.  Messaging can be and probably should be
handled by having a generic service that can create multiple
publication/subscription channels, allow publishers to publish by
identifying those channels and others to subscribe to channels.  The only
important thing is whether WSDL in its current shape enough to describe
appropriate interfaces for this messaging service and the subscribers'
interfaces?  We need to be careful about not getting wrapped up in the
messaging service itself and examine this scenario only from the point of
view of description.
 
Thanks,
 
 
_______________________________________________
Waqar Sadiq
 
EDS EIT ESAI - Enterprise Consultant
MS: H3-4C-22
5400 Legacy Drive
Plano, Texas 75024
 
phone: +01-972-797-8408 (8-837)
e-mail: waqar.sadiq@eds.com <mailto:waqar.sadiq@eds.com> 
fax: +01-972-605-4071
_______________________________________________