This topic describes how to add endpoint binding dependencies to your widget definitions. Endpoint bindings are used to resolve URLs dynamically at runtime in order to prevent end users from getting connection errors when the service is unavailable. Endpoint bindings are also useful when administrators want to change the connection information for a widget without having to modify the metadata of the widget.
When developing widgets, sometimes you may want to define endpoint binding dependencies for services instead of hard coding static URLs to them in catalog.xml, the widget definition file that is packaged with the widget. For example, you might be creating a widget that displays a calendar by connecting to a server where a calendar service is located. You cannot always guarantee that the service will be available. You also know that the administrator may change to a different server in the future. You can create an endpoint binding dependency in your widget's definition file so that the administrator can have control over the connection information without having to modify the widget's metadata.
In order to make use of endpoint bindings, administrators must create a configuration file that maps the dependencies that you define to a specific URL. You can either provide the schema for the XML file in your widget package for them to use, or you can describe how to create the schema in your widget readme file.
Note: This topic only describes how widget developers can create endpoint binding dependencies. For information about how an administrator handles endpoint bindings on the Mashup Center server, see ../com.ibm.help.mashups.admin.doc/mash_admin_endpoint.htm.
Understanding the syntax for endpoint binding dependencies
In simple terms, the syntax for an endpoint binding dependency looks like this:
endpoint://<endpoint_ID>/<relative URL>
The syntax always starts with
endpoint:// followed by an ID and a relative path to the service.
The
<endpoint_ID> value is an ID that Mashup Center uses to find and replace the value. Typically, this replacement value is a URL that is defined by an administrator in a configuration file on the Mashup Center server. For example, you might define an endpoint binding dependency ID as
ID1, and the administrator has defined the endpoint binding value as
http://www.ibm.com in the configuration file. Now, at runtime,
ID1 gets replaced with
http://www.ibm.com. At a later time, if the administrator decides that the widget should connect to a different URL, he simply needs to update the configuration file and not the metadata of the widget.
Note: When creating IDs for endpoint dependencies, always make sure that the ID is unique. Also, since administrators are using your IDs in their configuration tasks, be sure to create meaningful IDs that are easy to interpret.
Next, the
<relative URL> value is the remaining part of the information needed for connecting to the service. For example, if the
<endpoint_ID> value resolves to
http://www.ibm.com at runtime, and the
<relative URL> value is
software, the widget will connect to
http://www.ibm.com/software at runtime.