A
service is a set of operations that can be invoked by a
client,
which is an application component that resides on the same or another platform.
A service that you develop in EGL can be deployed in either or both of these
ways:
- As an EGL service, which can be accessed from EGL code either directly
or by way of a TCP/IP connection. The client can be a program, handler, library,
or other service.
- As a Web service, which can be accessed from code that runs in
a Web application server. The client can be a JSP, servlet, or Java™ client
application; or a script or an executable program written in any of several
languages such as C++, Perl, Visual Basic, or JavaScript™. Access is by way of an
HTTP connection.
Note: EGL 6.0.1 supports deployment of Web services and Web
service clients only on WebSphere® Application Server versions 5.1.x and
6.0. Also, EGL 6.0.1 supports deployment of Web services and Web service clients
only when WebSphere Application
Server is using the IBM® WebSphere runtime environment, instead of the IBM SOAP
or Apache Axis runtime environments. For more information, refer to the documentation
for WebSphere Application
Server.
At development time, the service is a part that includes implementation
code. Here is a simple example:
Service echoString
function returnString
(inputString string in)
returns (string)
return (inputString);
end
end
The Service part is similar to a library part:
- Neither can include a user interface
- Either can include variables (and constants) that are declared as private
- Either can include functions that are declared as private or public
Libraries and services differ in the following ways:
- The code that uses the service can access only public functions, not constants
or variables, whereas the code that uses a library can access public constants
and variables
- Any global memory in the service is initialized at each invocation of
the service, whereas changes to the global memory in a library persist for
the life of the run unit
Instead of using a Service part directly in your code, you create a variable
that is based on that part. The Service part includes the logic for the runtime
service but does not include the details necessary for access. At run time,
however, the variable is bound (refers) to a service that runs at a
specific location. The binding includes details on the protocol that is used
to access the service.
You specify the binding information in a variable declared in a service
binding library, which is a type of EGL library. The variable is global
to the run unit, as is true of any variable accessed directly from an EGL
library. For most uses, the initial binding for that variable provides all
the service-specific functionality needed by any client in the run unit.
The setting of the library property
runtimeBind determines whether
the initial binding of a variable to a service is based on a decision made
at development time or at deployment time:
- If you set the property to no (as is the default), the decision
is made at development time. The binding that you detail in the library is
in effect when the run unit starts.
- If you set the property to yes, the decision is made at deployment
time. The binding information is retrieved at the start of the run unit, from
a property file that is specific to the library.
For advanced uses, EGL provides these capabilities:
- You can get and set the service location at run time by invoking the functions
described in ServiceLib
- You can use multiple variables to simulate dynamic binding, as described
in Service bindings at run time
To provide access to a non-EGL Web service, you must use an EGL interface.
An interface also provides a secondary way to access a service that was developed
in EGL. For an introduction to this subject, see EGL interfaces.