tks, see my replies below
Claire Fahy wrote:
> Hi Pierfranco,
> After having studied your sequence diagram, we still have some outstand=
> 1) What component will do the announcement, "set-up" or "console"=20
the setup will do the announcement (creating the instance from the model
which is different from the invocation), i.e. the setup will prompt the
user with the proper UI. Other components, as for the diagram, will
handle/complete the operation, it's a shared responsibility
> 2) Is the negotiation announced (publicly) by placing on the DKB?
the announcement is the announcement. i.e. the instance is to be placed
in the DKB no wander. Another matter are the runtime information; read
The on-going discussion with Jason about using the soapod registry for
the runtime data (essentially the fact that a model instance exists and
where is to be run) will address this issue.
> 3) How is the negotiation privately announced, where (i.e. what compone=
> is the invitation coming from?=20
good point, the negotiation console shall IMO as soon as it receives the
> 4) Should the private negotiation be stored in the DKB?
We have to
>If so, will access
> to this entry in the DKB require a secure login?
=46rom the "Bible" (W1.2) I read "Private Negotiation A negotiation where=
only predefined participants can join."
Hence there is no specific need to handle private negotiations
differently, apart that only invited participant can join.
> 5) How are private invitees invited, for example: email, MyONE..?
We can just stick to the email at the moment
> 6) When is the negotiation started, after or before announcement?
It depends about what we mean by "started": there an issue related to
period that goes from the time the negotiation is announced and the
date-time where the readiness superstage begins living in the engine.
I suggest we "start" the negotiation just after the announcement but
does not exit the initial state until the "date-time start of the
negotiation" (can we call it "initiation of the negotiaiton"?) is reached=
> 7) What component triggers the start of the negotiation?
as a descendant of the previous point the setup informs the negotiation
engine of the announcement which in turn it loads the state-machine in
memory. In the meantime (from the start till the initiation of the
negotiation) it can do some homework such as:
- synchronizing with the backup node
- updating the soap registry
> 8) What is the information available to the users with the announcement=
> negotiation (private and public case)? We have made a preliminary list =
> info that could be presented:
> a) Title/Description of negotiation (comes from negotiation
> b) Negotiation ID
> c) Current state
> d) Owner name
> e) Negotiation Description
I recall that the announcement is the phase that makes a model to become
an instance (values related to the models are added), it's not another
state of a negotiation, hence the question is related to "what
attributes a negotiation instance has" which has already been answered I
Another question might be related to which runtime data we have. These
are still in the M0 (there is no M-1 :)), but in a different "package".
At any rate the runtime are (partial list):
- the participants
- the time since the start
- the time till the end
- the state the negotiation is in (relative to the protocol state
machine) and all the variable that it's made of (it depends on the model)=
> Obviously there will be a need to maybe link into area where "further
> information" is available. This might detail "items", "issues", "criter=
> and "attributes".
sure these are all runtime information
> 9) What information will need to be updated from the engine to the DKB?=
> have come up with the preliminary information:
> a) State
> b) Superstate
> c) Issues
> d) Criteria
> e) Attribute
> f) Offer
I believe (unless I misunderstand you) we do not have to put these
information in the DKB. These details can be obtained in the "show
details" of a negotiation instance and gathered by asking the
negotiation node directly (the node where the engine is running).
But surely the DKB will receive the log at the end.
> I've attached a sequence diagram (.jpg) with a number of possible
> alternatives for the "Announce/Deploy" sequence. I haven't added this t=
> EA repository yet until we fully agreed it. I also didn't integrate it =
> your sequence diagram (the node delegation process..etc) yet just to tr=
> keep it less complicated for the moment. I will add that our preference=
> would be "Alternative 1 "!
> I hope this helps,
Sure, thank's lot
I'm digging in the sequence, be back soon
> -----Original Message-----
> From: Pierfranco Ferronato [mailto:pferronato@...
> Sent: Wednesday, November 14, 2007 5:27 AM
> To: Jason Finnegan
> Cc: ONE Project Developer Mailing List; Claire Fahy; Andrea Danzi; Shan=
> Dempsey; Sonia Rigo
> Subject: Re: annoucement
> I'm in a hurry, will reply 15/11/2007, in any case the sequence is unde=
> the component "setup" insider the "component model" viewpoint.
> Kind Regards
> Pierfranco Ferronato
> CIO and Founder
> Innovation in Action
> Tel: +39-0423-915547
> Fax: +39-0423-915547
> ICQ: 297565827
> Skype: pferronato
> The information transmitted is intended only for the person or entity t=
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or=
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and delete the
> material from any computer.
> Jason Finnegan wrote:
>> Hi all,
>> I think we agree on everything apart from whether Soapod should contai=
>> the up-to-the-minute status information or just a pointer to a DKB whe=
>> this information is known to be up to date.
>> For soapod and any other DHT based system it is best to add data that
>> will change as little as possible. Our approach means only two updates=
>> to the DHT for each Negotiation (start and Finish).
>> However maintaining status information in the DHT(soapod) would requir=
>> possible hundreds of updates which could occur in a short amount of ti=
>> and cause problems.
>> (i'm assuming status information would include current state, highest=
>> offer received, if an open auction)
>> If a user were to search for all Negotiations with the tags "building"=
>> "cleaning" and got back 10 matches, then only these 10 DKB's would nee=
>> to be called once, with no updates required, which will scale better
>> than trying to keep sopaod updated with possibly thousands of concurre=
>> negotiation status changes.
>> PS. Pierfranco we have not been able to find your Setup sequence Diagr=
>> in EA, where exactly is it?
>> Pierfranco Ferronato wrote:
>>> Hi all,
>>> we can not assume and rely on DKB sycronization protocol, we have to
>>> go our way IMO despite the DKB approach.
>>> Said that we already agree that SOAPOD registry is the way to go.
>>> My first comment is that it has to index not only negotiation
>>> processes but also negotiations that have been announced. These two
>>> are logically separated items but could be merged if we assume that
>>> the Engine is going to start a negotiation just after the annoucement=
>>> even if it has not started yet. I'd support this approach that is
>>> in-line with my setup seq. diagram in EA.
>>> I'm unsure I have understood the approach you suggest, I try to recap=
>>> the consequence:
>>> - the Portal receiving a "list all negotiation instances" will call
>>> the DKB for the list of negotiation and get the list of the
>>> negotiation processes from the SOAPOD registry, but *THEN* from every=
>>> item in the latter it'd also query the nodes where the up-to-date
>>> status information reside. If this is a correct consequence of what
>>> you suggest I'd warn that this would generate a large number of
>>> distributed calls to DKB nodes.
>>> Alternatively, sdding the status information straight in the SOAPOD
>>> registry will not signifincantly affect the payload 'cause the
>>> information to be added, if wisely planned, will be just a few bytes.=
>>> And the list of updated negotiation instances will require just
>>> calling the SOAPOD registy and the DKB *ONCE*,
>>> Jason Finnegan wrote:
>>>> Hi Pierfranco and others,
>>>> We also assume that the DKB may not be fast enough for real time
>>>> searches of current negotiation status. Without further information
>>>> on exactly how DKB data will be replicated we cannot be sure how muc=
>>>> faster Soapod updates will be.
>>>> We had some discussions here and came up with the following proposal=
>>>> The Soapod service registry should contain an entry representing the=
>>>> Owner process for every public Negotiation. (this is an addition to
>>>> one entry for every user for routing messages)
>>>> this entry would have a key of the Negotiation_ID (a UUID)
>>>> and the value would be an XRI representing the location of the
>>>> current status information for that negotiation on the Owners
>>>> designated DKB (probably the owners local DKB).
>>>> This means the searching user would be able to look for the status
>>>> information in the DKB where it will be updated first. Also if this
>>>> designated DKB service is not found, using an XRI means the status
>>>> information could be looked for on any other DKB node (which may not=
>>>> be fully up to date).
>>>> If a user wanted to do a search for Negotiations based on keywords w=
>>>> can use the tagging facility of Soapod,
>>>> This approach would bypass any delays in replication of data in the
>>>> DKB, without overloading the Soapod service registry with extra data=
>>>> Before proceeding it would be good to have a more detailed picture o=
>>>> how the DKB data replication is to be implemented. Given that Soapod=
>>>> already implements a DHT it might be reasonable for us to coordinate=
>>>> to produce a consistent overlay with the DKB.
>>>> Pierfranco Ferronato wrote:
>>>>> in the EA repository, the Negotiation Setup has a nested sequence
>>>>> diagram describing the scenario of this functionality named
>>>>> The goal here is to identify the dependencies and the
>>>>> responsibilities across the various components.
>>>>> An isse here is related to the distribution of the information abou=
>>>>> the announced negotiation. My concern is related to the fact that
>>>>> the DKB might not be very fast in updating the entire DKB nodes and=
>>>>> some participant might miss these critical information. In addition=
>>>>> the actual "start" event of the negotiation is to be very timing,
>>>>> the DKB again might not be fast enough. What I suggest here is to
>>>>> used the service registry of SOAPOD, not only for indexing ONE node=
>>>>> but also for keeping track of the running negotiations. It could
>>>>> keep an index made of negotiation id and it's status (and some more=
>>>>> information), keeping the heavy-load information in the DKB. The
>>>>> registry can then be used to promptly inform users via the Portal
>>>>> that a negotiation has been announced, is started or has been
>>>>> The -small- draw back is that the functionality of the Portal that
>>>>> lists the negotiation instances (coming from the DKB) need to be
>>>>> added with information coming form the registry.
>>>>> This would requires to implement a P&S mechanism in SOAPOD avoiding=
>>>>> the portal or other components to constantly poll the registry
>>>>> Any comment?
>>>>> Best Regards