Database Reference
In-Depth Information
We not only separated the business service (provider) and client, who will now access the
resource using /order/getCustomerInfo , but we also established a layer of frame-
work. This will allow us to control all the aspects of the service's lifecycle—SLA,
policies, security, and monitoring (refer to selected areas in the preceding figure). Now,
we can intercept all traffic to/from our service and do all that is necessary. Interestingly,
Interceptor is the exact word that describes this behavior in other realizations of the ESB
SOA pattern, for instance, ServiceMix/CXF. Naturally, we will not be able to touch all
these aspects in one chapter, so please refer to the OSB documentation for each tab in the
preceding screenshot.
Tip
Our short exercise was based on the WS/WSDL service. The REST Proxy implementation
will be even easier, as we do not need to import any resources. Yes, REST services were
designed with simplicity in mind, but think of detachable contract—how much flexibility
it gives us! The time of holy wars between SOAP and REST is over, and thanks to OSB,
we have unified service management for all types of services.
The Message Broker pattern mentioned previously is equally capable to dispatch mes-
sages and could be a good choice for REST or just HTTP-based services. Message
Broker, as a commercial product, is commonly associated with IBM ( ht-
tp://www-01.ibm.com/software/integration/ibm-integration-bus/library/message-broker/ ) ,
and we hope that you understand that we are focusing only on the pattern. It will be inter-
esting to see what we gain and what we lose if we try to implement a custom lightweight
Message Broker for a predefined canonical protocol.
Search WWH ::




Custom Search