Klaus:
Thanks for these detailed answer, I think it is a great way to make progress.
>As is common between inter-organizational efforts, the coordination and
>alignment of work is always done via official liaisons and this has
>proven to work very well; ex, the BPEL TC. UN/CEFACT has a Standards
>Liaison Rapporteur (SLR). If technical issues need to be resolved or
>addressed, the SLR may communicate directly with the parents of the
>TC/SC/WG to ensure actions are taken.
I am glad to see that you have established so quickly such a valuable relationship with a standard like BPEL. I have found this group very closed to B2B ideas, I am glad it is finally opening up. B2B won't be limited to the partner tag after all.
I cannot respond to a lot of the comments you are making below as I was never involved with the JCC, nor actually was I at any point involved with the decisions made at the ebXML level. I have always been a contributor nothing more. I simply value ebXML and its architecture.
I personally like the approach of the TMG working on a technology neutral business collaboration framework. Since you acknowledge yourself that ebXML is nothing more than a technology why not establish the same relationship between BCF and all the other technologies? Why would a piece of ebXML be bolted on UMM, when it could be just another technology that map to the BCF concepts? Like BPEL.
Afterall, BPEL is allowed to talk about "collaborations" just like BPSS. But they can do it in any way shape or form that suits their technology. I think they call it "abstract BPEL" or BPELa as opposed to executable BPEL (BPELe). Similarly, BPEL is relying on a web services based messaging layer, just like ebMS.
The web services stack is still a bit immature or incomplete to match the capabilities of ebXML. In addition, the ebXML architecture and its BSI is fairly unique compared to the architectural ideas of web services (since they did not come from the B2B angle). So why not let darwin give us the answer, let ebXML be a technology and architecture of its own. I think the last paragraph of your email says it all:
>UN/CEFACT (TMG) has always said and it will continue to align work
>around the UN/CEFACT ebXML BPSS with the UMM Meta Model as agreed
>earlier this year in our project team meetings. Nothing in the last 2
>years has changed UN/CEFACT's open intentions regarding our BPSS
>roadmap.
As I read it, you would proceed to any alignment regardless of its consquences. Once you made a decision, other ebXML TC must follow. Poor timing could results in periods during which ebXML could be "broken". It would be much more efficient from a technology perspective to let ebXML pull changes from BCF, rather than BCF pushing changes to ebXML. We also run the risk that one day BCF would be either more focused on "private" or "public" processes than respectively either ebXML or BPEL can take on. For instance, the way I see orchestration like many others is that before you hit the B2B interface, there is a choreography layer that in the most trivial cases does not show up, but is necessary as soon as you have more that a few orchestrated services that talk to each other. What if BCF abstracts this choreography layer out, how do we proceed dealing with the use cases that we have?
By starting a new ebBP TC at OASIS, ebXML gets a chance to be a "technology and architecture" for B2B. I more than ever think that this architecture will prevail. I also think that a healthy relationship could be developed between the ebXML technology and BCF, peer-to-peer relationship actually, like BCF/BPEL, rather than client/server as it seemed to have happened in the past.
Once ebXML becomes a fully independent technology, I actually, don't understand why UN/CEFACT would continue maintaining a technology specific piece while you guy's might have so much work to do in the technology neutral framework. That would amount to a big distraction.
What do you think?
JJ-