Contents: Administering Mashup Center : Mashup Center 2.0
This topic describes how to create configuration XML files that map a widget's endpoint binding dependencies to URLs. 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 you want to change the connection information for a widget without having to modify the widget's metadata.

First, before we describe how to handle endpoint binding dependencies on the Mashup Center server, let's understand why developers create these dependencies in the first place.

When creating widgets, widget developers 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, let's say a developer is creating a widget that displays a calendar by connecting to a server where a calendar service is located. The developer cannot always guarantee that the service will be available. Also, the developer knows that you, the administrator, may want the widget to connect to a different server in the future. The developer can create an endpoint binding dependency in your widget's definition file so that you can have control over the connection information without having to modify the widget's metadata.

In simple terms, the syntax for an endpoint binding dependency in catalog.xml 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.

These are the tags that support endpoint bindings in catalog.xml:

<definition>

<content>

<preview>

<icon>

<previewThumbnail>

<help>

Here is an example:

<definition>endpoint://ID1/widgets/widgetdef.xml </definition>

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 you define in a configuration file on the Mashup Center server. For example, the developer may define an endpoint binding dependency ID as ID1, and you may define 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 you decide that the widget should connect to a different URL, you can simply update the configuration file and not the widget's metadata.

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.

Creating the configuration file for mapping ID

Typically, widget developers will either package the XML schema for mapping endpoint IDs in the widget package, or they will provide instructions in the readme file. If the developer does not include the schema or readme information, you can always open catalog.xml and see if any endpoint binding dependencies are defined. The main piece of information that you must gather from catalog.xml is the ID that is described above.

Here is an example of a configuration file that you can create to map URLs to endpoint binding dependencies:

Note: The file takes the value of -DendpointBindingDirectoryName={} and tacks it onto the installation root. So, if you installed to C:\IBM and -DendpointBindingDirectoryName=sample then you will look for the files in C:\IBM\sample.

<?xml version="1.0" encoding="UTF-8"?>

<endpoints:EndpointsRegistry

xmlns:endpoints="http://com.ibm.mashups/EndpointsRegistry">

<endpoints:endpoint>

<endpoints:id>

testEndpoint1

</endpoints:id>

<endpoints:type>

testEndpoint1

</endpoints:type>

<endpoints:version>

1.0.0.0

</endpoints:version>

<endpoints:url>

http://www.ibm.com

</endpoints:url>

<endpoints:description>

A meaningless test endpoint with absolute url

</endpoints:description>

</endpoints:endpoint>

<endpoints:endpoint>

<endpoints:id>

testEndpoint2

</endpoints:id>

<endpoints:type>

testEndpoint2

</endpoints:type>

<endpoints:version>

1.0.0.0

</endpoints:version>

<endpoints:url>

/endpoint

</endpoints:url>

<endpoints:description>

A meaningless test endpoint with relative url

</endpoints:description>

</endpoints:endpoint>

</endpoints:EndpointsRegistry>

Notice how the ID testEndpoint1 is defined in the configuration file:

<endpoints:id>

testEndpoint1

</endpoints:id>

Now notice how the administrator has mapped the testEndpoint1 ID to http://www.ibm.com in the file:

<endpoints:url>

http://www.ibm.com

</endpoints:url>

When an end user tries connecting to the resource at runtime, Mashup Center will recognize the endpoint ID testEndpoint1 in catalog.xml, locate your configuration file, replace the ID defined in the dependency with http://www.ibm.com, append the relative URL, if it exists, and finally connect to the resource.

Running the configuration task to move the XML into WebSphere Application Server WCCM

In order to move the XML that you configured to map the ID of the endpoint binding dependency to a URL to WCCM, run the following command:

config.bat mashup-admin-command-load-endpoint

-DendpointBindingDirectoryName={} -Dclean={true/false}

Notice that the command contains the following two parameters: -DendpointBindingDirectoryName={} and -Dclean={true/false}. The -DendpointBindingDirectoryName={} parameter refers to the directory that contains the configuration file that you created above. The -Dclean={true/false} parameter tells Mashup Center how to handle endpoints that have been previously configured for the widget. The default setting is true, which means that all previous endpoint bindings are deleted and only the new ones are recognized.