Service domains

You create a service domain by packaging your service object and implementation classes to a JAR file. The service domain name is the jar file name, naming convention is <domainName>-<version>.jar.

Service domain jars must have a file resoa.xml within the META-Info folder, a simple

<?xml version="1.0"?>
<Resoa xmlns="http://www.resoa.org/deploy" />

will meet all requirements.

Service Roles / Permissions

You can assign roles to a service class or a single service method, add an org.resoa.service.Role annotation on class or method level, i.e. @Role({“admin”, “member”}).

ResoaGateways validate service requests during runtime. Only ‘RestSession’ authorized requests can access role protected services, check the ResoaGateway chapter for more information about session management.

Add the annotation @SecureProtocol if service access should be granted to secure requests (i.e. HTTPS) only.

You can define roles and permissions also within the resoa.xml file.

><?xml version="1.0" encoding="UTF-8"?>
<Resoa xmlns="http://www.resoa.org/deploy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<!-- Define roles for access control both on class and method level -->
	<Services className="org.resoa.test.xsd.service.StudentService">
	<Executions method="store">
		<Roles>admin</Roles>
	</Executions>
	<Roles>member</Roles>
	</Services>
	<!-- if you like to enable a cross domain calls for your services, add the permission here -->
	<Permissions service="org.resoa"> <!-- valid for every service which starts with org.resoa -->
		<Roles>resoa.node</Roles> <!-- internal calls will have the role resoa.node -->
	</Permissions>
</Resoa>

Resoa does not allow calling services of other deployed domains by resoaGateway.executeService(…). If you want to enable this, add a dedicated permission to the resoa.xml as well.