I will be presenting a session on Multi-Enterprise Business Applications in the Cloud as part of the July meeting of the Chicago Cloud Computing Users Group on July 30, 2009 at 6PM in Downers Grove, IL.

Join us for the July local meeting of the Cloud Computing User Group – this month in Downers Grove.

Our topic this month is Multi-Enterprise Business Applications (MEBAs), a new category of application for business collaboration that the cloud makes possible. We’ll review what the current thinking on MEBAs is from Microsoft and the cloud community followed by an in-depth demo and code exploration of an Azure business collaboration application.

Dave Bost, Developer Evangelist from the Developer Platform and Evangelism team at Microsoft will be the presenter. He will discuss how MEBAs facilitate business processes that span enterprises, how they are enacted by the exchange of messages, and how complex, cross-organizational challenges are managed through these applications (e.g. Security, Data, Management and Governance).

In this session, I will discuss the work that I was recently a part of in Redmond on “Project MEBA” in partnership with the Platform Architecture team. If the planets align, we will have the visionary and brainchild behind “Project MEBA”, Jack Greenfield join us by conference call.

You can find all the details and registration information at http://www.azureusergroup.com/events/event/show?id=2698780%3AEvent%3A13229&xgi=6zA1EHT.

[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.

[This is the 5th article in a series of diary entries covering my experiences with Project MEBA]

The vision for Project MEBA has always been about making it easier for business to collaborate more effectively with the most cost efficiency. We can offer up service based computing with offerings such as the Azure Services Platform which takes the complexity and capital expense out of the business parties hands and offers them to focus on their core business. However, in the Business-to-Business arena a major challenge is still finding those business parties to partner with. This leads us to our second vision with Project MEBA – provide a common space (“a community”) to link business parties with similar business needs. In this case, we are taking the ideas behind social computing and bringing it to the business world. 

With the MEBA Business Portal, business can join a community to find, communicate and collaborate with new and existing business partners. In building our portal concept, we didn’t have to go far in finding a starting point. Just a couple doors down the hallway in building 24 on the Microsoft Campus, members of the Platform Architecture team released a sample social computing application called “Kobe”. The purpose Kobe was to provide a sample “Web 2.0” application for a PowerPoint sharing website. Kobe had all the components we were looking for: a community portal, friends/contacts, communication, discovery, etc. With a few tweeking items here and there, we were able to take our requirements, combine them with the architecture behind Kobe and build out our MEBA Portal in a very short amount of time.

One of the reasons for the rapid development was what Kobe did with it’s architectural components. The MEBA portal was pieced together by utilizing another Platform Architecture team project called Blueprints.

Microsoft Blueprints make you more productive by helping you codify conventions, automate tasks, and package requirements, designs or implementations, so that you can use them again.

Blueprints is a form of Software Factories that plugs directly into Visual Studio and provides some foundational architecture components to ramp up your development effort. Through the development of Kobe, the identified the foundational aspects of the Kobe architecture and created a “Blueprint” to support the building a Web 2.0 website onto of the Microsoft Platform. Exactly what we needed in building our MEBA Portal. In a matter of hours, we were able to build our “social computing” website and adjust the contents to support our business vocabulary. This brought us the coveted 80% of the way in short order.

The “MEBA” Business Portal

Once a business joins the community, they are presented with an engaging home page that lets them know what’s going on within the community. In this case, we can show details on what are the currently running business processes, what are the most popular business processes within the community and what are the currently featured business processes. In this case, if the community owner uploads new business processes supported by the community, they can showcase them for business partners to participate.

You can go back and read the preceding articles to understand what I mean by a business process, but I’ll spare you the effort and tell you that a business process is simply a business collaboration between two or more business parties. Think of a Buyer and a Seller. The Buyer would like to send out a request for a quote on a particular product and if the price is right, purchase that product. The business process is the OrderFromQuote process and the collaboration is the arrangement between the buyer and seller to offer each other’s services to. In our case in this community, that arrangement is the transfer of messages to support the business process: 

Buyer sends Message to Seller requesting a quote for a product; Seller would respond with a message with the quote or an empty message refusing the request

It’s important for a community to offer something backs to its members. In our MEBA portal that offering is the mediation of business processes and the discovery of new business partners.

Each Business Process has a detail page that provides additional information about the process along with comments and ratings by other community members. If a business would like to participate in a collaboration, they would assign themselves to a role of the business process. In our OrderFromQuote sample, are you a Seller or are you a Buyer? Once you agree to participate in a certain role, the community should provide a means to find parties serving the other roles of the process and work with them to create a collaboration.

In creating a collaboration in the MEBA portal, we’re stepping out of the bounds given to us (for practically free) from Kobe. To communicate the ideas to the development team, I created a wireframe using PowerPoint. I never thought of PowerPoint as a design tool but it certainly served its purpose in our case.

With the collaboration, we are assigning the roles for each party to play in the process. Once complete the parties will have their assignments which in the case includes what WSDL they much implement on their end and what service bus address they will host them at. This is all wrapped into a mediation workflow provided by the MEBA business portal. From here, the business portal can track the progress of the transaction and report back to the participating parties on the level of quality and any previously arranged service-level agreements around time to response, success/failure ratios, etc.

With the MEBA Community Portal, we are providing a means on how businesses can discover, communicate and collaborate with new and existing business partners. We still have some time to go in finishing out the portal, but without the efforts of Blueprints and the Kobe project, we’d have a much longer road ahead of us.

Next up… the back end.

[This is the 4th article in a series of diary entries covering my experiences with Project MEBA]

The past couple of weeks on Project MEBA have been quite…challenging. Without getting into the details of those challenges (not important for this blog), I’ll just say that with the news of the economy and cut backs taking place across the industry, Project MEBA is fully funded throughout the course of my stay on the project (mid-April) and we’re moving ahead full steam. With that…let me tell you where we’re at.

In my last Developer Diary entry (Researching the Problem Domain), I laid out the work we were doing to try and understand the different B2B standards and specifications that exist. Specifications such as UMM, ebXml, RosettaNet, etc. What we’re trying to do with Project MEBA is to take these various specifications, where most of them are derived off of UMM, and build a system where someone skilled in these specs can plug-in and ramp-up quickly with a B2B implementation utilizing Windows Azure as the underlying infrastructure and the Azure Services Platform as the pieces to help orchestrate the business processes.

From the UMM Development Site, we are taking their Order From Quote example and using it as a golden thread business process scenario for our proof of concept. I have taken the time over the past couple of weeks to try and understand the UMM modeling language and nuances to interpret the business process. We’re now in the throws of getting down to the implementation. Here’s what we’re looking at…

It’s a simple process really. You have a Buyer who requests a quote from a Seller. This is one of the Business Activities in this Business Process. If a quote is provided, the Buyer can make the decision to execute the Place Order activity with the Seller. I’m over simplifying things here because there are a number of decisions that need to take place. The Seller may have rules on their end to determine if they can provide this Buyer a quote. What if this Buyer is blacklisted from the Seller because of bad dealings in the past? What if the Seller no longer carries the item the Buyer is requesting a quote on? When the Buyer submits a Place Order request, the Seller should request some sort of credit check if a credit line isn’t already set up in the first place. And so on.

If we drill into the process a little further, we’ll see the Business Activities break out into two different workflows:

Request For Quote Workflow

Here we see a little more detail into the Request for Quote activity. For instance, the Buyer sends the request out as a message formed as a QuoteRequestEnvelope. The Seller has an endpoint defined as Calculate Quote that will except the message QuoteRequestEnvelope and send a response back out in the form of a QuoteEnvelope message. There is a decision point after the Buyer receives the QuoteEnvelope. If a quote was provided, we have “BussinessSuccess”. If the quote was refused, “BusinessFailure”.

Obviously depending on the business, additional actions may be required on the part of determine why there was a “BusinessFailure” but this particular UMM doesn’t define that. it’s not part of the standard. What’s defined is the standard and it’s what the parties agree to. “If we agree to participate in this business process, with me playing the part of the Buyer and you playing the part of the Seller, I agree to submit a Request for Quote by sending you a QuoteRequestEnvelope…”. That’s what the model defines. An agreed to business transaction.

Process Order Workflow

Our next activity in the Request Order From Quote business process is the Process Order activity. Once again, more detail into the process. What we’re really seeing here is a simple Request/Response pattern of messages traversing back and forth between the two parties. It’s important to note that in the world of UMM, this definition doesn’t designate an implementation. It’s defining the process. These “messages” could be simple forms passed back and forth by fax – BUT those forms need to adhere to an agreed upon format of QuoteRequestEnvelope and QuoteEnvelope.

In our case, we’re thinking implementation. We’re thinking Azure. More specifically, we’re thinking of how the infrastructure supported by Windows Azure along with .NET Services can help us build a MEBA implementation.

Up next… jumping into our implementation.

[This is the 3rd article in a series of diary entries covering my experiences with Project MEBA]

I’ve been a bit quiet on the Developer Diary mainly because I’ve been spending quite some time on researching our business problem space. This isn’t a case of having a square peg and trying to figure out how to fit it into this round hole called the Azure Services Platform (not that ASP is a round hole mind you), but this is us (the technologist) having a better understanding of the business problem (B2B computing) at a higher level so that we can build a much more compelling solution.

Business-to-Business computing has been around for a good many years now. With the advent of the Internet, a global backbone became available for businesses to do … well … business with one another. The main crux is how to do this on a public infrastructure in a secure and reliable way. Along come Web Services and the WS-* specs that provide specifications on how to roll your messages to communicate in a secure and reliable way. However the business still had to worry about getting those messages to one another (how do we hook up?) and agree on what they were actually going to send to one another that would feed into their existing business processes.

As it turns out, this problem has been noodled on for a while and now we have groups such UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) and OASIS developing modeling methodologies (ie. UMM) and standard messaging protocols (ie. ebXML, HL7, etc.). Now it is our job, or the mission of Project MEBA, to offer the communities utilizing these types of business protocols to do business easily on top of the Azure Services Platform.

