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