RegistryGraphMessagingContainerFactory

This is a useful [messaging container factory](messaging container factories) that uses an XDI graph from the xdi2-core component as a basis to decide what [messaging containers](messaging containers) to create on the XDI server. Every peer root node in this "registry graph" becomes a messaging container. Like any other graph, the "registry graph" can be stored in any of the [supported backend stores](Available backend storage for XDI graphs), and it can itself be mounted as a messaging container, which effectively makes it possible to provision and remove messaging containers at runtime.

Interfaces and Classes

• xdi2.transport.impl.http.factory.RegistryGraphMessagingContainerFactory

Properties

• prototypeMessagingContainer: A [messaging container](messaging containers) to be used as a prototype for new messaging containers that are created.
• registryGraph: The XDI graph to use to determine what messaging containers to create.

Example Configuration

The following configuration sets up the RegistryGraphMessagingContainerFactory at the relative path /users/*:

<!-- MESSAGING CONTAINER FACTORY at /users/* -->

<bean id="registryGraphFactory" class="xdi2.core.impl.wrapped.file.FileGraphFactory">
	<property name="path" value="registry.xdi" />
	<property name="mimeType" value="text/xdi;ordered=1" />
</bean>

<bean id="registryGraph" factory-bean="registryGraphFactory" factory-method="openGraph" />

<bean name="/users/*" class="xdi2.server.factory.impl.RegistryGraphMessagingContainerFactory">
	<property name="prototypeMessagingContainer" ref="prototypeMessagingContainer" />
	<property name="registryGraph" ref="registryGraph" />
</bean>

It references a "prototype messaging container" which is used as a template for instantiating new messaging containers:

<!-- MESSAGING CONTAINER TO BE USED AS A PROTOTYPE FOR MESSAGING CONTAINER FACTORIES -->

<bean id="prototypeGraphFactory" class="xdi2.core.impl.memory.MemoryGraphFactory">
</bean>

<bean id="prototypeGraph" factory-bean="prototypeGraphFactory" factory-method="openGraph" />

<bean id="prototypeMessagingContainer" class="xdi2.messaging.container.impl.graph.GraphMessagingContainer">
	<property name="graph" ref="prototypeGraph" />
	<property name="interceptors">
		<util:list>
			<bean class="xdi2.messaging.container.interceptor.impl.BootstrapInterceptor">
				<property name="bootstrapLinkContract" value="true" />
				<property name="bootstrapPublicLinkContract" value="true" />
			</bean>
			<bean class="xdi2.messaging.container.interceptor.impl.RefInterceptor" />
			<bean class="xdi2.messaging.container.interceptor.impl.ToInterceptor" />
			<bean class="xdi2.messaging.container.interceptor.impl.authentication.secrettoken.AuthenticationSecretTokenInterceptor">
				<property name="secretTokenAuthenticator">
					<bean class="xdi2.messaging.container.interceptor.impl.authentication.secrettoken.GraphSecretTokenAuthenticator">
						<property name="globalSalt" value="00000000-0000-0000-0000-000000000000" />
						<property name="secretTokenGraph" ref="registryGraph" />
					</bean>
				</property>
			</bean>
			<bean class="xdi2.messaging.container.interceptor.impl.linkcontract.LinkContractInterceptor" />
		</util:list>
	</property>
</bean>

Note that since this messaging container factory uses a special "registry graph", that graph can of course also be exposed as a messaging container and therefore modified through XDI messaging. Also not that, for the purpose of authentication, the "registry graph" also serves as the "secret token graph" of the AuthenticationSecretTokenInterceptor.

The following configuration sets up an XDI endpoint for the registry graph at the relative path /registry:

<!-- REGISTRY MESSAGING CONTAINER -->

<bean name="/registry" class="xdi2.messaging.container.impl.graph.GraphMessagingContainer">
	<property name="graph" ref="registrygraph" />
	<property name="interceptors">
		<util:list>
			<bean class="xdi2.messaging.container.interceptor.impl.BootstrapInterceptor">
				<property name="bootstrapOwner" value="+!:uuid:9999" />
				<property name="bootstrapOwnerSynonyms">
					<util:list>
						<value>+testcsp</value>
					</util:list>
				</property>
				<property name="bootstrapLinkContract" value="true" />
				<property name="bootstrapPublicLinkContract" value="true" />
			</bean>
			<bean class="xdi2.messaging.container.interceptor.impl.RefInterceptor" />
			<bean class="xdi2.messaging.container.interceptor.impl.ToInterceptor" />
			<bean class="xdi2.messaging.container.interceptor.impl.authentication.secrettoken.AuthenticationSecretTokenInterceptor">
				<property name="secretTokenAuthenticator">
					<bean class="xdi2.messaging.container.interceptor.impl.authentication.secrettoken.StaticSecretTokenAuthenticator">
						<property name="globalSalt" value="00000000-0000-0000-0000-000000000000" />
						<property name="localSaltAndDigestSecretTokens">
							<util:map>
								<entry key="+!:uuid:9999" value="xdi2-digest:00000000-0000-0000-0000-000000000000:a7292f2347aef29a9e4c05d35764019106143a339b6e9bb39faee53103e1d6f55e49213d77d16a326a91bab0fc6885779d04e2e4470125720860cf54f872b3bb" />
							</util:map>
						</property>
					</bean>
				</property>
			</bean>
			<bean class="xdi2.messaging.container.interceptor.impl.LinkContractInterceptor" />
		</util:list>
	</property>
</bean>

Adding a new messaging container to the registry

With the above configuration in place, an XDI client could send an XDI message like the following to add a peer root to the registry graph, which effectively instantiates a new messaging container:

+!:uuid:9999[$msg]!:uuid:1234/$is()/(+!:uuid:9999)
+!:uuid:9999[$msg]!:uuid:1234/$do/(+!:uuid:9999/+!:uuid:9999)$do
+!:uuid:9999[$msg]!:uuid:1234<$secret><$token>&/&/"cspsecret"
(+!:uuid:9999[$msg]!:uuid:1234$do/$set)(=alice)/$ref/(=!:uuid:1111)
(+!:uuid:9999[$msg]!:uuid:1234$do/$set)(=!:uuid:1111)/$is$ref/(=alice)
(+!:uuid:9999[$msg]!:uuid:1234$do/$do&<$digest><$secret><$token>)(=!:uuid:1111)<$digest><$secret><$token>&/&/"alicesecret"

Testing the new messaging container

The new messaging container then becomes available at the relative path /users/=!:uuid:1111 and is initialized with a BootstrapInterceptor. It could be tested with a message like the following:

=!:uuid:1111[$msg]@~1/$from/(=!:uuid:1111)
=!:uuid:1111[$msg]@~1/$to/(=!:uuid:1111)
=!:uuid:1111[$msg]@~1/$contract/(=!:uuid:1111/=!:uuid:1111)$contract
=!:uuid:1111[$msg]@~1<$secret><$token>&/&/"alicesecret"
=!:uuid:1111[$msg]@~1$do/$get/

Removing a messaging container from the registry

An XDI client can also send an XDI message to remove a peer root from the registry graph, which effectively removes the corresponding messaging container:

+!:uuid:9999[$msg]*!:uuid:1234/$from/(+!:uuid:9999)
+!:uuid:9999[$msg]*!:uuid:1234/$to/(+!:uuid:9999)
+!:uuid:9999[$msg]*!:uuid:1234/$contract/(+!:uuid:9999/+!:uuid:9999)$contract
+!:uuid:9999[$msg]*!:uuid:1234<$secret><$token>/&/"cspsecret"
+!:uuid:9999[$msg]*!:uuid:1234$do/$del/(=!:uuid:1111)
+!:uuid:9999[$msg]*!:uuid:1234$do/$del/(=alice)

After this, the messaging container at the relative path /users/=!:uuid:1111 no longer exists, and the server would return an HTTP 404 error.