[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Web Services Best Practice, summary 3

• To: "'Roger L. Costello'" <costello@m...>, xml-dev@l...
• Subject: RE: Web Services Best Practice, summary 3
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Thu, 10 Jan 2002 15:28:49 -0600

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.

len

-----Original Message-----
From: Roger L. Costello [mailto:costello@m...]


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". 

• Prev by Date: Re: Web Services Best Practice, summary 3
• Next by Date: RE: Web Services Best Practice (was: Interesting XML-DI ST-APP thread)
• Previous by thread: Web Services Best Practice, summary 3
• Next by thread: RE: Web Services Best Practice, summary 3
• Index(es):
  • Date
  • Thread