As part of Project MEBA, we are researching what are the types of entry points they would require to easily participate in B2B communities while not having to worry about the complexities. The ideas we’re floating around for what a “MEBA Framework” should include involve items such as:

• Business Process Services
  • Business Process Metadata Service
  • Business Process Management (Workflow; Event notifications)
  • SLA Monitoring & Enforcement between parties
• Service Choreography Services
  • Process State Synchronization (Message routing & delivery)
  • Identity Mapping
  • Data Composition and Transformation
• Market Management Services
  • Market Definition and Provisioning
  • Market State Repository (Data update and retrieval)
  • Market Lifecycle Management
• Party Management Services
  • Community Management (Groups & Memberships; Roles & Privileges)
  • Community Lifecycle Management (Self provisioning)
  • SLA Monitoring & Enforcement between broker and parties
  We have a lot of ideas in store and we certainly have our work cut out for us. The decisions we’re currently making is what are the priority drivers in our list of features that will get business up and running with their B2B transactions utilizing the Azure Services Platform. We certainly see a tremendous value in providing this infrastructure base for B2B computing. The challenge now is where to focus our efforts.

  For me, it’s especially interesting because the work I’m currently doing on the project is certainly outside of my comfort zone. It isn’t only this foray into cloud development and what that means, but in my 15+ years of software development, not once have I had to deal with analyzing any industry standards and developing a solution around it. Let one, building a solution that not only supports one industry standard, but multiple. However, taking yourself out of your comfort zone once in a while offers up tremendous opportunities for knowledge growth and stimulating the brain waves.

How about you? Do you have any experience in building B2B solutions? What were your efforts like? Did you use a packaged solution? What were the challenges? Were you successful? I’d like to hear your stories.