- This topic has 3 replies, 1 voice, and was last updated 9 years, 1 month ago by
.
-
Posts
-
-
Hi All!
We don’t want our applications (service consumers) to directly talk to the middleware, rather we want a layer (say façade layer) in b/w the middleware and the applications, so that the applications (consumers) are loosely coupled with the middleware and we can change our m/w software (for example from biztalk to websphere message broker) in the future (if we need to) without much difficulties.
The big question is how to implement façade layer, one idea that we’ve piloted with is to implement the façade layer as a web service. A generic web service that any one who wants a service from biztalk calls, and that service forwards that request to biztalk via MSMQ.
Since all the consumers would be calling that web service, so it needs to decide for which service in biztalk it is intended for, and forward it to that particular location (Queues in our case).
My question is where should we deal with this issue of evaluating which biztalk orchestration this message is intended for, in web service, or in a generic orchestration within Biztalk? If we go for a generic orchestration, then it’d be a catch all, we’d have just two queues and it’d be listening on the request queue, for all incoming messages. All of them would be of different schemas, but would contain, a <service> tag, which would tell us which service it is intended for, and we’ll call its orchestration using the Call Orchestration shape.
If we do it in Web service, It’d have an input argument in the web method which tells us the service name. In this architecture we have service based request-response queue pairs. Suppose if service name passed is GetBalance, we forward it to the request queue of GetBalance Biztalk project, biztalk project returns the response to response queue of GetBalance and we pick it from there using correlation. That way we have queue pairs for every biztalk project (So we might end up with too many queues?)
What do you people think is a better solution in these, or any other solution you want to propose, considering our situation. Thanks a lot for your time, Hope to hear from you!!
Regards,
Sajid.
-
You don’t have anything inside the message itself that can be used for routing? This would be a content based routing scenario. Typically, the message type (root node and namespace) are used for this purpose. But you can use any property you want to promote for message routing or use extended properties from the adapter like File Name or SOAP Headers.
If there is nothing inside the message then I’m not sure how either place would really be able to determine were the message goes.
Hope this helps.
-
Actually we are doing it in a generic catch all orchestration, we dont know the schema at all, because it is recieving messages on behalf of all the biztalk projects deployed. So we'd have a pass thru pipeline, with XmlDocument as the data type of the incoming message. My question was can we parse such a message inside the generic orchestration, we dont its schema, dont know how many tags are in there, what we know is the root node name, and that there is a service tag name in there, whose value we need to decide further processing?
Also I'd like to know from experts out there, that how if we not go for this generic orchestration, but rather deal this routing to right orchestration in the facade web service, in which we have service based queue pairs for each biztalk project, web service routes to appropriate queue after examining the service name passed to it. As the projects in biztalk grow the queue pairs would also grow, and perhaps would be difficult to manage. I'd like to see your thoughts on it…
Regards,
Sajid.
-
The Web Service facade with an MSMQ backend to Biztalk would not be my first choice. If you decide to replace the Biztalk server you will need to re-engineer your facade to use a different back-end connection mechanism.
I would think about hosting the web services on the Biztalk server. If you changed Biztalk you would simply provide the same web service from the replacement system. The web service consumers would need know that the service provider had moved. This could be done with a manual update, or better still the use a directory of services, UDDI perhaps.
If you do use a facade, then I would use web services out the back as well. Use of the proprietary MSMQ will limit your future options or incur a major change to the facade. Have you investigated the WS-Addressing capabilities of WCF, which could make your facade basically a service router.Your generic orchestration concept seems to be reinventing the content based routing already available within Biztalk.
It would appear you have a generic service header containing a service tag. You could define a schema to just match this service header, promote the service tag and route using the pub/sub mechanism in Biztalk. Your service header would basically be an envelope around a message payload.
e.g.
<xs:element name=serviceHeader>
<xs:complexType>
<xs:attribute name="serviceTag"/>
<xs:any>
</xs:complexType>
</xs:element>If you put the routing functionality in the facade, then you are replacing existing functionalty in Biztalk, every new Biztalk application would require that you configure Biztalk and then the facade. You maintenance/support/operational costs will be higher
The request/response queues would work fine for a synchronous messaging model, how would handle an asynchronous model?
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.