SOA GUIs

Goal

The goal of the SOA GUI is to allow true reuse of code also in terms of UI flows which are -not- bound to page flows only.

See "The SOA GUI workflows" for details, and example code for this demo

Service definition

1. define a service descriptor in the config.xml file of your service:

 <bean class="ch.goodsolutions.services.user.UserSearchServiceDescriptor" 
	init-method="init" singleton="true">
	<property name="serviceRegistry">
	      <ref bean="org.olat.core.service.ServiceRegistry" />
	</property>
 </bean>

Lookup of a Service

To lookup and use a service from withing your code:

1. lookup the service and cast it to the service interface

 UserSearchUIService searchUIService = (UserSearchUIService) ServiceFactory.getService(UserSearchUIService.class);

2. prepare all arguments and let the controller create

 searchController = searchUIService.createUserSearchController(ureq, getWindowControl(), /*listener*/ this, false, false);			

3. plug the initial view into your screen at the place you wish

 contentPanel_A.setContent(searchController.getInitialComponent());

Events from a Service

When you e.g. use a user search service, you want to know one things only: be notified when something interesting is happening

For a user search service, the only interesting things that can happen are a) the logged-in-user chose a user, and b) the user cancelled the user search.

The service should tell me what happened by hiding any details to me.

51   protected void event(UserRequest ureq, Controller source, Event event) {
52     if (source == searchController) {
53       // 1. get the user search service
54       UserSearchUIService searchUIService = (UserSearchUIService) ServiceFactory.getService(UserSearchUIService.class);
55       User user = searchUIService.getChosenUser(event);
56       if (user != null) {
57         // the user chose a user
58         showInfo("user.chosen", user.getIdentity().getName());
59       } // else user cancelled user search
         // do other things here
63     }
64   }
The key point is at line 55 where we receive an event which we just pass back to the service for "translation" into the business language.

A service loads all its resources automatically and is autowired with Spring when Brasato starts up. A service can be packaged into a jar and easily deployed by simple putting the .jar file into the "libs" directory.

An application can thus pick the services it needs for deployment, and only deploy those jars. OSGI integration for services is on the roadmap