21 messages in org.oasis-open.lists.ebsoaRe: [ebxml-bp] Re: [ebsoa] Re: [ebxml...| From | Sent On | Attachments |
|---|---|---|
| Duane Nickull | Apr 23, 2004 3:07 pm |  .pdf |
| David RR Webber | Apr 23, 2004 6:21 pm | |
| Anders W. Tell | Apr 24, 2004 1:22 am | |
| Duane Nickull | Apr 24, 2004 5:09 am | |
| Duane Nickull | Apr 24, 2004 5:20 am | |
| Duane Nickull | Apr 24, 2004 5:28 am | |
| David RR Webber | Apr 24, 2004 8:11 am | |
| Anders W. Tell | Apr 24, 2004 9:48 am | .pdf |
| Anders W. Tell | Apr 24, 2004 9:49 am | |
| David RR Webber | Apr 24, 2004 12:33 pm | |
| Monica J. Martin | May 4, 2004 12:18 pm | .pdf |
| Duane Nickull | May 4, 2004 12:43 pm | |
| Duane Nickull | May 4, 2004 12:45 pm | |
| Duane Nickull | May 4, 2004 3:28 pm | .pdf |
| Anders W. Tell | May 8, 2004 3:49 am | |
| David RR Webber | May 8, 2004 11:15 am | |
| Chiusano Joseph | May 9, 2004 11:00 am | |
| Monica J. Martin | May 9, 2004 11:35 am | |
| David RR Webber | May 9, 2004 2:15 pm | |
| Duane Nickull | May 10, 2004 10:05 am | |
| David RR Webber | May 10, 2004 10:10 am |
| Subject: | Re: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] eBusiness Metamodel EARLY DRAFT 0.03 | |
|---|---|---|
| From: | David RR Webber (dav...@drrw.info) | |
| Date: | Apr 24, 2004 8:11:58 am | |
| List: | org.oasis-open.lists.ebsoa | |
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" <dnic...@adobe.com> Cc: <ebs...@lists.oasis-open.org>; "ebXML BP" <ebxm...@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" <dnic...@adobe.com> To: <ebs...@lists.oasis-open.org> Cc: "ebXML BP" <ebxm...@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