Best Practices PreviousNext
Data Distribution Service (DDS) Forum > DDS FAQ >
Message/Author
Next message Sachin  posted on Wednesday, June 17, 2009 - 05:08 pm
hi Hans,
can you please tell me where i can find best practices for openSplice DDS?

Regards,
Sachin
Next message Hans van 't Hag  posted on Thursday, June 18, 2009 - 12:44 pm
Hi Sachin,

thats a very 'wide' question as practices related to OpenSplice DDS can cover system-design, information-modeling, application-design, target-configuration, deployment types, etc.

Typically 'best-practices' are part of courses that we can provide.

Nevertheless, please check-out www.opensplice.com where under the resource-center(home->Opensplice->Resources) you can find numerous whitepapers, webinars as well as links to our OpenSpliceTube YouTube videos.

Good luck,
Hans
Next message Sachin  posted on Thursday, June 18, 2009 - 03:14 pm
Hi Hans,

Thanks
Regards, Sachin
Next message Sachin  posted on Wednesday, December 16, 2009 - 03:30 pm
Hi,
can anybody please explain me how exactly we will combine the received topics in our application to make a complete structure for our use.The problem is that the topics that are going to be used to make complete structure will be received at different time and in different methods(say listener)?
How will i come to know that my structure is completely filled i.e. all topics have been copied to structure?

Thanks,
Sachin
Next message Sachin  posted on Wednesday, January 06, 2010 - 03:17 pm
Hi,
can anybody please explain me how exactly we will combine the received topics in our application to make a complete structure for our use.The problem is that the topics that are going to be used to make complete structure will be received at different time and in different methods(say listener)?
How will i come to know that my structure is completely filled i.e. all topics have been copied to structure?

Thanks,
Sachin
Next message Erik Hendriks  posted on Friday, January 08, 2010 - 12:45 pm
Hi Yogesh,

Applications that communicate using DDS must agree upon a number of things in order to communicate successfully:

1) They must agree on a common information model.
2) they must agree on the QoS that is used to communicate this information.

So if Application A wants to communicate some information to Application B, and application A chops up this piece of information into separate topics (for example because the different parts of this information have different update frequencies and can therefore be transmitted using different QoS policies), Application B needs to know exactly which topics make up this piece of information and which Qos policy values are applied to them. It needs this information to create the correct subscriptions on the correct topics, and to 're-assemble' the original piece of information from the separate topics.

If indeed the different parts if this piece of information have different update frequencies, then the re-assembly process is not a single step action: incoming information should continuously be evaluated, and applied to the correct location in your information model. This re-assembly process is part of your Business Logic, and for OO-languages is typically abstracted into a number of Domain specific classes that have relationships to one-another.

Of course you can write your own Business Logic to translate Object Relationships into key-values for your topic model (in the Relational Database world this is often referred to as Object-to-Relational mapping), and then write these individual topics into DDS. You would then need to make similar Business Objects on the receiving side, that translate the relationships based on key-values in your topic model back into Object relationships in your Object Model.

When using only DCPS, writing the Business logic to do the Object-to-Relational mapping (and the way back) may be quite some effort. DCPS does offer you some helpful tools to build this logic (e.g. For solving a relationship based on a foreign key, you can use a Query to lookup the referenced instance by key value). But the DDS specification offers much more dedicated mechanisms for this purpose that operate on a much higher abstraction layer: the Data Local Reconstruction Layer (DLRL).

In the DLRL, you specify both the Object Model and the Relational (= Topic) Model explicitly, and you also specify the Object to Relational Mapping by means of an XML file. In this file you can specify for example that Class A maps onto Topic 'Atopic', and that an attribute A::myB (which is a relationship to class B) maps onto a foreign key in topic A. Likewise the Class B could be mapped onto a Topic 'Btopic', of which the key type complies with the foreign key in 'Atopic'.

The DLRL will then automatically manage these relationships for you: if you change a relationship between Objects, the DLRL will write a new foreign key value in the topic that contains the corresponding foreign key. The receiving side will notice this new topic sample, will interpret its change in foreign key field and will modify the corresponding Object Relationship likewise. It offers you very dedicated Listeners that can inform you about Object creation/modification/deletion, and that can also inform you when a particular object relationship has changed. When one Object has a relationship to another Object which has not yet been received, the relationship is not navigable yet. The DLRL will inform you when that relationship becomes navigable.

On this abstraction level, it is much easier to write your own Business Logic that allows you to act on incoming data. Building a Business Object that notifies you when all its relationships have become navigable (so that your Business Object can be considered 'complete') is very easy that way.

Hope this answers your question.

Regards,
Erik Hendriks.
Back to top
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Post as "Anonymous"
Enable HTML code in message
Automatically activate URLs in message
Action: