[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [regrep] BIEs re-visited.
Joel, Good question! Now I feel like the weather man!! Maybe I should have waited until after the document from Barcelona was available. I too am now confused - just when I thought I had this down. What Duane is describing does seem to be a different animal, and the complicated behaviour I'm not sure on - seems like we would like something simpler - not being a fan of complexity! Arrows and boxes on UML diagrams can take some unravelling! I'd been shown a totally different one to the one Duane posted!! Here's some further notes in hope of flushing out the meaning. The CCR team had create a default mapping to XML to store CC's, and had realized there are logical CC's (like the ones in the already published spreadsheet/doc table) - and physical CC's that are associated with those that capture the business context - and manifest themselves in existing libraries today (OAG BODS, EDI, etc). Seems to me that these physical instances of logical ones are very close to being BIEs. The CCR team had been relying simply on the Association mechanism to provide linkage between the logical and physical - and then all the behaviours that Duane was mentioning fall out of the hat very neatly. Even cross Registry association. However there is no way for a Core Component in one Registry to know who has linked to it somewhere else out in cyberspace. That would be unenforceable in anycase. To fix that - one could ask that people who do links - register with that master registry and tell it the location of theirs. At least then that Registry could do an extended query into those remote registries to see if any associations pointed at its content. But this could only be a courtesy mechanism - not mandatory. Back to what I posted: seems like what I described was actually aggregated BIEs. There may or may not be a one to one correspondence between aggregated CC's and aggregated BIEs. So - looks like we need both - just we need to understand the relation. Thanks, DW. =========================================================== Message text written by "Munter, Joel D" > Now I am a little confused. It may be just semantics but Duane just stated that a BIE is a child of a Core Component and, in the origin of this thread, David said that a BIE is a re-usable collection of core components with optionally associated passive context. Which is it? Joel -----Original Message----- From: Duane Nickull [mailto:duane@xmlglobal.com] Sent: Friday, May 17, 2002 9:41 AM To: David RR Webber - XMLGlobal Cc: Lisa Carnahan; OASIS Registry List Subject: Re: [regrep] BIEs re-visited. I am glad that you all are talking about this topic. 1. One thing that would be nice for Design Time is for a Business Collaboration Designer (new title??) to be able to query the Registry for a list of BIE's that are children of a single Core Component AND are subject to a single or set of context rules. Becuase the list is possibly very large, it may be nice to have an ability to set parameters for the query results: eg. - return only 10 results at a time and only return the URI of each BIE. Also - what is the sort order???? hmmm???? 2. This should be a function of the Registry itself via "associations". Agreeably, a BIE should also know what Core Component is its' parent. I would argue that this should be in the BIE itself, not only the RIM so the BIE still contains that information once it is used outside the Registry. 3. In cases where their are several Registries whose content is not synced, how will a user get a list of all BIE's made from a specific Core Component? Can result sets be merged? There may be an onus on the Principle Registry of the Core Component to keep track of all of this via its' associations mechanism. Just some thoughts (probably to keep some of you up an night ;-) D- <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC