Introduction
The pull pattern is based on the need-to-know principle. In this pattern, the consumer knows the exact provider and asks for specific information which is made available only if and when possible. The sequence diagram attached depict a typical dialog scenario between the Consumer and the Provider using this message pattern.
Note: The encryption and the decryption of messages is used only in very specific cases and will be detailed in the section Encrypting and decrypting messages. The procedure to sign the message with a digital signature and the corresponding verification of the signature will be described in the specific page Signing messages and verifying the signature.
Messages
In the above typical dialog scenario between the Consumer and the Provider, an example of message interchange is as follow: the consumer send a PullRequest to ask specific information about a Vessel and the provider deliver that information in a PullResponse. The PullRequest message and the response in XML format are as bellow.
The sequence diagram
PullRequest
In the PullRequest. the all message is enclosed by the PullRequest tag. The received PullResponse corresponding to the example could have the Vessel Name and other attributes filled.
Business rules for the PullRequest
The message Pull Request is used in the Pull communication pattern to request information. This message extend the standard message structure, adding the following specific attributes (for the description of common message structure, see The standard Message structure common to all communication protocols). The specific attributes of the PullRequest are:
Element | Required | Value | Description |
---|---|---|---|
PullType | Yes | One of the string values:
In the specific case of a simple PullRequest we use "Request". | The Pull Type is to distinguish between the simple request and the subscription mechanism. It can also be use to unsubscribe to a flow. |
ResponseTimeOut | No | Time in seconds. An integer value, as for example: 3600. | The request should be answered within this time limit. After this time, the response may not be considered by the requesting system. |
Requests | No | Example: <Requests> <ExpectedResponseTime>32 </ExpectedResponseTime> </Requests> | Service Capability required by the system provider. See The ServiceCapability. |
DiscoveryProfiles | No | Not should be used, because the receiver (recipient) is knowed. | DiscoveryProfiles is only for unknown patterns, see The DiscoveryProfiles the way to profile a service. |
PayloadSelector | No | Supply a Selectors array refereed to the Payload data specified in the PullRequest. | To understand this element refers to The PayloadSelector for query by example. |
PullRequest example
The Sender is a consumer, that make a request of data" and the Recipient is a Provider. Both are very well identified as services in the Cise Network.
Note the MessageID c7b7dea3-a2af-4ef9-b9e9-0d8e2e63f66d.
Synchronous Acknowledgement received
Note that the CorrelationID (c7b7dea3-a2af-4ef9-b9e9-0d8e2e63f66d) is referred to the PullRequest MessageID
Asynchronous Acknowledgement received
Note that the CorrelationID c7b7dea3-a2af-4ef9-b9e9-0d8e2e63f66d is referred to the PullRequest message