I just took a quick look at this (sorry, I've been a bit slow lately) and
I'm completely happy with it EXCEPT for one detail.
In my diagram, note that step 4 is a two-way interaction. I saw no reason to
break it into two steps. Thus "the SRU/S interacts with the SE" can be
modelled as a single step. This is different from (and not symmetric with)
the interaction on the other side between the CA and SRU/C because those are
two steps that occur at different times, namely the first and last step.
(Note that in my diagram there is an error, a missing arrow representing
step 1.)
Tony if you agree, could you redraft this: combine steps 4 and 5 into a
single step (double sided arrow) and renumber, total 7 steps. Then I'll put
it in the document. Otherwise it's fine.
Thanks.
--Ray
----- Original Message -----
From: "Hammond, Tony" <>
To: "OASIS SWS TC" <>
Sent: Tuesday, January 12, 2010 11:22 AM
Subject: [search-ws] SRU Protocol Model Terminology
> Hi:
>
> Following on yesterday's call I made some remarks about the SRU protocol
> model terminology. I am very chary about introducing new (or seemingly
> new)
> terminology - even where terms may be explained in the text. We should aim
> to avoid lessons in algebra.
>
> * Existing terminology
>
> CA client application
> SE search engine
>
> SRUP/C SRU protocol module at the client
> SRUP/S SRU protocol module at the server
>
> PRQ searchRetrieve protocol request
> PRS searchRetrieve protocol response
>
> LLP lower level protocol
>
>
> I am wondering if the following changes might be in order.
>
> 1. Retain CA/SE. (Looked for symmetry but gave up.)
>
> 2. Drop the specious "P" in SRUP/C, SRUP/S. The term "SRUP" is
> horrendous.
>
> 3. Use REQ and RES (or RESP) for PRQ, PRS as these are readily familiar
> terms in client/server architectures. And note that we should avoid the
> term
> "searchRetreive protocol" and instead use the term "SRU protocol".
>
> 4. Let's not be coy about the transport protocol - it *is* HTTP. I
> worry
> that introducing a new layer of abstraction (through the term LLP) is a
> generalization too far. If we need to abstract we should probably use
> "transport protocol" rather than "lower level protocol" because we are
> still
> using SRU semantics but over an HTTP transport layer.
>
> That would lead to the following proposal from me:
>
> * Suggested terminology
>
> CA client application
> SE search engine
>
> SRU/C SRU protocol module at the client
> SRU/S SRU protocol module at the server
>
> REQ SRU protocol request
> RSP SRU protocol response
>
> HTTP HTTP protocol (for transport)
>
>
> I have taken a rough cut at a revised architecture diagram (see .png
> attached) with new labelling, client/server processes more clearly
> indicated, and a cloud for topicality. If this is deemed to be in any way
> useful I could always aim to improve.
>
> Cheers,
>
> Tony
>
>
>
> ********************************************************************************
> DISCLAIMER: This e-mail is confidential and should not be used by anyone
> who is
> not the original intended recipient. If you have received this e-mail in
> error
> please inform the sender and delete it from your mailbox or any other
> storage
> mechanism. Neither Macmillan Publishers Limited nor any of its agents
> accept
> liability for any statements made which are clearly the sender's own and
> not
> expressly made on behalf of Macmillan Publishers Limited or one of its
> agents.
> Please note that neither Macmillan Publishers Limited nor any of its
> agents
> accept any responsibility for viruses that may be contained in this e-mail
> or
> its attachments and it is your responsibility to scan the e-mail and
> attachments (if any). No contracts may be concluded on behalf of Macmillan
> Publishers Limited or its agents by means of e-mail communication.
> Macmillan
> Publishers Limited Registered in England and Wales with registered number
> 785998
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
> ********************************************************************************
>
--------------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
