| Oracle® Retail Service Backbone Oracle® Retail Service Backbone Implementation Guide 14.1 E57331-01 |
|
 Previous |
 Next |
| Oracle® Retail Service Backbone Oracle® Retail Service Backbone Implementation Guide 14.1 E57331-01 |
|
Previous |
Next |
For each service, RSB packages a proxy service, the corresponding business service and the instrumentation code as a single deployment unit. This combination of services and instrumentation is called a Decorator. It is based on the Decorator design pattern where value is added ("decorated', in other words) to the base functionality. RSB adds instrumentation code, security policies and binds the proxy service and business service together in the decorator. When a decorator is deployed both proxy service and business service are deployed along with instrumentation code. Following diagram is a sequence diagram showing the invocation call from service consumer to service provider.
A payload is the XML message that is send to and returned from web service operations. These XML messages conform to schema standards agreed upon by Oracle Retail and governed by RIB-RSB. These standards are published as XSDs and referred as Retail Business Objects (RBO)
Examples of payload types include ItemDesc, ASNInDesc, ASNOutDesc etc.
The Router/Injector service is a mechanism for external web services to subscribe data published in RIB topics. In the absence of this method, the external applications will have to subscribe directly to JMS Topics and parse the message to call appropriate web services. This solution serves as an alternative to integrate external web service providers to RIB.
RIB4OMS is an example of a router/injector service included in this release. This routing service is available in the pak RsbServiceIntegrationFlowPak14.1.0ForRibOmsToRsbOmsRouting_eng_ga.zip. The diagram above shows the different OMS services that routing service calls based on the message family.
This is a term use to refer the actual service provider like RMS, SIM, external applications etc. RSB and OSB are intermediate layers between the service consumer and service provider.
The RSB service payloads are designed around the concept of a message family. Each message belongs to a specific message family. Each message family contains information specific to a related set of operations on a business entity or related business entities. Examples are ASNIn, ASNOut, Items and so on.
A message family may contain multiple message types. Each message type encapsulates the information specific to a business entity within one or more business events. For example, the order message family is published for events such as Create PO Header, Create PO Detail, Update PO Header, or Delete PO Detail.
This classification helps to group related messages for reporting and analysis. Examples of message family include ASNIn, Customer, Items, ItemLoc etc.
Instrumentation is a method of intercepting the main flow and collecting important information for reporting or analysis. In RSB, the instrumentation code collects application name, proxy and business service operation names, timestamp, payload etc during instrumentation. The collected information is stored into a database configured at installation time. The information is collected in the most efficient way so that the primary invocation flow is least affected in terms of performance.
The RSB instrumentation captures the timestamps of the request and response, the payload of the service call and response, the service URI, operation name, application name and the result of execution. The instrumentation call is made at the response pipeline, in other words after the service call returns from the service execution in the edge app server.
The information collected by instrumentation is reported through RIC.
Between service consumer, RSB and service provider there are many options to secure the communication using web service policies. Since there are multiple layers involved in the communication, the policies chosen for each layer must be compatible. RSB supports two such sets of policy configurations; policy A and policy B. RSB comes with supports for these two configurations with scripts to automate the configurations. We believe these configurations satisfy most of the common security requirements of the customers. Any requirements outside these configurations will have to be configured manually.
Policy A is SSL with UsernameToken. The transport layer of the service invocation uses https for this policy. The consumers will have to provide the username and password for invoking the service. Policy B is message protection with UsernameToken. Policy B should be called with http. The encryption is at the message level, instead of transport layer.
