Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The Service Dispatcher handles dispatching services to the appropriate Service Enginewhere Engine where it is then invoked. There is exactly one ServiceDispatcher for each Entity Delegator. If there are multiple delegators in an application there will also be multiple dispatchers. The ServiceDispatcher is accessed via a LocalDispatcher. There can be many LocalDispatchers associated with a ServiceDispatcher. Each LocalDispatcher is uniquely named and contains its own list of service definitions. When creating an instance of a LocalDispatcher, a DispatchContextis also created and passed to the ServiceEngine.

A LocalDispatcher is associated with an application. Applications never talk directly to the ServiceDispatcher. The LocalDispatcher contains an API for invoking services, which are routed through the ServiceDispather. However, applications may be running in different threads than the actual ServiceDispatcher, so it is left to the LocalDispatcher to keep a DispatchContextwhich DispatchContext which among other things keeps a reference to the applications classloader.

...

This is where the service is actually invoked. Each service has an engine name assigned in its definition. This engine name is mapped via the servicesengineserviceengine.xml file and is instantiated by the GenericEngineFactory when called upon. Third-party engines are supported and must follow the GenericEngine interface when implemented. See the Service Engine Configuration Guide for details on defining engines.

...

Services are defined in Service Definition Files. There are global definition files used for all service dispatchers as well as individual files associated only with a single dispatcher. When a LocalDispatcher is created it is passed a Collection of Arils which point to these definition files. These files are composed using XML and define the necessary information needed to invoke a service. The DTD XSD of this file can be found here.

Services are defined with a unique name, associated to a specific service engine and the input and output parameters are defined explicitly. Below is an example of a service definition:

Code Block
<service name="userLogin" engine="java" location="org.ofbiz.commonapp.security.login.LoginServices" invoke="userLogin">
    <description>Authenticate a username/password; create a UserLogin object</description>
    <attribute name="login.username" type="String" mode="IN"/>
    <attribute name="login.password" type="String" mode="IN"/>
    <attribute name="userLogin" type="org.ofbiz.entity.GenericValue" mode="OUT" optional="true"/>
</service>

SERVICE ELEMENT:

Attribute

Required?

Description

Default Value

name

Y

The unique name of the service.

 

engine

Y

The name of the engine (defined in serviceengine.xml).

 

location

N

The location or package of the service's class.

 

invoke

N

The method name of the service.

 

auth

N

Does this service require authorization? (true/false)

true

debug

N

Enable verbose debugging when calling this service?

true

default-entity-name

N

The default Entity to use for auto-attributes

 

export

N

Is this service allowed to be accessed via SOAP/HTTP/JMS? (true/false)

false

max-retry

N

Sets the max number of times this service will retry when failed (persisted async only)

-1 (unlimited)

require-new-transaction

N

Require a new transaction for this service

true

semaphore

N

Defines how concurrent calls to this service should be handled:
none: multiple calls to this service may run concurrently
wait: while this service is running, queue any subsequent calls
fail: while this service is running, fail any subsequent calls

none

semaphore-wait-seconds

N

When semaphore="wait" how many seconds to wait before failing the service call

300

sempahore-sleep

N

When semaphore="wait" how often (in milliseconds) to check if the waiting service call can be run

500

validate

N

Do we validate the attributes found below for name and type matching? (true/false)

true

  • name - The unique name of the service
  • engine - The name of the engine (defined in servicesengine.xml)
  • location - The location or package of the service's class
  • invoke - The method name of the service
  • auth - Does this service require authorization (true/false)
  • export - Is this service allowed to be accessed via SOAP/HTTP/JMS (true/false)
  • validate - Do we validate the attributes found below for name and type matching (true/false)

...


Now look at the console and see what the test service has echoed.
The test service is located in core/docs/examples/ServiceTest.java You must compile this and place it in the classpath.

...