Quick answers to David's questions

[Hamid]: First, the document was written in a very short period of time (2 days if you need to know), and it was intended to be read by people who have enough imagination. The document draws few dots on the board, and the reader should connect the dots and extend the line using imagination. Further details and information will be provided after the end of June, as I am extremely busy right now with other work. If you read the document literally (without imagination), you may not find much information that you are looking for. So, the answer to your question "Is this document for programmers and is about UML, J2EE, etc...?" is no.

[David]: So - in addition to this - following Ben's usage - we need the SOA BUP - Business Use Patterns, as the overarching view here - that introduces what ebSOA is all about - and most important - how people can use SOA BUP to develop their own solution rapidly.

[Hamid]: That's a good thinking. "Usage patterns" will be part of the first specification, namely the "ebSOA General Specification" (or ebSOA GS for short). Even if the document does not mention it, with a small imagination, you can figure out yourself that the ebSOA GS will talk about "Usage Patterns".

[Hamid]: This is where I disagree with you. Yes, the "Usage patterns" will be described in the ebSOA GS spec, but this alone is not enough for the industry to create solutions by just looking at the patterns and usages, and then start implementing their solutions. If what you are saying were true, then all B2B and EAI problems (which could not be solved by ebXML and Web services) could be solved by just adding good usage patterns, and good models to the existing ebXML and/or Web servces technologies.

[David]: Typical patterns would include:
1) Classic ebSOA - this is the ebXML pattern around BPM.
2) Holistic ebSOA - blends use of BPM with webservices.
3) POA - process-oriented architecture.
3) SOA - EAI service oriented architecture.
4) EPR - bespoke solution pattern(s) for particular
sector domains - in this case eGovernment services
and citizen-facing applications.
and so on.

[Hamid]: What you are describing here is not exactly what I would call "Usage patterns". What you are describing is a solution that can cope with outstanding problems in B2B and EAI that neither ebXML nor Web services is able to solve at the moment. I understand that you are eager to see a solution (or solutions) crafted. But this is too early and too premature at this moment. Don't get the idea that I am too theoretical and not interested in concrete solutions. To remind you, I was the person who asked at the teleconf meeting (not the last one) that we need to gather business requirement from the automotive industry. The reason I had asked for this work item is because I wanted to have one foot on the theoretical side and one foot on the industry side. What we are drafting in ebSOA specs are theoretical and foundational in nature. Solutions can only be drafted after at least 18 months of spec work. I wanted to have a document on the business requirements of the automotive industry so that I can draft temporary solutions for them (which we would put as recommendations in appendix) in case the spec work turned out to be longer and last more than 18 months before we can even think about describing solutions.

[David]: Ben's approach to SOA - while good for todays programmers can also suffer from rapid obsolescence - as witnessed from people touting POA, and varients already today. You are then yesterdays news. We need to have an adaptive model here - that can then assimulate the latest in-vogue programming components as they emerge.

[Hamid]: The document I wrote is not for programmers. The intent was that ebSOA specs are foundational in nature in that their scope is bigger than (and not limited to) the problems you are seeking drafted solutions for. The goal here is not to draft concrete solutions. I can draft 10 concrete solutions for you, but they all will be obsolete after 2 years. If to solve B2B, B2C, and EAI problems, one has only to work on crafting solutions without the need for theoretical foundations, then ebXML and Web services could have done the job already. It's like you are seeking to discover advanced computational techniques in applied mathematics while pure mathematics does not even exist yet. Microsoft is parallely working on the technology and will release it around 2006 or 2008. It is a technology (not the concrete solutions) and its theoretical foundations that Microsoft is spending lots of money on and it will be here to stay for many years to come before it can become obsolete. The solutions you want to draft at this early stage of our ebSOA specs are the one who will become obsolete and will fail to deliver.

ebsoa message