Using static ports with ESB

what happens if you have multiple applications that use the same dynamic send port configured using ESB.

Pros:

• Single port to handle multiple end point addresses.
• Single port to handle multiple transport types.

Cons:

• No ability to easily set the host instance that the port will be excuted in.
• No ability to stop the send port without impacting all end points.

in my current project we have many endpoints that use a single send port, the client has raised a concern that this will impact their ability to scale out and it will not enable them to stop sending messages to a specific end point without impacting the rest of their end points.

one possible workaround I found (with Bruno Spinelli’s help) was to create a static send port that has the same subscription filter as the dynamic send port. The static send port has to use the same pipeline that the dynamic send port is using (in my case, it is the “itinerarySendPassthrough” pipeline) . So I used the dynamic send port during design time in VS2008 but for production I created the static send port and removed the dynamic one.

This approach gives the client the flexibility he was looking for and also the ability to decide which endpoints will share the dynamic send port and which end points will have their own dedicated static send port.

Send me an email if you are interested in the source code for this post.

Good luck

Uri

Read Full Post »

Updating existing schema without redeploying the dll.

We recently had an issue in my current project that involved making changes to existing and deployed schemas.

When we tried to deploy the schema we got an error message since we had maps depending on the old schema.

We are using ESB so we figured out (with Brad Tillman’s help) that there is no need to deploy maps into Biztalk. it is enough to add them to the GAC and the itineraries will use the maps from the GAC.

Now, since the map dll is in the GAC, Biztalk has no awareness of the maps so we can redeploy the schemas into Biztalk without having to uninstall the dependent artifacts.

This is useful when you have multiple endpoints dependant on canonical schemas and you want make changes to the canonical schemas.

Now, there is no need to remove all dependant endpoints to make the change. 

Good luck

Uri

Read Full Post »