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