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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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


Subject: RE: FW: Proposal: A Registry Browser GUI tool/Spontaneous Businessrelationships


Here are some of my thoughts (Strange thread heading - we are off the spirit
of the thread heading miles ago ;-)!):

>
> All,
> what is in my head now on the base PP/Spontaneous Business relationships
> are:
>
> -> A Party has one PartyProfile.
> That PP *may* be registered into a Registry. We may consider
> defining an InfrastructureBusinessProcess with specific technology for
> obtaining
> a PP directly from a Party once you know of the business. Results of this
> request could be "here is my PP", "I maintain my PP in this
> Registry, so go
> here",
> etc.

The parties themselves can and most probably should host a regrep as well.
So theoretically we can use the regrep calls to query and get details.
Actually we do not care whether the party hosts a regrep or not so long as
we get an answer to the generic "give me the profile for company X"
question. The company X can be the party (and so we do not need a give me
your profile message).

As this discussion is around the messaging I am not going to go in detail
about how to discover parties and bootstrap a communication. We should have
a set of generic discovery messages (I assume the BP is the place to add
them) so that this process is covered. I saw a sketch authored by David on
this. We need to expand it and include in the appropriate document. IMHO,
dynamic discovery and spontaneous business relationships are very important
and that *is* one of ebXML's contributions. David, more thoughts ?

The key question here is "A party has *one* PP".

>
> -> A PartyProfile contains one BusinessProcessCollection. I'm suggesting
> this as an
> explicit entity in order to keep the supported BusinessProcesses
> within one
> containment
> in the Profile, in order keep the door open for a Party to present other
> information in the
> Profile not related to BusinessProcesses.
>

I assume you mean an identifiable business process (I liked this - as
opposed to popular - during our con call last week) And a party can support
many standards for a business process for example submit PO can be via
Ariba/CommerceOne or RosettaNet. How do we handle this ?

> -> The BusinessProcessCollection contains BusinessProcessDescriptors.
> A BusinessProcessDesciptor contains one reference to an
> IdentifiableBusinessProcess,
> which could be a reference into a Registry for a RegisteredBusinessProcess
> (default), or
> some user-defined way (same issue as Partyid and URI default).
> A BusinessProcessDescriptor also contains a list of steps/actions that the
> business
> supports within that IdentifiableBusinessProcess. Each supported
> step/action contains
> a list of technology capabilities (perhaps ranked to support spontaneous
> business
> invocation success likelihood) that indicate what *can* be used, not what
> *will* be used.
> None of this is an agreement, and all of it is associated with a Party.
>

I do agree on the differentiation "can" be used Vs "will" be used. The "can"
will change to "will" once a tpa is signed.
If we put BusinessProcessDescriptors, then we need to add
BusinessProcessSteps which in turn contain BusinessProcessMessages.

This is because, each message could have different protocols. For example
normal response by http and error by e-mail. Also each BusinessMessage can
have multiple protocols as well i.e. send me errors by http *and* e-mail.

We can go into more detail at the appropriate time to define the attributes.

> Further, we would define several more InfrastructureBusinessProcesses to
> facilitate
> "coming to an IdentifiableAgreement" instance (which *may* be
> registered in
> a Registry or held
> privately as long as its identity makes sense to the involved Parties)
> to be used for future business transactions between those
> specific Parties.
> (This leads to more thought on required underlying
> InfrastructureCommonErrors, etc....)
>
> Thoughts?
>

Again, extending my prev thoughts, nothing stops one from having a private
registry. What do you mean by InfrastructureBusinessProcesses ? Aren't we
mixing two concepts/crossing abstraction layers ? I thought
businessprocesses run over infrastructure.

I actually have more, but in the spirit of brief e-mail, I will wait for a
better opportunity ....

cheers
----------------------------------------------------------
       |          |             Krishna Sankar
      :|:        :|:            Member of technical Staff
     :|||:      :|||:           Internet Commerce
 ..:|||||||:..:|||||||:..       (Ph) 408-853-8475
    Cisco  Systems Inc          ksankar@cisco.com
----------------------------------------------------------
"Failure is certain if we don't,
           but Success is uncertain even when we do.
                         So the choice is Ours, always..."
----------------------------------------------------------



[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