Hello, I am opening this topic to know what your thoughts in the role of the broker in common SOA requirements.

One of the basic SOA usages is to creates abstraction layer between data provider applications and data consumer applications.

Normally we do this using Web Services over HTTP(S) with SOAP protocols. The common approach I see to address this implementations in webMethods is by not using the broker at any stage.

In the common approach architecture there are services to get data and services to expose data to consumers, the communication between those is done by direct invocation, top services close to business users invoke data services which can be in separated packages, but without recurring to the wMBroker at any stage.

In Web Services the communication is synchronous and that’s normally the excuse not to use the wMBroker, but it is well know that the broker supports synchronous communication.

My questions are do you see any advantage in calling creating an abstraction layer between top level services and bottom data services using wMBroker? (I can point one disadvantage → performance).

What is your general experience with wMBroker in the SOA landscape do you have any samples were you really think the broker has a major advantage or it is really required?

Provider provides a service to the consumer. It does not have to be synchronous always. One such example is when consumer requests automated daily feeds by sending a flat file request. Provider can service this request by publishing feed to the consumer.

Service in context of SOA can be implemented in any protocol - http, sftp, jms, ftp etc…

Thanks smk appreciate your feedback.

Agree in SOA context we can have multiple protocols stated that in:

The example you gave it’s quite cumbersome, as it could be considered EIA/B2B rather than SOA. But nevertheless you could have a service processFlatFilePurchaseOrders, in this case I think most of the times the client would be happy with a response status like “File received, and it is being processed”.

But what about a request of the type retrievePurchaseOrderDetails(PONum) which has to go through multiple systems (it can be under analysis, processing, shipping, etc each info in different systems), would it make sense to use the broker in such an instance?

Hi,

What you are asking is a design time question not design pattern. Yes receivePOstatus should be synchronous (again it can be a REST service not neccesarily a web service).

However there are many instances where synchronous real time response is not feasible and sometimes consumer is not interested as well or its a bulk request to do N number if things.

It also depends upon how provider is setup to process the request. If provider cannot get you synchronous reply then you have to use other means.

At the end it all depends on the scenario and what design pattern suites that scenario.

Generally every org. will have reference architecture document which will describe you what design patterns are supported by the respective IT applications used by the organisation.

Everything in SOA is a service and its independent of what protocol you use.

Nothing is bad / cumbersome if use for right scenario with right design pattern.

Hope it helps.

Cheers,
Sumit

Thanks but I am looking for practical examples of synchronous messaging using the broker.

Let me rephrase the question in a very brief format:

Is there any advantage in using the broker in synchronous requests?

An example of a synchronous request can be a web service implemented in the IS to pick data from a database and expose it to consumers immediately.

This is what I think.

It can be if you have 2 dedicated IS, one for front end (presentation layer) another for back end (the one that collects the data), that way it is actually the only way for the FEIS to call services from BEIS.

If the services are in the same IS it doesn’t make sense to use the broker in synchronous communication, it will degradate performance, and the decoupling will be meaningless, instead of a service chain it will be a trigger chain, service revision/reengineering will demand the same kind of effort.

As you said it looks like FEIS is used as an application server and BEIS as an ESB. Is that correct ? Can you elaborate when you said FEIS is presentation layer ?

Ofcourse broker can be used in request / reply pattern. But without knowing the full scenario its difficult to comment.