What is a YOUnite Adaptor
...
- Get the actual YOUnite Adaptor SDK. For Java, the most common method is to use the YOUnite-provided Maven artifact. If you don't use Maven, you can optionally download the SDK library directly. <TODO Kevin: Link here to latest sdk jar file>.
- Use the following Maven configuration in your settings.xml file:
| Code Block |
|---|
<dependencies>
<dependency>
<groupId>com.younite</groupId>
<artifactId>adaptor-sdk</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
</dependencies> |
3. You also need to add Add a server to your project POM to access the YOUnite Maven Repository: <TODO KEVIN: ONCE YOUNITE MAVEN REPO IS WORKING... INSERT INFO BELOW>
| Code Block |
|---|
<repositories> <repository> <id>younite-snapshots</id> <name>younite</name> <url>https://younite.bintray.com/</url> </repository> </repositories> |
4. Once you have these configured configurations in place for your project POM, the YOUnite Adaptor SDK will be available.
...
The YOUnite Adaptor SDK aims to be a very small, easy-to-use library. As such, it has been part It is a product of the design goal to avoid depending on external libraries library dependencies as much as possible. But sometimes it is better to use well-designed and tested libraries to perform menial work than attempting to roll your own. As such, the The YOUnite Adaptor SDK depends on only one external library (: the Google Reflections library) so as to have minimal impact on integration . This minimizes the impact of integrating within existing applications that may use duplicates the same libraries, possibly of different versions. This dependency is the , causing a dependency conflict. The Google Reflections library . This library provides run-time reflection capabilities needed to find and resolve classes and methods. .
Use the following configuration in your project's pom.xml file:
| Code Block |
|---|
<dependency> <groupId>org.reflections</groupId> <artifactId>reflections</artifactId> <!-- use latest version of Reflections --> <!-- maintained here: https://github.com/ronmamo/reflections --> <version>0.9.11</version> </dependency> |
...
Once an adaptor is connected to the YOUnite DataHub through the YOUnite Message Bus, it is able to send and receive data and ops messages. However, to streamline an adaptor developers time, the SDK has a minimal configuration step so that developers can focus on the business logic their adaptor is being built for and not the inner workings of sending and receiving messages, parsing those messages, and so on. To facilitate this, the YOUnite Adaptor SDK makes use of annotations developers use to define the capabilities related to the data their adaptor can produce and/or consume. These capabilities loosely translate into a Pub/Sub configuration on the YOUnite DataHub. Essentially they indicate to the YOUnite DataHub the specific domain properties they are interested in receiving changes for, and which of their own domain properties they will push out to the YOUnite DataHub when a change occurs within the associated local service(s) the adaptor is implemented to work with or domain properties requested by the YOUnite DataHub. These local services could be direct database data, an FTP server, in-memory data, or a remote service with data. In fact, the dynamic nature of YOUnite domains leave the details to individual adaptor implementations to determine how they access and retrieve domain property data and any transformations they may want to apply to the data.
...
The integration approach may run in to another issue that sometimes arises in applications that make use of 3rd party libraries.. versioning. It is unlikely, but possible, that the integration application would have another version of the google reflections library within the classpath due to the nature of how and why the google reflections library is used (namely.. for scanning the classpath for classes with specific annotations, signatures, etc). However, that it is a possible situation, it makes this section relevant. Many developers will be aware of a term "classpath hell". This situation arises when two (or more) of the same libraries are on the application classpath usually with different versions. Often is the case where 3rd party libraries bundle a "fat jar" that include classes from yet other libraries that might also be part of other libraries. A common case is logging. Often times log4j or other logging libraries will be bundled via the "fat jar" process and that is when you can run in to runtime classpath issues. This is espeically difficult to narrow down in integrated platform envrionments like servlet and JEE containers because of the way they munge the classloader hierarchy. A telltale sign is when you start to see runtime exceptions with ClassNotFoundExceptions showing up in the logs.. and in the case of the YOUnite Adaptor SDK, it might present as if the SDK is not finding any of your annotated adaptor classes.
Examples
Here is a list of examples provided via the <portal? sdk.zip outside of maven? link to github projects??> with information on each.
TBD...