The next las2peer release focuses on stability and usability. The service deployment is simplified and improved. Starting with las2peer 0.7 a service developer packs all service classes and dependencies into a usual jar. This jar is called fat-jar.

To deploy the service this fat jar is uploaded to the network. To upload a service jar the developer has two options:

First you can use the L2pNodeLauncher and add a command to upload your jar, like:

java -jar las2peer-0.7.0.jar --bootstrap deployment.network.url:port uploadServicePackage('i5.las2peer.services.fileService-2.0.jar', 'agent-developer.xml', 'developer-password')

Second you can use the NodeAdminConnector frontend:

The agent used to upload the service becomes the service owner. Afterwards only this agent is allowed to change the service. After uploading the service can be started on any node attached to the network, just by calling:

startService(‘i5.las2peer.services.fileService.FileService@2.0’, ‘secretpass’)

To execute the service the class loader loads all necessary classes from the network.

Technical Details: How does it work?

• developer builds and tests service
• packs the full service including it’s deps like JSON lib, or apache-commons-io lib into a single jar, called fat jar
• uploads the fat jar to a las2peer network
• at the upload node the jar is unpacked and a each file is hashed with a secure hash
• this gives a list of all classes and their hashes required or included in this service
• afterwards each class is uploaded to the network identified by their hash

 FileService.class 0898230948901283094810923...
 StoredFile.class 9380948120938409182093412...
 StoredFileIndex.class 1923809182903481092380948...
 ...

With this method no file is duplicated. The hash is unique for the content. Any other developer, who uses the same file from the same lib in his service, also has the same hash on uploading. In this case las2peer recognizes the same hashes and does not duplicate the file.

Furthermore this is a strong security feature. The developer specifies the exact class and it’s content by giving the secure hash. An attacker can not overwrite the classes with malicious ones.

Last but not least this feature gives good stability, because a service is always executed with the exact library the developer tested it with. The version and even stronger the file content matching is exact and has no tolerances. In case of updates the service developer just generates a new jar with a new version number and uploads it to the network again.

Future Plans

Our plan for the future is to automatize the service execution. This way a service is once deployed and is always available in the network.The service  does not have to be started by hand anymore.

Furthermore we plan to integrate a simple API checking for new service versions. This could help to achieve that RMI calls still work and version number changes are made correctly.