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