The following practices are recommended for developing services and related
interfaces with EGL:
- Use interfaces as a design tool
- You can create one or more interfaces that describe the functionality
that you want to have coded in an EGL service. After the interfaces are complete,
you or others can code the service, which is said to implement the interfaces.
The primary meaning is that the service contains every function described
in the interfaces. The interfaces provide a kind of contract that the service
must fulfill.
This use of interfaces provides the following benefits:
- Helps people in your organization to think clearly about what operations
are needed before service development begins
- Allows developers to finish client applications while the service code
is under development, as the client code can interact with variables that
are based on Interface parts rather than on Service parts
- Avoid unnecessary declarations that refer to a Service or Interface
part
- Unless you have a reason to do otherwise, use services binding libraries
to define every variable that refers to a Service or Interface part.
You usually do not need to declare those kind of variables elsewhere or to
pass them to or return them from a function or to declare more than one for
referring to a particular service.
Each of the variables in an EGL library
is global to the run unit.
- Create multiple service binding libraries, each for a different collection
of service and interface parts
- Organize bound variables into small, logical collections to avoid having
to regenerate a library as new parts are added.
- Assign a value to the debugImpl field in the @EGLBinding and @WebBinding
property (as used in the services binding library)
- The property field debugImpl identifies a Service part that is
accessed at debug time, even if the service is only a development-time stub.
If no part is specified, the debug session invokes a deployed service without
stepping through that service; but in that case, the absence of a runtime
service throws an exception of type ServiceInvocationException.
- Use the IN modifier to save time and bandwidth when you do not need
to return a value for a given function parameter
- Use of the IN modifier reduces the time needed for runtime processing
and reduces the amount of data that must be transmitted from the service back
to the client.
- Avoid declaring global variables in a Service part
- If you declare all variables in a service as function parameters or other
local variables, the behavior of the service is consistent wherever the service
is deployed.