First Steps

Step 1: Implement the Callback Interfaces

One has to implement the following interfaces:

• at.ac.tuwien.dsg.smartcom.callback.PeerAuthenticationCallback
• at.ac.tuwien.dsg.smartcom.callback.PeerInfoCallback
• at.ac.tuwien.dsg.smartcom.callback.CollectiveInfoCallback

Those interfaces are required by SmartCom to provide peer and collective functionality because the middleware does not save any data belonging to a peer or a collective. This has to be provided by implementing those interfaces. A demo implementation can be found here: DemoPeerManager.java

---

Step 2: Implement Output Adapters

Output Adapters are responsible for the transformation of normalized messages to technology-related messages, and to send them to the peer. For example, a REST-Adapter transforms the internal message to JSON message and sends it via REST to the peer.

These adapters have to implement the interface at.ac.tuwien.dsg.smartcom.adapter.OutputAdapter and have to be annotated with @Adapter(name="ADAPTER_NAME", stateful=TRUE/FALSE). The adapter name defines the unique name of the adapter and the parameter stateful indicates if there should be one instance per peer or one instance shared among all peers. The name will also correspond the the type of the communication channel that will be explained in Step 6.

---

Step 3: Implement Input Adapters

Input Adapters are responsible for the collection of input messages from peers or tools (e.g., a Dropbox folder). If these adapters are notified via push, they have to extend the class at.ac.tuwien.dsg.smartcom.adapter.InputPushAdapter. If they have to actively pull for new input, they have to implement the class at.ac.tuwien.dsg.smartcom.adapter.InputPullAdapter.

---

Step 4: Start Smartcom

SmartCom can be started by instatiating the class at.ac.tuwien.dsg.smartcom.SmartComBuilder and providing the callback interfaces that have been created in Step 1. This class provides some methods to configure SmartCom before starting it (e.g., setting the port for the REST API or the Mongo Database). By calling SmartComBuilder#create() an instance of at.ac.tuwien.dsg.smartcom.SmartCom will be created and initialised, finally the method returns the newly created and already initialised instance of Smartcom. The prototype already provides a predefined set of Output Adapters which will be registered by calling this method; to prohibit this behaviour and initialize SmartCom without the default adapters, one has to call SmartCom#initializeSmartComWithoutAdapters(). A call to SmartCom#getCommunication() will return the interface at.ac.tuwien.dsg.smartcom.Communication that should be used for the primary interaction with the system.

depreciated method:
SmartCom can be started by instantiating the class at.ac.tuwien.dsg.smartcom.SmartCom and providing the callback interfaces that have been created in Step 1. The system will be initialized by calling SmartCom#initializeSmartCom() on the newly created instance of SmartCom.

---

Step 5: Register and add adapters

The Output Adapters that have been created in step 2 have to be registered by calling Communication#registerOutputAdapter(Class<? extends OutputAdapter>). This adapter is now available for all peers. Note that they are instantiated by the Middleware on demand rather than by the user of the system. Input Push Adapter instances can be added by calling Communication#addPushAdapter(InputPushAdapter). Input Pull Adapter instances can be added by either calling Communication#addPullAdapter(InputPullAdapter,long) Communication#addPullAdapter(InputPullAdapter,long,boolean). The second parameter of both methods indicate the the timeout between two pull requests (will be issued by the middleware), the third parameter of the second method indicates if the adapter has to be to removed after a message has been received.

---

Step 6: Register peers

Register peers in the Manager (or any other class, depending on how Step 1 has been executed) of Step 1 by providing an instance of at.ac.tuwien.dsg.smartcom.model.PeerInfo per peer. This object contains the id of the peer, the delivery policy, some privacy policies and peer channel addresses. The delivery policy controls how messages are sent to the peer's communication channels (e.g., just to one, to all, ...), privacy policies can restrict such an behaviour (e.g., don't send messages on the weekend). Right now the most important part are the peer channel addresses (at.ac.tuwien.dsg.smartcom.model.PeerChannelAddress). They provide the contact information on a peer such as a telephone number or an email address. One or multiple instances have to be created per peer, to be able to cantact it. The constructor requires the following parameters: peer id, channel type (which corresponds to an adapter and its name created in Step 2) and a list of parameters that are required by the parameter in order to contact the peer (e.g., an email address, or an URL, username and password for a REST call).

---

Step 7: Register a notification callback and interact with the System

First one has to register a notification callback to get notifications of newly arrived input messages and other control messages (e.g., a failed delivery), this can be done by implementing the class at.ac.tuwien.dsg.smartcom.callback.NotificationCallback and providing this implementation to the Communication interface by calling Communication#registerNotificationCallback(NotificationCallback). Create a message using the builder class at.ac.tuwien.dsg.smartcom.model.Message.MessageBuilder and send it to SmartCom via the call Communication#send(Messsage).