What to do with MABS? (as of OCT-2014 release)

The development of MABS applications is mainly divided into two parts - EAI and B2B (EDI / AS2)
[I will update the links once I publish the detailed blogs for those]

Enterprise Application Integration (EAI)

All XML / Pass-through bridges – which can be used to connect two different types of systems – so it can be message transport protocols, structures, formats. With integration of WCF LOB adapter, you can connect to supported LOB systems on premise. 
Visual Studio is used to develop and deploy such applications.

B2B (EDI / AS2)

Integrating commerce transactions between businesses over industry or vertical-specific standards, such as X12, etc.
BizTalk Services Portal helps you to manage your EDI / AS2 message transactions with trading partners. If you need Transforms or other supporting artefacts, you may use Visual Studio to create a project of type “BizTalk Service Artifact” and deploy it. Then use the relevant references while configuring agreements / bridges.

Read more at About Azure BizTalk Services

Comparing with BizTalk Server on premise

With name “BizTalk” in MABS, it is inevitable that we start comparing MABS and BizTalk Server on premise. Quite obvious – nothing wrong. But when we do that, lets keep in mind that MABS is in its infancy stage - yet to complete 1 year since it went live (GA) - and BizTalk Server on premise is a veteran - 14+ years. MABS also has a different form factor and scale factor. However the biggest advantage for MABS is that all the learning experience of BizTalk Server on premise product creation comes to an aid while developing MABS. So the ramp up for MABS will be very fast. The product group is diligently working  on the new releases with some awesome features. Stay tuned for the announcements.

A very commonly asked question – BizTalk on premise server has no future? Is it dying? Presented this question in front of the product team.
Here is what PMs from the product team are saying - The future of BizTalk looks like an integration solution branded under a single product name which includes seamless integration of BizTalk Server on premise, IAAS (BizTalk Server on Azure VM) and PAAS (MABS) – that's the vision product group is looking forward to– offering a “solution” to the end user’s requirement who does not have to worry about the underlying platform or the implementation details.
So if you have queries like – This is how it is done in BTS why not in MABS? – This is not the same in MABS? – Can we have same feature from MABS to BTS? – etc. - keep them on hold at least for a while.

Not so bad - ah? At least in terms of features? Some apprehension? Oh yes, do I need to mention that - the detailed functionality to make the life more easier will evolve over the time, definitely

BizTalk on premise is recognized for its features like guaranteed message delivery, no message loss and no duplicates for transactional adapters  once BizTalk has received the message and more importantly the pub / sub model.
With the architecture of MABS, there is no Message Box like store (and logic) available. So when you configure bridges, the destination needs to be known beforehand.
Also, you can route the message only to a single destination. (Though you can connect multiple destinations to a single bridge and make on the fly choice of the destination based on the message properties / connector precedence.)
As MABS does not store the received messages, if the message delivery fails (for what-so-ever issues at the destination end point or issues in between stages), an error is returned back to the source client  as well as tracked in Tracking database and WADLogsTable. If the source was a store like FTP then the message will sit in that store only. In such cases, manual intervention may be required - like to stop the bridge, to troubleshoot and resolve the issue (assuming it is not just end point down situation). If the source was some external service / application, then the posting client has to handle this error and put a retry logic or alert mechanism as appropriate. The client may have to inform to the MABS owner / administrator if issue continues to happen. It is better to implement some kind of alerting mechanism (which is not present today out of the box) based on the error coming up in the tracking database / store.

I hope that the product team implements the much needed crucial functionality and we see more matured product down the line – at the earliest. Till then, you may overcome some of the shortcomings by taking care while designing your MABS solution – e.g. whenever you receive a message, first send it to blob store as the first destination and then chain it forward for real processing. This was just an example –there are architects who have devised very nice and practical business solutions (which are in production) with bright and innovative ideas. A new branch for MABS solution architecture patterns is developing.

So, if you have already used the BizTalk Server on premise, then I suppose you got a fair idea about what MABS can / cannot do. For readers, who have never used the BizTalk on premise, hope that the following blogs - EAI and B2B (EDI / AS2) - will help you to get some better picture.
[I will update the links once I publish the detailed blogs for those]