Re: [ebsoa] Quick answers to David's questions

Hamid,

 

Interesting responses.  IMHO the 18 month work 
on specification has

already been done - it is the OASIS BCM 
specifications and the 

OASIS BPSS, CAM and 
Registry work.

 

Now we need to move forward rapidly by providing 
the ebSOA components

to integrate that and give people the means to 
leverage these OASIS 

tools in a synergistic way.

 

When reading the BCM specification and executive 
overview you will see

why I believe your document to be 
programmer-centric.  That's not a 

critism - its just an observation.  As we 
found out with the CAM work - 

you actually need two documents a lot of the time - 
one that articulates

the business-model view and one that describes the 
IT-model view.

 

However - for your document to tie better into the 
business-pattern side,

then we need to open with that message.  Alot 
of the history of 

programming techniques belongs in an Addendum - as 
background

material.   If you look at how we wrote 
the BCM specification - we

focused on having Section 1 deliver the meat and 
potatoes immediately.

Here is the method - here is how you use it.  
People do not want to

wade through section after section looking for the 
critical detail.

 

I'd like to see us do the same with ebSOA - introduce our central

vision of how ebSOA works in Section 1 - and then 
the remaining

sections providing supporting details.

 

If we are going to base our vision on GS/BUP (which 
I believe is

the right approach BTW) - then that must be first. 
And we have

examples to draw on - how to take SOA and configure 
POA or

EPR solutions for example.

 

Mentioning work - there are hunderds of hours done 
already on

EPR - and so we have foundations here to draw on - 
I will be 

posting a link shortly to the BCM/EPR presentation 
for Norway

that shows the kind of deployment that we see ebSOA 
supporting.

 

It is not just the Automotive industry here that 
needs answers.

We can find very comprehensive analysis and design 
requirements

extensively defined right here in the work of other 
OASIS TCs!

The eHealthcare is but one example - then there are 
eGovernment

service solutions and more.

 

We have made significant progress in these last six 
months to

being able to model and produce XML templates and 
scripts

that enable the types of patterns that GS/BUP can 
deliver.

We certainly should not wait 18 months before 
exploiting 

these techniques here for ebSOA!!

 

Thanks, DW

  
----- Original Message ----- 

  
From: 
  Hamid Ben 
  Malek 

  
To:  

  
Sent: Thursday, June 10, 2004 1:31 
  AM

  
Subject: [ebsoa] 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