Anyone experienced with the ActivityPub protocol who can clarify something for me?
For server-server federation (S2S), what's the correct delivery logic when something is addressed to a remote followers collection?
7.1 of the ActivityPub spec says:
The inbox is determined by first retrieving the target actor's JSON-LD representation and then looking up the inbox property. If a recipient is a Collection or OrderedCollection, then the server MUST dereference the collection (with the user's credentials) and discover inboxes for each item in the collection
But that seems like it would incur a ridiculous number of GET requests to the remote server: one to get the JSON-LD for the Collection, then one for each item in the collection to retrieve its JSON-LD. It's even worse if the remote Collection is paged.
7.1.1 of the spec says (emphasis mine):
When objects are received in the outbox (for servers which support both Client to Server interactions and Server to Server Interactions), the server MUST target and deliver to: The to, bto, cc, bcc or audience fields if their values are individuals or Collections owned by the actor.
This appears to contradict 7.1, when it says the server must dereference everything.
Can anyone explain what I'm missing?
Related
I am using DCMTK storescp.exe to receive images from a CR modality and then process/save them in my DB.
Is it possible to use other DCMTK binary to manually send the PatientName and PatientId to CR modality before the patient goes there?
I have read somewhere that the modality makes a query to get the Modality Worklist. I would like to reverse that flow. I want to directly send the Modality Worklist to the modality, whenever I like, without receiving the query from Modality.
Is that possible? If yes; how can I do that with DCMTK?
Please note that this is not an off-site tool request. I just want to know the DCMTK binary that implements required DICOM service/command.
You are looking for Modality Worklist or MWL service which implements C-FIND command.
SOP Class: 1.2.840.10008.5.1.4.31 [Modality Worklist Information Model – FIND].
But it does not work the way you are expecting; and it should not - for good.
MWL SCU (in your case - CR) initiates the query with the (optional) filters it suits. As usual, association happens and MWL SCP receives the MWL Request. It then fetch the data from its database matching the filters if any. It then sends one MWL Response for each row fetched from database, status for each response is PENDING. When all the rows are transferred, final SUCCESS response is sent. If no rows were found matching the filter, only final response is sent. If something goes wrong, proper failure response is sent. SCU then, sends the Release Request and on receiving Release Response, it closes the association.
Now, why your expected workflow is not possible?
Generally MWL SCP is implemented by RIS systems. These systems have tools/features to register the patient demographic data while/before admission of the patient in hospitals. They also have features to schedule the orders to be executed by Modalities. There might be multiple modalities in given DICOM Network (hospital). Though, RIS have a way to decide which order should go to which modality (based on AE Title if configured and used properly), they cannot push it because they are acting as SCP i.e. Server. As any other server in any network protocol, they have to wait for request from client i.e. SCU.
Further, though SCP may know which order should be sent to which modality, modality may not expecting that order for many reasons. So, the general flow in MWL is the way I explained above. You cannot implement your reverse workflow with any DICOM service/command.
Just for the sake of clarity:
All this has nothing to do with the data you received and stored in DB using storescp.exe. I mean, you do not generally send that data to modality as Modality Worklist.
MWL happens first. When modality get the MWL Worklist item, it conducts the study and acquires images with the demographic data received in MWL Worklist item. This way, errors are avoided, redundant inputs are avoided and flow is bit automated. When done, modality push (C-STORE) the instances (CR images in your case) to C-STORE SCP which is storescp.exe in your case.
I planned to implement a Storage Commitment Service to verify if files previously sent to the storage were safely stored.
My architecture is very simple and straightforward my SCU sends some secondary capture images to the storage and I want to be sure they are safely stored before delete them.
I am going to adopt push model and I wonder what steps/features I need to implement to accomplish the service
What I understood is
I need to issue a N-ACTION request with SOP Class UID
1.2.840.10008.1.20.1 and add to the request a transaction identifier together with a list of Referenced SOP Class UID – Referenced SOP
Instance UID where Referenced SOP Instance UID are the UIDs of the
secondary capture images I previously sent to the storage and
Referenced SOP Class UID in my case is the soap class identifier
representing the Secondary Capture Image
Wait for my N-ACTION response to see if the N-ACTION request succeed
or not
Get the response from the storage in form of N-EVENT-REPORT
But when? How the storage give me back the
N-EVENT-REPORT along with the results? Does my SCP AE implements some
SCP features? Or I need to issue a N-EVENT request to get a
N-EVENT-REPORT?
Have a look at the image below copied from here:
Now, about your question, following is the explanation assuming same association will be used for entire communication. For communication over multiple associations, refer above article from Roni.
But when?
Immediately. On same connection/association. On receiving NAction response, you should wait for timeout configured in your application. Before timeout expires, you should get the NEventReport.
How the storage give me back the N-EVENT-REPORT along with the results?
When you receive NAction response from SCP, that means SCP saying "Ok; I understood what you want. Now wait while I fetch your data...". So, you wait. When SCP is ready with all the data (check list) necessary, it just sends it back on same association through NEventReport. You parse the Report and do your stuff and send response to SCP saying "Fine; I am done with you." and close the association.
Does my SCP AE implements some SCP features?
No (in most of the cases); you do not need to implement any SCP features in both (single association/multiple associations) cases. You should get NEventReport on same association as mentioned above. DICOM works on TCPIP. Client/Server concept in TCP is only limited to who establishes the connection and who listens for connections. Once the connection is established, any one can read/write data on socket.
In rare cases, SCP sends NEventReport by initiating new association on its own. In that case, SCU need to implement SCP features. This model is not in use as far as I am aware. It is difficult to implement this model for both SCP and SCU. It also needs multiple configurations which everyone tends to avoid. So, this could be neglected. I am calling this rare because I never (at least so far) come across such implementation. But yes; this is valid case for valid reason.
Or I need to issue a N-EVENT request to get a N-EVENT-REPORT?
No; as said above. Refer this.
J.3.3 Notifications
The DICOM AEs that claim conformance to this SOP Class as an SCP shall invoke the N-EVENT-REPORT request. The DICOM AEs that claim conformance to this SOP Class as an SCU shall be capable of receiving the N-EVENT-REPORT request.
That said, SCU should be able to process NEventReport. It will NOT issue it.
There are three different sequences of events possible. I could describe them here, but this article is really excellent: Roni's DICOM blog
I have nothing to add to what is written there.
By reading the Handing off work section in wiki, it seems that you can do one way publishing in rebus with one way mode. But I thought one way mode only allows bus.send?
If in a scenario, where I have two applications both can publish SomethingHappened message, but only one of the application should handle the reply from ProcessManager, e.g. DoSomethingElse, how should I configure rebus for both applications?
Regards
Yin
But I thought one way mode only allows bus.send?
Nothing will prevent you from doing a bus.Publish from a one-way client as long as it has a properly set up subscription storage. And if something else populates that subscription storage with some subscriptions (e.g. you, by inserting them manually in the db, or by having another publisher handle subscribe/unsubscribe) then something might actually happen when you publish ;)
how should I configure rebus for both applications?
Without having a totally clear image of your scenario, I'm thinking that
one publisher, A, has an input queue: publisherA
the other publisher, B, has no input queue (i.e. it's a one-way client)
the two publishers share their subscription storage (e.g. a table in SQL Server)
the two publishers publish messages from assembly StuffToPublish
other endpoints have an endpoint mapping that maps StuffToPublish to publisherA - therefore, a bus.Subscribe with an event type from StuffToPublish will make publisher A establish the subscription
published messages from A and B will go to the same subscribers because they share their subscription storage
If you want publisher A to handle replies even though the event was published by publisher B, you can make B supply the rebus-return-address header (which would otherwise automatically be set, had B had an input queue) like so:
bus.AttacheHeader(someEvent, Headers.ReturnAddress, "publisherA");
This way, replies will be sent to the publisherA input queue.
I have already googled a lot this subject, read various articles about this header, its use in Heroku, and projects based on Django.
However, it's still all confused in my head.
What is the purpose of this header?
Does it violate user privacy?
Can it help tracking a user?
When you're operating a webservice that is accessed by clients, it might be difficult to correlate requests (that a client can see) with server logs (that the server can see).
The idea of the X-Request-ID is that a client can create some random ID and pass it to the server. The server then include that ID in every log statement that it creates. If a client receives an error it can include the ID in a bug report, allowing the server operator to look up the corresponding log statements (without having to rely on timestamps, IPs, etc).
As this ID is generated (randomly) by the client it does not contain any sensitive information, and should thus not violate the user's privacy. As a unique ID is created per request it does also not help with tracking users.
Purpose: Idempotency
With an ID that changes for every request, but stays the same in case of a retry of a request, the receiver can ensure the request won't get processed more than once.
This is a quote from some API provider:
All POST, PUT, and PATCH HTTP requests should contain a unique
X-Request-Id header which is used to ensure idempotent message
processing in case of a retry
If you make it a random string, unique per request, it won't infringe on your privacy, nor enable tracking.
If you want to know more of what idempotency has to offer, read this insightful article.
N.B. As Stefan Kögl comments, this header is not standardized - hence the (deprecated) "X-" prefix.
Explanation using a story/analogy
You can think of X-Request-ID like your driver's license (some type of ID card).
Imagine visiting the DMV:
You present your ID card to gain admission, and then you
Stand in line, for 16 hours,
after 16 hours - the DMV tells you to go home. i.e. your request timed out. The petty tyrants at the DMV don't work a second past 4:31 pm.
An entire day wasted - you complain to the congressman - hey: I waited in line for 16 hours etc. The congressman replies:
"Buddy, we get 1000s of people visiting the DMV everyday - When I look through the DMV records, how am I meant to identify you - when you came etc.?
That's where the X-Request-ID comes in.
Application of story to HTTP
The same applies to http requests - it's an id used to help back end devs find out what went wrong. Clients submit requests with that id - and it's a ID that they create (i.e. some random number etc.). Now servers can keep track of it.
Story given to help you remember. Hopefully you're not confused further - post a comment if I have and i'll try to clear it up. thx.
This request header can be used for syncrhonization. Let's say you've built a ToDo list that offers offline capability. Your user creates 3 items and each of them are given a unique UUID on the offline application. When network connectivity is available, the records are POSTed to the server and the corresponding IDs auto-generated from the database are returned. You can then replace the IDs in your app (e.g. "id" attribute of HTML "li" element).
I'm working on an application that allows users to send internal message to one-another.
I'll tell you what the current setup is and please help me figure out how to make it work or perhaps suggest another angle to take. We're using BlazeDS with Spring.
User A listens for messages on
message topic Chat.A
User B listens for messages on message topic Chat.B
Both users listen for global messages (system-wide messages) on topic Chat.System
So we have a multi-topic consumer for the personal message topic and one for the global message topic.
So a couple of questions I have:
Is it better to do it as two
distinct consumers (that share the
same handler function) or as one,
multi-topic consumer?
How do I check that the client A is actually the one listening to Chat.A and not just some one else that knows how to write BlazeDS clients? We have Spring Security in place, but how can I listen for subscription requests and block them if their user name (pulled from security context) doesn't match the sub-topic that they requested?
I've also read about selectors. Well, that looked promising, but again, how do I check that when a consumer uses selector="for == A || for == System that the consumer belongs to a client that has authenticated as that "for" user.
How do selectors compare/contrast to sub-topics? What's the best situation for each of them?
A selector is basically an expression you can use to filter which messages will be dispatched through your consumer. According to the docs, it uses SQL 92 conditional expression syntax:
http://livedocs.adobe.com/blazeds/1/blazeds_devguide/help.html?content=messaging_6.html
A subtopic is sort of a special case of a selector, filtering out messages whose "DSSubtopic" header don't match the provided value.
The important thing to understand with both of these is that the client determines which messages are sent to it, and as such it cannot be relied upon entirely for security.
To implement secure server-based filtering of messages based on an authenticated user's identity, see my answer to a related question here:
Flex Messaging Security
As far as multiple Consumers vs. MultiTopicConsumer, not sure there. They're both going to use the same underlying ChannelSet, so it ought not to have a big performance difference. I think it's mostly a question of whether it's convenient to have one event handler that responds to all messages from the MultiTopicConsumer or whether it's easier to have separate event handlers for each Consumer.
I usually use subtopics for this. But if you do it that way make sure that you disable subscriptions to wildcard subtopics.