The focus of this overview is on building applications to deliver data from the Axeda Platform to users, from a field service technician with a wireless tablet to an executive with an iPhone. The platform supplies web services which allow you to build the full range of applications from a simple asset status through complete interactive dashboards.
What's your language?
The web services on the Axeda Platform support relatively simple environments, such as JavaScript, through RIA tools such as Flash, to full development environments and languages such as Java or C++. The result is that you can choose the tool to match your problem.
The Tutorials and Sample Applications on this site include many example clients in different languages, including some great examples of the display possibilities of Rich Internet Applications.
SOAP or REST?
Whatever your UI environment and tools, you can choose whether to communicate with the Axeda Platform using either SOAP or REST services. An important difference between these two styles of interaction is that on the Axeda Platform, the SOAP services are predefined, but you build the REST services yourself in Groovy. You can find more about how Groovy is used on the platform, including pointers to code samples, in the Groovy Scripting article.
The SOAP services are defined using WSDL, and if the language you have chosen for your application is strongly typed, it may be more convenient to use these services. They are described in the WSDL Reference Guide, with examples provided by a handful of .NET applications. There is also a WSDL tutorial providing step-by-step instructions for incorporating WSDL into your applications.
The advantage of using REST is its flexibility. It may be more convenient if:
- you prefer results returned in a particular format, such as JSON
- your language environment makes WSDL hard, such as Javascript
- you want to combine or compute data on the platform before returning a result
- you want to perform a search on the platform that is not included in the SOAP services
- you want to return several results at once, to minimize round-trips
- you want to call another web service from the platform, such as a mapping service
REST services are built on a platform feature called Scripto, which is documented in the Scripto Web Service Reference Guide. You can build a simple example of a Groovy-based service in a few minutes by following the steps in the Hello World tutorial.
Processing data on the platform
When an asset sends data to the platform, the arrival of the data is an event which can trigger a number of expression rules, depending on the exact data which arrives, which can consist of one or more alarms, location data and one or more data items. This is explained further in the articles on Expression Rules and Expression Rule Triggers.
Expression rules can, in turn, call Groovy scripts. Your application can therefore run Groovy scripts at either or both of two times:
- when data arrives on the platform
- when your application makes a web service request
An example will make this clear. Suppose you have a tracking device on a vehicle which is reporting the vehicle's speed, and you're interested in displaying the vehicle's maximum speed. One way to do this would be to write a Groovy script which ran through all the reported speed values and returned the maximum. You could write this script to be callable from a web service, which would supply the vehicle id to the script.
Another way of achieving the same result is to write a Groovy script which is run each time the vehicle reports its speed. An asset on the platform, such as a vehicle, contains the data that the real asset reports, such as speed, but the Axeda Platform also allows you to extend the definition of an asset with whatever additional variables you need. You can therefore add a data item to the vehicle to hold maximum speed, which your Groovy script can adjust whenever the vehicle reports a new speed higher than the previous maximum.
You can also add data items to your assets to collect data from your users. For example, a vending machine may be able to report its stock levels, but not when it is restocked. You could include a data item for restocking time in the vending machine asset which could be populated by the person doing the restocking.
You can find out more about these details in the article on the Data Model.
Calling other web services
In addition to calling the web services on the Axeda Platform, your application may take advantage of other cloud services to enhance your application. One simple example is to call a lookup service to translate a numeric code, such as an error code or UPC, into text. An example of this is given in the article Using Cloud Services in Rules. Another good example is using a mapping service to display your assets' locations on a map, which we demonstrate in the Get Started application.
If you are calling a web service to provide additional data for your assets, you can do that either from your client application or from the Axeda Platform. Suppose an asset reports an error code. As before, the arrival of this data on the platform can be used to trigger an Expression Rule which calls a Groovy script. The script can make a web service call to translate the error code into text and store the text in the asset.
MQ
The Axeda Platform includes support for MQ. While MQ is normally thought of as a tool for enterprise integration, it can also be used to push information to user applications. This works as follows: suppose the user has obtained information about a particular asset, and is performing some operations related to it that will take some time. During that time, it is helpful if the user always has the most current information about the asset. The application can call the platform and request a temporary MQ queue to which it can subscribe. Updates can then be pushed, using Groovy, to the user application through the queue.
