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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

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


Subject: Re: Parties and Partners


Murray,

See notes below.

Thanks, DW.

Message text written by Murray Maloney
>
Again, there seems to be confusion. The eCo model provides a 
framework into which ebXML can fit -- almost as it is.
Since ebXML depends so heavily on Reg/Rep, I am again confused
by the comments about people being afraid of directories.
I get the impression that you have some concept called 'Net Market'
that has some baggage attached to it. I don't want one of those.

>>>>>>> Sorry - my wrong on not explaining this clearly - I jumped
                 to the UDDI model of directories - from a market party
                 needing to be a player - so lets nix NetMarket related
                 thoughts altogether - we're agreed on that.

>
>We should support a pair-wise private model just as 
>easily as a distributed marketplace model, and we
>should be deriving primatives that transcend any 
>one particular model - the Lego bricks.

The eCo model support pairwise commerce with less overhead than ebXML
-- that is, there is no absolute reliance on a Reg/Rep. Rather any 
two parties can discover each other, share information about their
business services inerfaces, and proceed with conducting transactions.
As far as I can tell, ebXML has some restrictions built in that
make it harder to build distributed marketplaces and private ones too.

>>>>>>>> We have to separate out the role of the Registry as a 
                   publicly exposed architectural technology facilitating 
                   interface, and the Repository aspects that can
potentially
                   store business information such as a TPP.   The
distributed
                   marketplace model is one only lightly touched on in the 
                   current TA spec, and obviously there is much work to be 
                   done in this area for RegRep.  

                  TRP have been promoting the registry-less interchange
                  model too.  But the initial discovery and configure phase
                  does require the registry - and my recollection is that 
                  conceptually the eCo approach also provisions for
                  registry and registry discovery.   I think its a question
of
                  implementation and semantics again.  If a 'registry' is
as
                 simple as an ebXML compliant XML doc' residing in a
                 sub-directory off a Web Server, then we are in alignment
                 too.   Again - right now RegRep is still looking at 
                 interface spec's here, we have a ToC interface in
progress,
                 and I'm sure post-Tokyo we'll have a lot more in place.

Thanks, DW.


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC