You can access services in ways that match your need:
- You can write an EGL service type and deploy it as a "dedicated service," along with your Rich UI application. In this case, you don't need to know the service location, and the logic for accessing the service is a simple call statement, a callback function, and an exception handler.
-
You can deploy the same EGL service type as an EGL REST-RPC service. In this case, your call statement has an additional clause, and you'll use that clause to reference a resource-binding entry in the deployment descriptor.
The resource-binding entry stores the access details outside of your logic. As a result, you can reference a different service location without re-generating your code.
-
If your EGL REST-RPC service is referenced from one or more handlers, you might write a simple, declarative proxy function in a library -- no logic needed there -- and then reference that function from your requesting code. In this case, you also write a resource-binding entry.
The mechanism just described also works when you access a dedicated service or a third-party REST service.
- You might invoke several services to combine their data in a mash-up, which is an application that provides a single presentation from multiple sources. A mash-up might be lighthearted, or worthy of enterprise-level computing, or both. EGL allows for creativity and depth.
How do you start to learn about service access?
- Do you want to be "hands on" from the start? Try out the code snippets for accessing a service.
- Do you want to see a more detailed overview of the options? Consider service bindings.
- Do you want some background information? Read service-oriented architecture (SOA) for EGL developers.
- Do you want to learn more detail that is specific to EGL? Go to the Help system, search for and select "EGL support for SOA," and gain access to the subtopics by clicking the ToC icon at the bottom left. The language reference also has topics of interest; in particular, "REST annotation."
We were most concerned about ease of use when we designed service access. We also ensured that the use of proxy functions is similar to the use of proxy functions for accessing a program on IBM i.
We're pleased with the design and the outcome, but let us know what you think.
-- Ben
No comments:
Post a Comment