Overview

Integrating applications into the Ratchet-X platform serves little purpose unless you have plug-ins to act on an integrated application’s data. Simply put, plug-ins are the reasons you use Ratchet-X in the first place because they provide the functions you want to add to existing applications. Plug-ins are developed in your programming language of choice using the Ratchet-X Plug-in SDK.

 

The Ratchet-X Plug-in SDK consists of the following components:

  • Application Programmer Interface (API documentation)
  • RXDL Editor And Test Harness (REATH)
  • XModel Editor
  • Registry Editor

Before we dive into the details of the SDK’s subordinate components and the process of building plug-ins, let’s first take a high-level look at the Ratchet-X Plug-in architecture. For a review of the Ratchet-X framework architecture, click here.

 

Ratchet-X Plug-in Architecture

As mentioned above, plug-ins perform the functions users add to existing applications. Plug-ins are created using your programming language of choice and are registered by the user with the Ratchet Commander. Once registered with Commander, plug-ins that reference the same XModels as an appspace are be made available to the user at runtime for execution from within his application.

 

For example, if you want to create a plug-in that checks to see if a phone number on you application screen is on a national do not call list, you must create a plug-in that contains the following:

  • The screens the user sees that guides him/her through the process of checking the phone number. Think of these screens as a wizard that provides whatever guidance you feel is appropriate for the user to properly execute your plug-in. In the case of checking a phone number, the user experience could range from having no user interface other than returning the do not call status of the number, through a complex interface that allows the user to add the number to a private do not call list or an exclusion list. The look and feel of this experience is under your total control so it can look and perform any way you feel is appropriate.

    •  

  • An “XModel element” that conforms to a universally understood semantic definition of a phone number. Don’t worry about understanding XModels too much at this point because they are covered in significant detail elsewhere in this guide. For now, think of an XModel as a schema of data or a microformat that lets appspaces know that your plug-in can process data that conforms to the definition of a phone number. XModels are created using the Ratchet-X XModel Editor.

Once a plug-in is created and tagged with the appropriate XModel and elements, you then must generate a RXDL file that describes the plug-in. RXDL, (short for Ratchet-X Description Language), is an XML file that describes a number of different attributes of the plug-in including its name, description, invocation address (URL) and associated XModels. The RXDL fulfills the same role that a WSDL does with regard to a web service. So, if you understand how WSDL relates to SOAP-based web services, then you conceptually understand the role of a RXDL.

 

After the RXDL is generated, the plug-in code is made available at the invocation address contained within the RXDL and a link to the RXDL is made available to any user that wants to integrate the plug-in into his applications. Once registered within Commander, the plug-in can be executed from any application screen that is contained within a registered appspace that supports the XModels supported by the plug-in.

 

So, if a user registers an appspace that contains a screen that references the phone number XModel described above, a do not call alert will be automatically generated every time the user navigates to the application screen. Once the alert is generated in the alert window, the user can click on the alert and perform the do not call check. It’s that simple.

 

Plug-in Development Process

Although there is no hard and fast rule regarding how to build a plug-in, the following process defines the most common plug-in development path and is considered a best practice.
PlugInProcess

The remainder of this help guide will center around the creation of plug-ins using this process and delve into the details of supporting topics where appropriate..

© Copyright 2008, RatchetSoft, LLC