If you like web services, you may be interested in a project that explores
the underlying reason for distributing a system in the first place: to
reduce complexity while enabling collaboration between applications.
You know that UDDI is a mechanism for systems to register the web SERVICES
that they provide. How about a system to register the web EVENTS that
applications can provide and to distribute those events to subscribers.
So your system exposes web services that do the following:
--- return the list of events that can be subscribed to. (Initially empty)
--- allow a system to subscribe to the event, and provide a mechanism for
the event to be sent to the system
--- allow a system to register a set of events that it will provide and info
on each event (for the first call to return).
Then, when an event comes in, the system will determine who subscribed to
it, and will dispatch the event to the subscriber.
Sound easy? Consider this:
-- What if system A wants to subscribe to events that occur, but system A is
not online when the event occurs? How can you make sure that system A gets
the event?
-- What if a malicious user creates a system to send "false" events that
look like an event that system A cares about? How do you insure that system
A doesn't get the false event message?
-- The events from any system must be XML documents. However, they can be
different documents for each event. Should you validate that the event is
valid by checking against a schema? (Schema provided by the publishing
system when they register the event).
-- What happens when your server goes down? Are any undelivered events
lost? They shouldn't be.
-- How would you scale? Can you set up a mechanism for this app to
communicate with another version of itself running on another server? I.E.
a mechanism for all messages to be sent to another system that asks for "all
events"? How would you share the catalog of events? What if these systems
don't have access to the same database server?
-- How do you insure that a message is sent once-and-only-once to a
recipient? Do recipients send acknowledgements? What do you do if your app
sends a message downstream that the downstream app returns a SOAP exception?
Do you send it again? Can you provide options? Can the app be taken down
and brought back up (presumably after it is fixed), and then subscribe to
the event that failed in addition to any other events it missed along the
way?
You can take this from the simple all the way to the very very very complex.
Your project would not only need to create this middleware component, but
also a couple of "test harness" mini-apps to consume the web services and
demonstrate that a message is sent from the publisher, via the event
dispatcher, to only those apps that choose to subscribe to the event.
This is an excellent introduction to the key concepts of systems
integration, SOA, middleware technologies, and the fundamental concepts
behind brokers. There is a lot of very well paid work in this area, and a
huge gap in understanding of these key concepts, making people who know this
stuff pretty valuable.
Good luck,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
