Modules pattern

A module is a foreign subroutine, where an operation calls on a solicit or notify on a different service. The other service, and the called solicit or notify this service is a client on, is in another configuration tree.

In the example in Table 1, there are two mixes in different configuration trees, with a key-based matching between the services.

Table 1. svc_subr - Modules
Example Description
<!-- CLIENT SIDE -->
<service name="Subr" 
  provision="subr">
  <prop name="subr.import"
    user="some@domain.com"
    key="any_key"/>
</service>
...
<request name="myRequest"  
  service="Subr">
  <prop name="subr.spec"/>
  ...
</request>

<!-- SERVER SIDE (user some@domain.com) -->

<service name="Subr2" 
  provision="subr">
  <prop name="subr.export"
    key="any_key"/>
</service>
...
<solicit name="mySolicit" 
  clients="Subr2">
  <prop name="subr.spec"/>
  ... 
</solicit>
The operations are identical to the ones in the Subroutines example, except for the different services.
The caller operation is supported by the Subr service, that specifies:
  • The user, some@domain.com, in whose account it looks for services with matching keys
    Important: A user can only import another user's SPARKL resources if he has execute rights.
  • The key, any_key, that a foreign service should match
The called operation is on the Subr2 client, that specifies:
  • The key, any_key, that should match the import key defined by the service supporting the caller request/reply
Note: If more than one subroutine service is exported with the same key, it is undefined which one will be matched by an import.