What if an IN-AE creates a group of lights with ADN-AE1 and ADN-AE2, controlling them by using just one request. The diagram shows that, it uses one request to control both of them but when I click the request example, its creates <contentInstances> one by one. Is there any example that I can control a group of resources with just one request or this is not in oneM2M's scope ?
Call flows for multiple light control are depicted in the figure below
and are ordered as follows:
When the user updates a group of light states on her/his smartphone,
the IN-AE creates a new contentInstance targeting a group of Light
ADN-AE container resources hosted on the MN-CSE. Request shown here
For each contentInstances created successfully, the MN-CSE sends a
notification to the corresponding Light ADN-AE.
---------------------- --------- EDITED -------------------------------
A <group> resource bundles and manages a number of resources (either of the same or of a mixed resource type), in your example the two <container>'s under ADN-AE1 and ADN-AE2.
In addition to its other attributes a <group> has a virtual resource called the <fanOutPoint>. This virtual resource multiplies internally every request it receives for all the fitting resources of the <group>, be it CREATE, READ, UPDATE or DELETE.
In the example, the <container>'s exist before they are organised in a group, and can be accessed and controlled independently. The <group> resource now bundles them together and makes them available for an application as a single entity. When this <group> receives a CREATE request for a <contentInstance> the group automatically creates a new <contentInstance> resource for all its resources. For the ADN-AE's, though, it doesn't matter who and how the <contentInstance>'s where created.
Interestingly, this decouples the IN-AE application from the actual deployment and orchestration of an infrastructure. Just imagine that a <group> bundles all the lights in a home. This <group> is managed by a home manager AE. Now, another AE, for managing the home when the inhabitants leave, doesn't need to know much about the actual devices in the home. It only needs to sends one request to the <group> resource to switch off all the lights.
Update
Check oneM2M's "TS-0001 - Functional Architecture", sections "9.6.13 - Resource Type group" for the <group> and "9.6.14 - Resource Type fanOutPoint" for the <fanOutPoint> for the specification of this behaviour.
Related
My model is a basic warehouse situation model. Trucks enter the model, are seized by an empty loading dock resource and then offloaded by the forklifts. The trucks location (loading bay 1, loading bay 2 etc.) is determined by the available resource that gets seized. My "move-to" block then has the "move to location of seized resource" option ticked. In this case, the truck half of the model is working as expected.
The forklift half is a little harder. I have been advised to inject pallet agents into the model instead of splitting them off the incoming trucks. The problem is that I can't specify the location of the agents to a specific resource.
How can I save the location of the newly parked truck (loading bay 1, loading bay 2 etc.) in a variable, and then call on that same variable to inject the agents into that location? The nodes that are acting as the loading bays, are the home locations of specific resources (loading bays).
When I save the location (varAgentLocation = getNetworkNode();) I have to set the variable type to type "custom" (INode) to void errors. The if I type "varAgentLocation" in the location box of the source, I get an error stating that the types are not the same (INode and InitialLocationType)
Using home locations for your (non-moving) loading bay resources is unnecessary.
Just have them as custom resource agent types (e.g., agent type LoadingBay, not vanilla Agent) with a type Node parameter that you set at model startup to be the relevant space markup nodes. (You need to have the resource pool add the resource agents to a custom (initially empty) population of LoadingBays you've created beforehand; this allows you then to loop through the resource agents at model startup to setup any parameters, etc. for them.)
Then probably the most coherent way is to
Copy this value into a variable within your Truck agent via the on-seize action of your Seize block.
Have your Pallet agents created with a reference to the Truck agent they came from (in a variable or parameter). There are various design alternatives for whether the pallets exist beforehand (where you might use an Unbatch block to 'release' them) or whether you create them on the fly.
When you inject pallet agents into, say, a Source block, set that to have the arrival node (which can be a dynamic expression) getting the relevant node from the 'parent' Truck agent (e.g., something like agent.arrivalTruck.loadingBayNode).
For example I have a post service. At UI I need to show post and userinfo (username and id for redirect to user page)
Options:
Should I store username and id in post service. (When every user register to system I will send subset detail to post service via RabbitMQ). (Total Request from UI= 1)
I will store only Id of user(AR). And at UI component fetch user with id(Total Request from UI=2)
Both of them are OK. The decision is based on how you map the concepts between different boundary contexts. The patterns are:
Anticorruption Layer
Shared Kernel
Open Host Service(option 2)
Separate Ways
Customer Supplier
Conformist
Partenership
Published Language
...
It is not only the personal preference, but also about the organization structure(The Conway's Law).
If both the two contexts(post and user) are controlled by your team, you could choose either of them. Considering the complexity of the option 1, I prefer option 2 since it's very straight. Start from the easier one then involve your architecture is always a good idea.
The timeSeries resource represents a container for data instances and timeSeriesInstance resource represents a data instance in the resource.
The main difference from container and contentInstance is to keep the time information with data and to be able to detect the missing data.
Is there any other advantage which can be achieved using timeSeries and timeSeriesInstance resource instead of container and contentInstance resources?
Does it also help in saving data redundancy e.g. if my one application instance is sending data every 30 seconds so in a day 24*120 contentInstance will be created.
If timeSeries and timeSeriesInstance resources are being used then will the same number of timeSeriesInstance be created in a day (i.e. 24*120) for the above case?
Also, is there any specific purpose for keeping contentInfo attribute in timeSeries instead of timeSeriesInstance (like we have contentInfo in contentInstance resource)
There are a couple of differences between the <container> and <timeSeries> resource types.
A <container> resource may contain an arbitrary number of <contentInstance> resources as well as <flexContainer> and (sub) <container> resources as child resources. The advantage of this is that a <container> can be further structured to represent more complex data types.
This is also the reason why the contentInfo attribute cannot be part of the <container> resource, because the type of the content can just be mixed, or the <container> resource my not have direct <contentInstance> resources at all.
A <timeSeries> resource can only have <timeSeriesInstance> resources as a child resource (except from <subscription>, <oldest>, <latest> etc). It is assumed that all the child <timeSeriesInstance> resources are of the same type, therefore the contentInfo is located in the <timeSeries> resource.
<timeSeriesInstance> resources may also have a sequenceNr attribute which allows the CSE to check for missing or out-of-sequence data. See, for example, the missingDataDetect attribute in the <timeSeries> resource.
For your application (sending and storing data every 30 seconds): It depends on the requirements. Is it important that measurements are transmitted all the time, or when it is important to know when data is missing? Then use <timeSeries> and <timeSeriesInstances>. If your application just sends data when the measurement changes and it is only important to retrieve the latest value, then use <container> and <contentInstance>.
Two uses cases for <timeSeries> that seem better to me than using a <container>.
The first use case involves the dataGenerationTime attribute. This allows a sensor to specifically record the time that a sensor value was captured, whereas with a <contentInstance> you have the creation time (you could put the capture time into the content attribute, but then that requires additional processing to extract from the content). If you use the creationtime attribute of the <contentInstance> there will be variations in the time based on when the CSE receives the primitive. When using the <timeSeriesInstance> the variations go away because the CREATE request includes the dataGenerationTime attribute. That makes the data more accurate.
The second use case involves the missingDataDetect attribute. In short, using this, along with the expected periodicInterval you can implement a "heartbeat" type functionality for your sensor. If the sensor does not send a measurement indicating that the door is closed/open every 30 seconds, a notification can be sent indicating that the sensor is malfunctioning or tampered with.
I read documentation for making two way communication in OneM2M. I understand that one way of doing that is using subscription and notification system. Lets assume we have an example like the figure below. IN-AE (Smartphone) wants to open the light of ADN-AE2. Assume that registration and resource creations are already done and also ADN-AE-2 is already subscribed to the container of a light in ADN-AE-2.
As a result, oneM2M covers the part of how IN-AE sends the light control request and how ADN-AE-2 or ADN-AE-1 took the request that comes from IN-AE and execute it. But what if ADN-AE-2 cannot control the light and fail while controlling it. What should be the scenario ? The contentinstance is already created with the request sent by IN-AE.
1- Should ADN-AE-2 create another contentinstance that is previous state of the container
2- Should ADN-AE-2 remove the contentinstance that is not executed (then what about other subscribers that take the notification and execute it successfuly)
What should be the recommended way if the actuator cannot do the action ?
http://www.onem2m.org/tr-0034/procedures/actuator-switch-control
This is a general problem in asynchronous communication. What happens when the receiver never receives a command, or is just not able to execute it (for whatever reasons, for example it is busy doing other things or the request is outside certain parameters)?
Both your options are valid, but won't work when the ADN is offline, so that the ADN-AE2 cannot perform the procedures. Also, even when the ADN is always online, both procedures have problems when there are more than one other AE that wants to control the ADN-AE2, or when the IN-AE is impatiently setting the desired state again and again. This often might result in race conditions.
I would suggest to re-think the communication scheme between the two AE's and split the original Container into two: one Container for the target state, and another Container for the status state. The target Container is used by AE's, other than the ADN-AE2, to set a desired state. The ADN-AE2 is notified of the creation of a new ContentInstance and acts accordingly. It then creates a new ContentInstance in the state container that reflects the new internal state, and this will notify the IN-AE to reflect the change.
The following drawing reflects an example resource structure for this pattern:
AE ─┬─ Container_target ─── ContentInstances* ◀═══ Container for desired state, set by other AEs
│
└─ Container_state ─── ContentInstances* ◀═══ Container for actual state, set only by this AE
This is a common pattern in asynchronous communication when the connectivity between nodes is not always reliable, or when the outcome of a state-change request is not always guaranteed. The responsibility for executing requests lies with the ADN-AE2, the policy for how often to retry or react on failure lies with the IN-AE.
I am thinking about something what is connected a little bit with CQRS. There is a pattern Request-Reply. In example of HTTP transport into header we put Request-Id for at least tracking purposes. In my case monitoring between different microservices. If incoming request contains it than rewrite is done to Correlation-Id header. As I think this is done on transport layer (infrastructure). Question is if that Request-Id (sometimes named as Message-Id) should be delivered from business layer in example directly from command that we are executing - some mechinics does this auto-magically - like ICommand requires that Id is present?
Or it's totally different thing that exists only in infrastructure layer (transport)? If yes, than how to correlate transport id with business command id? At least one log/trace/track thing has to be placed with both identifiers? Is there pattenr that I missed? Moreover what you think CorrelationId should be in business command or not?
IMHO concepts such as correlation id, causation id, request id, message id, etc belong to the infrastructure layer as they are not part of the business rules.
However, I've added a metadata attribute to my Command and Event objects to save this kind of info which helps me to manage the correlation and causation relationship between commands and events.
By having this metadata attribute in the form of an associative array (hash map, dictionary or whatever key-value format), you leave your code opened to persist any tracking info you may need in the future without polluting your Application and Domain layers too much.