Developer Diary – the Mediation Service
[This is the 6th article in a series of diary entries covering my experiences with Project MEBA]
In my previous posts, we discussed the problem space and what the thoughts are in bringing social computing to the B2B space. Now let me touch on the meat behind Project MEBA.
To reiterate from previous posts, Project MEBA is about providing an efficient, secure, and economical way for businesses to do business together that is also highly reliable and can scale with the businesses needs. When the Azure Services Platform (AzSP) was announced at last year’s PDC conference, the technical means to address these requirements was finally realized. We’ve been specifically focused on the .NET Services side of the AzSP story.
With the .NET Services Bus, we have the means for business to exchange messages in the cloud without having to worry about some convoluted process to get the various business parties to talk with one another.
Going back to our portal and the aspect of creating a business collaboration, each party in a collaboration will play a particular role within the business process. The Project MEBA portal will provide instructions for each business party on how to implement the services required on their end and also provide them the endpoints in which they’ll use to communicate. These endpoints are managed (and owned) by the MEBA’s AzSP solution. With Access Control Services, we can define the claims needed for each of our business parties to have the authority to host an endpoint in the MEBA cloud solution. The means in which we’re to provide this authentication/authorization process with the MEBA backend is yet to be finalized. We’re looking to implement an X.509 certificate store that has a trust relationship with the Access Control Service. Once the trust is established, we should be apply the necessary claims to create an endpoint in the MEBA solution. More of this work will come down the road with the Geneva Framework.
Each business process will have an associated workflow within the MEBA portal to support the mediation of the business process. As part of these business arrangements, there may be agreements in place such as time to respond, providing the agreed upon information, etc. With the workflow in the middle, we can provide a mediation service that tracks business transactions and outcomes. We can then provide this data in a dashboard fashion back to the participating parties. Therefore, if there are any discrepancies in the business dealings, we have a 3rd party mediated service that can provide the proof necessary to resolve situations.
The diagram below shows a simple business process scenarios architecture. The buyer will open an endpoint to communicate with the workflow. The workflow implements a ReceiveActivity to process the message, perform any necessary routines such as logging, and than executes a SendActivity to pass on the request to the Seller. The Seller than respond to the request which passes through the workflow and onto the Buyer.
.
In this architecture, we are implementing an on-premise workflow as opposed to using the .NET Services Workflow capabilities. The .NET Services Workflow just didn’t provide the activities and capabilities we needed to support our scenario. The .NET Services Workflow is changing rapidly with each new release of the .NET Services SDK. The team will revisit this once the functionality of the .NET Services Workflow has been expanded.
So there it is… simple enough, yet very powerful. With the capabilities of the .NET Services Bus, we have the opportunity to save business a substantial amount of money by taking the burden away of having to support an expensive infrastructure to perform business transactions with partners. This is just an idea that we’re playing around with. Taking a vision of a real work business problem and applying a solution that is now possible with the Azure Services Platform. Moving ahead, the team will continue to build this proof-of-concept and make it available to all of you. I would expect there are *many* things we can do to enhance the system and apply new means to attach the problem space. One idea already is to incorporate the recently announced support for routing and queuing in the service bus. Those two features will greatly benefit our solution.
Unfortunately, my time has come to end on the MEBA project. I have to get back to my REAL job in Chicago and continue to evangelize the incredible technologies and development platform that are continually evolving out of Redmond and beyond. This project gave me the chance to work with some of the brightest minds in the industry and for that I’m truly grateful. The team will muster on and I can’t wait to see how it all turns out in the end. If our vision is correct and the technology lives up to its promises, this will truly be an industry changing event and I can say I was part of it.
