I think the specific answer depends on the protocol we end up picking, but I’ll answer generally for “messaging” and “resource oriented”. You can do query either
way, and I think it partly comes down to realizing that doing an asynchronous query can work just fine – that’s how DNS works (UDP).
# Messaging
In Java Message Service (JMS), which is an abstraction of messaging systems in general (and therefore a good source of generally-available messaging concepts),
there are a couple ways this could be implemented:
1.
Temporary Queues. The Requestors asks the messaging server for a temporary queue, and specifies that temporary queue in the “Reply-To” of the query
message. The query responder then places the response on this temporary queue. Once the message is consumed and the requestor disconnects, the temporary queue is discarded.
2.
Client-specific Queues. Each client has their own long-lived queue, and this is used as the “reply-to” for query messages. This has the disadvantage
of the server having to maintain a queue for each client, and this might end up being large.
Many messaging systems have a “Time to live” attribute of messages, so the requestor could set a TTL on a request message, then listen to the response queue for
that amount of time before timing out.
# Resource Oriented
There’s probably some variations in here, but I think the main theme is that there’s a resource that responds to queries, and parameters are sent to that resource
via some mechanism (e.g., HTTP GET/POST parameters). Since HTTP is synchronous and most people are familiar with it, think of the request being the query and the response being the query result (or error).
#Conclusion
Query can work across messaging vs resource oriented and synchronous vs asynchronous. Query probably maps better to resource oriented (owing to the request-response
nature of queries), but that will have to be considered against all use cases (once we’ve got them written down).
Personally, my gut reaction is that doing “both” is worse than doing just one. I’d rather have messaging OR resource oriented, acknowledge that it’s not perfect,
but is workable, for certain use cases, and is ideal for others. If you had (for instance) a web server and a messaging broker as required components for any TAXII server, I think that might get out of hand.
Thank you.
-Mark
From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org]
On Behalf Of Wunder, John A.
Sent: Thursday, July 30, 2015 9:50 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Channel Ideas
How do you see channels supporting query/response architectures rather than pub/sub?
FWIW I could see a workable scenario where you have this channels concept for pub/sub and something more resource-oriented for query and
object retrieval.
John
From:
<cti-taxii@lists.oasis-open.org> on behalf of "Jordan, Bret"
Date: Wednesday, July 29, 2015 at 6:32 PM
To: "cti-taxii@lists.oasis-open.org"
Subject: [cti-taxii] Channel Ideas
All,
Here is another diagram for the conceptual ideas that we talked about today on the call, like the one in the PPT. This one is at a bit
more detail but still very high level.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."