Best practices for services and related interfaces in EGL

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.

Related concepts
EGL interfaces
EGL services and Web services

Related tasks
Creating an EGL Interface part
Creating an Interface part from a Service part
Creating an EGL Service part

Related reference
EGL interfaces

Feedback
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.