I have to define a SOME/IP service in a AUTOSAR classic software component, which, beyond other things, triggers a (asynchronous) NVM operation.
After I receive the job finished notification in the same or another runnable (TBD), I have to give a response indicating whether this was successful.
Can, and if yes how, can I configure that a Runnable gets triggered from a call of the client/ server interface and continues to execute until end, but, when triggered from another interface or even a different Runnable, gives back the response to the SOME/IP call.
I have looked into the "Software Component Template", the "Specification of the RTE Software" and the "Specification of SOME/IP Transformer", but did not find an answer there.
Related
I am calling ServiceBusClient.DisposeAsync for disposing the client object. However, there are processors created from this object which starts throwing an exception saying the object is disposed and it cannot listen anymore. Is there any way to trigger auto closure of service processors when dispose is called? Or, should I get hold of all the processors created from this client and then stop the listening?
The short answer is no; there is intentionally no "stop processing on dispose" behavior for the processor. Your application is responsible for calling StopProcessingAsync.
More context:
The ServiceBusClient owns the connection shared by all child objects spawned from it. Closing/disposing the client will effectively dispose its children. If you attempt to invoke a service operation at that point, an error is triggered.
In the case of a processor, the application holds responsibility for calling start and stop. Because the processor is designed to be resilient, its goal is to continue to recover in the face of failures and keep trying to make forward progress until stop is called.
While it's true that the processor does understand that a disposed set of network resources is terminal, it has no way to understand your intent. Did your application close the ServiceBusClient with the intent that it would stop the associated processors? Did it close the client without realizing that there were processors still running?
Because the intent is ambiguous, we have to take the safer path. The processors will continue to run because they'll surface the exceptions to your application's error handler - which ensures that your application is made aware that there is an issue and allows you to respond in the way best for your application's needs.
On the other hand, if processing just stopped and you did not intend for that to happen, it would be much harder for your application to detect and remediate. You would just know that the processor stopped doing its job and there's a good chance that you wouldn't be able to understand why without a good deal of investigation.
When I read about Command in the DDD Context, it is usually described as an API call.
In this example, serviceA sends a command to serviceB.
serviceA -> serviceB
In my understanding, command is a concrete action on something. So technically this can come in asynchronous forms as well. Maybe sending a command message in a Message Queue.
serviceA -> queue -> serviceB
Are Commands strictly synchronous API calls, or can be asynchronous?
Commands in the context of domain-driven design:
Commands - in the context of domain-driven design - represent the intent for something to happen in the system that leads to some desired outcome after being executed. So it can be seen as some object that contains all the information required by the receiver of the command to execute the command.
So when talking about commands in domain-driven design there is no technical definition or restriction in what way a command can be triggered and transmitted or how the required information is represented.
Commands should be describable from the business perspective first to find out what or who in the system context will trigger it and when it will be triggered. As well as what the expected state shall be after the command has been executed.
Commands can be triggered/transmitted, for instance, the following ways:
Performing some synchronous REST request when a user clicks on a button on a web site
Sending an asynchronous message (e.g. from one Microservice) to the message queue of the command receiver (e.g. another Microservice)
Performing a gRPC call (e.g. from one Microservice to another)
Clicking on a button in the UI of a desktop application
Executing a scheduled background task
Commands in the business context can be, for instance:
Checkout the current shopping basket in an online shop to initiate the order
Upvote and answer on stackoverflow and increase the answer's vote
In the context of domain-driven design it is just some implementation detail if the command is executed synchronously or asynchronously. The important part is that the intended outcome will have happened after the executed has been performed successfully.
When performing a sychronous API call the component that triggered the command can get feedback via a synchronous answer if the command went through ok.
Whereas in an asynchronous command transmission (like messaging) you will only know that the message has been delivered to some queue but the successful execution of the command will have to be perceived in some other way. Either by querying for the current state of the involved domain entities or by leveraging some event-based mechanism where events get published after a command has been executed and any interested parties can subscribe to those events.
TL;DR
Getting back to your questions:
When I read about Command in the DDD Context, it is usually described as an API call.
The API call itself is just the technical data representation and transmission of the command.
Are Commands strictly synchronous API calls, or can be asynchronous?
The same command can be triggered in different ways (see previous examples) and again transmitted in different ways. But no matter how triggered or how transported it will have to contain the same required information and will lead to the same desired outcome in the overall system after being executed.
So, yes it can of course be asynchronous as well.
I'm wondering what is an "official" name for the design pattern where you have a single thread that actually handles some resource (database, file, communication interface, network connection, log, ...) and other threads that wish to do something with that resource have to pass a message to this thread and - optionally - wait for a notification about completion?
I've found some articles that refer to this method as "Central Controller", but googling doesn't give much about that particular phrase.
One the other hand this is not exactly a "message pump" or "event queue", because it's not related to GUI or the operating system passing some messages to the application.
It's also not "work queue" or "thread pool", as this single thread is dedicated only to this single activity (managing single resource), not meant to be used to do just about anything that is thrown at it.
For example assume that there's a special communication interface managed by one thread (for example let that be Modbus, but this really doesn't matter). This interface is completely hidden inside an object with it's thread and a message queue. This object has member functions that allow to "read" or "write" data using that communication interface, and these functions can be used by multiple threads without any special synchronization. That's because internally the code of these function converts the arguments to a message/request and passes that via the queue to the handler thread, which just serves these requests one at a time.
This design pattern may be used instead of explicit synchronization with a mutex protecting the shared resource, which would have to be locked/unlocked by each thread that wishes to interact with that resource.
The best pattern that fits here may be the Broker pattern:
The Broker architectural pattern can be used to structure distributed
software systems with decoupled components that interact by remote
service invocations. A broker component Is responsible for
coordinating communication, such as forwarding requests. as well as
for transmitting results and exceptions.
I would simply call it asynchronous IO, or more catchy: non-blocking IO.
As: does it really matter what that "single thread side" is doing in detail? Does it make a difference if you deal "async" with a data base; or some other remote server?
They key attribute is: your code is not waiting for answers; but expecting information to flow in "later".
I have an activity which signals a service (IntentService) to do various operations. The Activity might stop running but the service carries on until all data is processed. At various points, the service needs to do a TTS speak. The service cannot do the TTS speak initialization as it is an IntentService and it cannot safely register listeners so another task needs to be written.
My question is, what form should the new task take? It needs to:
Process TTS speak requests from the service
Do TTS.shutdown to release TTS resources when nothing remains to be done
Safely register the TTS onInit listener
The first two requirements indicate the task should have a message handler.
One option I can think of is to use a Thread. I am not sure if a Thread can support a handler and I do not know how the run() method should be handled.
I am relatively new to Android. I have programed a Thread, IntentService and activities in my project, I am unsure where to go with these requirements.
I wrote a bound service that gets messages from the IntentService. It achieves all requirements without a message handler.
I've have a couple of questions to which I am not finding any exact answer. I've used CQRS before, but probably I was not using it properly.
Say that there are 5 services in the domain: Gateway, Sales, Payments, Credit and Warehouse, and that during the process of a user registering with the application, the front-end submits a few commands, the same front-end will then, once the user is registered, send a few other commands to create an order and apply for a credit.
Now, what I usually do is create a gateway, which receives all pubic commands, which are then validated, and if valid, are transformed into domain commands. I only use events to store data and if one service needs some action to be performed in other service, a domain command is sent directly from one service to the other. But I've seen in other systems that event handlers are used for more than store data. So my question is, what are the limits to what event handlers can do? And is it correct to send commands between services when a specific service requires that some other service performs an action or is it more correct to have the initial event raise and event and let the handler in the other service perform that action in the event handler. I am asking this because I've seen events like: INeedCreditAproved, when I was hoping to see a domain command like: ApprovedCredit.
Any input is welcome.
You're missing an important concept here - Sagas (Process Managers). You have a long-running workflow and it's better expressed centrally.
Sagas listen to events and emit commands. So OrderAccepted event will start a Saga, which then emit ApproveCredit and ReserveStock commands, to be sent to Credit and Warehouse services respectively. Saga can then listen to command success/failure events and compensate approprietely, like say emiting SendEmail command or whatever else.
One year ago I was sending commands like "send commands between services by event handlers when a specific service requires that some other service performs an action" but a stupid decision made by me switched to using events like you said "to have the initial event raise and event and let the handler in the other service perform that action in the event handler" and it worked at first. The most stupid decision I could make. Now I am switching back to sending commands from event handlers.
You can see that other people like Rinat do similar things with event ports/receptors and it is working for them, I think:
http://abdullin.com/journal/2012/7/22/bounded-context-is-a-team-working-together.html
http://abdullin.com/journal/2012/3/31/anatomy-of-distributed-system-a-la-lokad.html
Good luck