Quick answers to David's questions

[David]: Duane, OK - done - synopsis - this is the 
programmers eye-level view that fits into that world of people using UML to 
create enterprise integration applications with J2EE et al today.

 

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

 

[David]: The SOA BUP will allow business 
integration designers to pick models and patterns, and create new patterns for 
their own for industry uses.

 

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

 

I apologize that I will not be able to answer any 
questions you may have before the end of June.
Just compile all your 
questions in a document, and wait for me until I come back from my 
trip.

 

Regards