There are two kinds of PowerLinks: Deployable Components and web services. Deployable Components are deployed to each application server and become part of the Learning System application when installed. Web Services are able to connect remotely to the Learning System to access, add, modify, and remove data in the Learning System.
The Deployable Component Framework lets developers create custom components that can be integrated with the application server. The Deployable Components Framework consists the Authentication Framework and the System Integration Framework. When developing a deployable component, the developer creates a class that extends one of the DCF's base classes and writes the custom implementation code. Next, the developer defines the deployable component's settings in an XML configuration file named DeployableComponentConfig.xml. The class(es) and the configuration file are then packaged in a .jar file and delivered to the server administrator for deployment. Any other resources required by the deployable component (such as properties files) should also be packaged in the .jar file.
Each deployable component has its own class loader. This means that deployable components can use
different versions of the same library without the risk of conflicts.
The SDK also includes a set of Java classes that form a wrapper around a SOAP interface. This allows
developers to write Java applications that call the web services APIs without having to deal with the
intricacies of SOAP. The web services provide software developers with the means to programmatically access core functionality while shielding them from the complexities of the underlying Learning System application framework.
PowerLinks that use web services must connect to the Learning System as users and therefore are subject to the same authentication and authorization procedures as when the user logs into the Learning System through the GUI. Web services-based applications do not have any special privileges nor do they have access to any administrative functionality or resources other than what is allowed by the session user's permissions.
A web services client application invokes a method that generates a web service request. The request is
converted into a SOAP message (serialized and HTTP-encoded) and transmitted to the SOAP server via
HTTP. The SOAP server provides several proxy classes for handling the various web service requests.
The SOAP message is passed to the appropriate proxy class, which then sends a request to the appropriate
SDK EJB. In turn, the SDK EJB forwards the request to the appropriate Learning System EJB. The Learning System EJB may process the request itself or it may pass the request on to the core application. Once the
request is processed, any results that need to be sent back to the client follow the same path backward and deserialized into a form that is appropriate for the client.
The developer is only concerned with the client-side implementation code that generates the web service
requests. Everything else is handled by the Learning System and the web services framework.