| Title: |
Q and A - Events vs Services, and Service Asset Data |
| Author: |
David Sprott, John Butler, Lawrence Wilkes |
| Publication Date: |
20 December 2006 |
| Report Type: |
Journal |
| Report Class: |
Best Practice |
| Abstract: |
This report provides answers to questions from a Senior IT Architect Member.
Q1 How do services (and traditional SOA) fit in with a modern EDA?
Q2 Is the Service Registry sufficient? |
| Backgrounder: |
Q1 How do services (and traditional SOA) fit in with a modern EDA?
I'm looking for your opinion on services vs. events (ie. how to manage the intersection of a traditional SOA with that of the EDA that seems to be more prevalent in our wholesale banking arm). Our Wholesale Banking (Securities) group is in the process of rolling out their next generation application architecture - it's classic event-driven programming in that they have a bunch of applications (trading systems and the like) publishing a constant stream of events to another bunch of applications (confirmation systems and the like) with a messaging intermediary brokering all of the interactions. Systems come on, systems come off and nobody is the wiser.
I guess what I'm struggling with is how services (and traditional SOA) fit in with a modern EDA. Here's my thought - let me know if it resonates with you: an event ultimately is consumed and acted upon by a event sink. If the event sink can then pass the event off to a service with a well-defined contract, can we not start to catalog those assets? This allows much more flexibility, to the system, since we now have a service that can either be triggered by a traditional service request or an event (in either case, we have a different bindings and endpoints for different protocols). Thoughts. Suggestions.
Q2 Is the Service Registry sufficient.
We're currently proposing two new roles within our organization to handle the buildout of services as they occur - these two roles are that of the service owner (business representative responsible for the service) and service manager (technology representative responsible for the service).
We're currently lodging these two identities in our traditional System Requirements Specification (SRS) that is specific to the service in question. We're also recording this data in our service registry, under the entry for the specific service. Based on your experiences, is it appropriate to have this data present in both species? Or should one location suffice? In talking to some of my colleagues, their take is that the SRS should really dwell on the functional capabilities of the service, leaving any of the management-type attributes to be housed elsewhere (ie. the registry). |
| Report Size: |
5 pages |
| Report Access Type: |
 | Silver/Gold (Premium) |
|
| Available for separate purchase |
Single copies of recent CBDI Journals may be purchased |
| Login |
|
Home