This pattern uses a web service to communicate with a project that is located somewhere else. This can be a SOAP or a REST web service. These two projects are completely separate and can be deployed separately. See Web Services guide for more details of how this is modeled.
Characteristics
In the table below the implementation characteristics by using a Function is shown.
| Type | Score | Description | |
|---|---|---|---|
| Knowledge characteristics | User set or System set | User set | User-set values enter the profile, which are set from the returning message and the subsequent data mapping. |
| Parameters or complex model | Parameters | Only simple input/output parameters could be used with Web services (BaaS). The input and output parameters are neatly defined in the contract of the web service. You are able to steer what values are set in the data mapping. If you want to fill in the parameters differently for different calls from the same module, an additional data mapping and AQ_WebServiceClient service call needs to be created. | |
| Enhanced by Blueriq Functionality |  | Blueriq can use dependencies up to the contract. There are no decision requirement graphs or dependencies possible between the calling application and the BAAS. | |
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Focus on Internal or External Use | External | A web service is intended for external use, and relies on an official contract definition. |
| Low Implementation complexity | | You get two additional modules in your project, and a second project next to it. As you are in control of the information being send, the structure will be similar to what you use in the application module. Therefore the mapping should be easy (1 to 1). You have to create your own contract for the communication, and keep this updated. | |
| Internals invisible (encapsulation) | | Internals are not visible and/or accessible of a web service. | |
| Autonomous | | The business rules are executed in a separate profile, and no side-effects are possible. | |
| Highly Testable | | Webservices are easily testable. | |
| Highly Reusable | | A BaaS implementation is not very reusable because of a lack of parameter support. Hence, for every web service call a mapping must be defined. | |
| Out of the Box | | No custom code required in general. | |
Deployment characteristics | Part of Application or Separate Deployment (=deployment) | Separate Deployment | As soon as a new version is deployed, all consumers directly use the new version. When web services are versioned, the calling party can decide itself when to migrate to a new version. |
Overview
Content Tools