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 -->
 <mix name="Client">
   <service name="Subr" 
     provision="subr">
     <prop name="subr.import"
       user="some@domain.com"
       key="any_key"/>
   </service>
   ...
   <request name="myOperation"  
     service="Subr">
     ...
   </request>
 </mix>

<!-- SERVER SIDE (user some@domain.com) -->
 <mix name="Server">
   <service name="Subr2" 
     provision="subr">
     <prop name="subr.export"
       key="any_key"/>
   </service>
   ...
   <solicit name="myOperation" 
     clients="Subr2">
     ... 
   </solicit>
 </mix>
 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.