OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] eBusiness Metamodel EARLY DRAFT 0.03


Duane,

Concur.

Some other thoughts - missing pieces - linking and switching and tracking
state
(remember ebXML 1.0 was binary collaboration only - so did not need much
of those pieces to run just ping-pong style interactions).

Thinking of your diagram as a cut-away of your Porsche.... what needs to be
in the main diagram as opposed to a separate diagram?

For my money the core component stuff is a little bit like an inset into the
carborettor showing the vapor droplets inside the inlet nozzle -
interesting -
but probably something that goes into a separate diagram better.

In fact there's probably four or five sub-diagrams here - since Registry is
another
major missing peice - especially if you use Registry like in the CDC
scenario...
probably worthy of a second main diagram.

In fact one could make the case - a la BCM - that the registry is the
central
component - and everything else revolves around that.  Very different from
the
ebMS-centric diagram...

Thanks, DW.

----- Original Message ----- 
From: "Duane Nickull" <dnickull@adobe.com>
Cc: <ebsoa@lists.oasis-open.org>; "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Saturday, April 24, 2004 8:46 AM
Subject: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] eBusiness Metamodel EARLY
DRAFT 0.03


> To sum this up:
>
> 1. The BOV layer should be done to capture the needs of businesses.
> 2. The BOV layer and requirements MUST be supported by the FSV.
> 3. Architecture maps the BOV to the FSV
> 4. If the FSV does not support the BOV, the architecture and FSV
> components are incomplete/broken and need to be fixed.
>
> sounds a lot like BCF, BCM, UMM, ebXML et al so far.
>
> Therefore, I assert that we need to forensically capture the FSV as of
> today in order to compare it to the BOV (when done) on order to
> determine what further work is needed.
>
> Remember, it is only v 0.03.  John Yunker has graciously stepped up to
> the plate to help too (thanks John!!!)
>
> cheers
>
> Duane
>
> David RR Webber wrote:
>
> >Duane,
> >
> >Phew - yuk!
> >
> >I'd like to propose we start with a business-centric view first.
> >
> >I'm not sure any of this implementation layer makes any sense
> >at all any more.  Having lived this for five years - this
> >UML diagram has an other-worldly old-story feel to it.
> >
> >But I know you like it so that's OK - its a technologist
> >eye view on the relationships!
> >
> >I believe we need to understand how the big picture
> >collaboration happens between components - to
> >serve the SOA goals - and be able to deliver that
> >for people too.
> >
> >One things we've learned via BPSS work is handling
> >signals and events is critical - and I'm not sure that
> >aspect is "in there" in the UML - or even if UML can
> >do that well - from some of the comments on the BPSS
> >list.  I like especially JJ's post about the third wave of
> >software - that is message oriented (hence pi-calculus) -
> >and how the SOA needs to support that - and tools
> >like Microsoft XAML....yet provide a business
> >perspective.
> >
> >Alot of what you've put in may just not be applicable / or
> >even work - for a given implementation - and its
> >impossible to decouple for people the way you have
> >it drawn.  I much prefer something like the Lubash
> >Pyramid - that shows the hierarchy without committing
> >to strict dependances.  The world is more sophisticated -
> >and handling PDAs and more in the picture - requires
> >more flexible architecture thinking - or at least something
> >people can grok conceptually - and be able to visually
> >relate to their project deployment model...
> >
> >This time around I'd personally prefer to see more of
> >the business vision driving the technology implementation -
> >whereas before the OO / UMM / UML driver seemed
> >to tilt things too that technology side.
> >
> >But you are right - it does provoke discussion!!!
> >
> >DW.
> >
> >----- Original Message ----- 
> >From: "Duane Nickull" <dnickull@adobe.com>
> >To: <ebsoa@lists.oasis-open.org>
> >Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
> >Sent: Friday, April 23, 2004 6:25 PM
> >Subject: [ebxml-bp] eBusiness Metamodel EARLY DRAFT 0.03
> >
> >
> >
> >
> >>If 1.0 is a release, ready for public draft, please consider this a
0.03.
> >>
> >>The purpose is to capture the state of ebXML, WS, CEFACT and
> >>requirements of business.  The concepts on this can be mapped back to
> >>the ebXML Requirements document.
> >>
> >>We may not have time to discuss this in NO but it is interesting to
view.
> >>
> >>Please note that the names of certain items do not necessarily
> >>correspond to the names of the work governing them.  For example, the
> >>OASIS CAM work MAY be potentially used as the way to constrain Business
> >>Payload Metadata. I do not make any implied warranties as to such being
> >>true or false.
> >>
> >>There are also several departures from existing ebXML groups.  The
> >>details for "TimeToPerform" have been  subclassed to a class of their
> >>own since they are used by the BusinessCollaboration, CPP, CPA and
> >>BusinessProcess classes.  I have added two attributes for value and
> >>qualifier (units of measure).  This is to cater to both short and long
> >>running business processes/collaborations.  We cannot always assume it
> >>would be expressed in days (not precise enough for some) or seconds (the
> >>instance values may become unmanageable if you have something that runs
> >>7 years (220,752,000 seconds).
> >>
> >>As per Dale's message, we may have already identified some unnecessary
> >>containership.
> >>
> >>Comments, flames, suggestions, etc may be directed at me in person in
> >>new orleans.
> >>
> >>Duane Nickull
> >>
> >>-- 
> >>Senior Standards Strategist
> >>Adobe Systems, Inc.
> >>http://www.adobe.com
> >>
> >>
> >>
> >>
>
> -- 
> Senior Standards Strategist
> Adobe Systems, Inc.
> http://www.adobe.com
>
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]