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