Lists Home |
Date Index |
One other. In the category of aggregate vs replicate, one
wants to keep up with a Record of Authority. For example,
a suspect is brought into a police state and identified
through the usual processes (fingerprint, interview,
checking for aliases, etc). This same information,
typically name, race, physical description, address,
etc. is entered into the police records management
system. Depending on the next agency to handle the
person so identified, (courts, corrections, district
attorney), it is not cost-effective to repeat the
identification process. So one can either point to the
record in the Police RMS (not always a good idea
because not always reliable medium), or use a web service
to request it and store it locally. What one does
not want to do is repeat the identification/authentication
given that the systems needed to do it (mugshot, fingerprint,
other biometric records) may not be available. For
the corrections system, this is an issue at time of
transportation and admittance. For the District Attorney,
that information goes into case files but also has to
be verified at time of transportation and court process.
So we not only have to look at scaling, we have to
know which processes deal with that information, are
the validating systems available at the location
where that process occurs, and is a reliable access
to an ROA required at the time of processing. Is
it the right service from the right source with
the right service aggregation? It leads back to
the notion of orchestration of service types.
From: Roger L. Costello [mailto:email@example.com]
Thanks again everyone for the inputs. Awesome discussion!
I have thought a lot about Amy's point:
> Sometimes it makes sense to have silly-little-services
> that aren't terribly exciting by themselves ... because one
> can foresee that they will get aggregated.
This makes sense. However, it is in direct contradiction to the practice
of making course-grained XML messages. How can these be reconciled?
I think that David Hunter's message is the solution: making
course-grained XML messages is Best Practice "for scalability".