one-project-devel — ONE Project Developer Mailing List

[One-project-devel] Action Language features

[Pierfranco F. <pfe...@so...>]

Hi,

today the wiki of sourceforge is lazy or there is some trouble with the
DNS out-there since other sites are not reachable, for this reason I
post here what I was trying to write in the wiki.

Essentially I want to define some features the Action Language has to
support (namely BeanShell).

Be able to access some negotiation related "environment variables" to
access the following informations, others such as the actual system
time-date are already available in BeanShell:
- date-time to the end of the negotiation [R/W] (this shall be in the MM)=

- date-time of the start of the negotiation (this shall be in the MM)
- list/array of the partners that joined the negotiations [R] (this
shall be in the MM) this has to be available only to the owner
- the winner of the negotiation [R]
- owner of the negotiation [R] (this shall be in the MM)
- IP/name of the ONE Node running the script [R]
- IP/name of the ONE Node owning the negotiations [R]

Other abilities:
- able to connect the public data on the DKB [R]
- sending emails, sending messages when in the Acceptance stage

Other variables
- all the attributes of the negotiation model [R/W or R/O this depends
on the kind of variable]
- all the instances of item defined/used in the model[R/W]
- read the state of the currect state machine (where the script is
running) [R]

We have to agree and work on this list (some more might be added
jointly), to decide how to implements them, who will implement them and
when. We can bring this discussion on the Tuesday conference call,

Kind Regards
Pierfranco

[R/W] Read and Write
[R]   Read only

--=20
Soluta.net

Pierfranco Ferronato
CIO and Founder
Soluta.Net,Italy
Innovation in Action
http://www.soluta.net

Tel: +39-0423-915547
Fax: +39-0423-915547
ICQ: 297565827
Skype: pferronato

The information transmitted is intended only for the person or entity to
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.

Re: [One-project-devel] transitions in the protocol model

[Pierfranco F. <pfe...@so...>]

Hi,

I found myself saying "transitions", while I was referring to
negotiation messages; this brought some confusion in the discussion,
also to me. I apologize for the mistake.
The event/message based communication as described in the MM is fine,
it's as complex as it has to be, the notation in the Editor will be
improved and made easy as much as possible given its semantic meaning,

best regars
Pierfranco

Claire Fahy wrote:
> Hi Pierfranco,
>=20
> As far as I understand due to the distributed nature of the ONE environ=
ment,
> the decision was to apply a "state-machine" methodology as opposed to a=

> "workflow" methodology.  As such, the meta-model complies with state-ma=
chine
> conventions.
>=20
> I understand that you feel that state-machine conventions may not be ve=
ry
> "usable" but I believe there are many helpful additions that could be
> included in the factory graphical representations without re-designing =
the
> meta-model to manage a hybrid of workflows and state-machines.  For exa=
mple:
> each transition represents a change in state caused by either an event =
or
> action, perhaps these transitions could be colour-coded to indicate tha=
t the
> transition is an event or action.
>=20
> Just trying to answer some of your questions:
> " Why is the MM linking transition with stages which in turn contain th=
e
> actions?" This is a state-machine formalism. Please note the transition=
 is
> associated with an action or event. I'm not sure I understand why you w=
ould
> consider actions within stages a constraint?=20
>=20
> "seeing arrow from stage to stage and from there to actions is misleadi=
ng
> and hardening the comprehension of the model"=20
> I think this is an issue which we really should ask our user group to
> comment on i.e. Coopservice. But at an initial look, I do understand th=
at
> using terminology like "ingress" and "egress" in the factory may of cou=
rse
> cause problems to a business user (as opposed to a computer scientist).=
 A
> suggestion would be to change these to more "technology agnostic" seman=
tics
> such as "Entry action" and "Exit Action". This is a simple change that =
could
> be made as part of the factory. Also I thought it was agreed in the
> Waterford, that it would be possible to just include graphical
> representations (such as a dotted line arrow) to indicate a "send messa=
ge"
> from one user and "receive message" at the receiver. Another possible w=
ay to
> materialise the idea of the dependency between the two behaviours
> (state-machines) is: When the designer add an action "SendMessage()" in=
 one
> side (Owner or Participant), the editor can suggest to him by opening a=

> popup (or something similar) to add an event "ReceiveMessage" in the ot=
her
> side. That could be one of the help facilities that the tools provide t=
o the
> users.
>=20
> You must remember also that the run-time uses the concepts of the meta-=
model
> also so including such formal communication messaging between state-mac=
hines
> to improve usability in the models will have no meaning to the run-time=
=2E=20
>=20
> Best Regards,
> Claire
>=20
> -----Original Message-----
> From: Pierfranco Ferronato [mailto:pfe...@so...]=20
> Sent: Wednesday, November 21, 2007 11:44 AM
> To: Claire Fahy; Jason Finnegan; ONE Project Developer Mailing List; So=
nia
> Rigo
> Cc: Andrea Danzi
> Subject: transitions in the protocol model
>=20
> Hi all,
>=20
> we are due to improve the Editor with respect of the event notations. W=
e
> wish to show actual arrows going from "create message action" to "wait
> event action": this is what the user shall expect to see since this his=

> the actual desiderata and it'd greatly improve the readability.
> Since the MM defines the transitions to and from Stages instead of
> Events directly, the graphical notation we wish to adopt will differ
> from the MM: we have to show something which will not be reflected in
> the model in the same way, a manual coding is necessary: Java hand
> coding is necessary and this is doable and we ca do it (IT'S NOT A
> MATTER OF SIMPLIFYING OUR EFFORT) but the issue is here another In my
> humble opinion.
>=20
> Why is the MM linking transition with stages which in turn contain the
> actions? What is the criteria here? If we going to customize the editor=

> supporting the MM as it is now, we'd not be in the position of using th=
e
> ecore MM directly: seeing arrow from stage to stage and from there to
> actions is misleading and hardening the comprehension of the model.
> It'be straightforward to see arrow going from action at action straight=

> from the MM.
>=20
> Unless there is something I miss here, please tell me, I'd suggest to
> amend the MM,
>=20
> best
> Pierfranco
>=20

[One-project-devel] EX-Re: [one-all] One Node schematic diagram Now: One Portal

[Matteo B. <mb...@so...>]

Hello All,
As Pierfanco wrote in a schematic diagram, we suggest Jakarta Pluto for 
the ONE-Portal implementation.
We are investigate on a technical infrastructure for the ONE-Portal.
We propose a portal infrastructure compatible with  Java Portlet 
specification (JSR 168)
I try this portal:

    * Jakarta Pluto  [http://portals.apache.org/pluto/]
    * Jakarta JetSpeed [http://portals.apache.org/jetspeed-2/]
    * Light Portal [http://www.lightportal.org:8080/lightPortal/index.jsp]

In this moment we prefer Jakarta Pluto but if some of you know any other 
portal server (compatible with spring, tomact and all ONE architecture) 
please email us.
As soon as we try to deploy a sample one-portal with Pluto environment.

Bye Matteo
 

On 22/11/2007 17.51, Pierfranco Ferronato wrote:
> Hi,
>
> I want to share with you this schematic diagram that was made here
> internally to focus on ONE node runtime dependencies.
>
> The dashed boxes indicate that they are optional elements in a ONE node
> configuration/installation. So do all the "components" installed over
> sopod shown in the right side.
>
> In addition all these component are allowed to "exit" the node to talk to:
> Engine->Engine
> DKB->DKB P2P Network
>
> In case you feel comfortable with this picture I'll publish it in the wiki
>
> best
> Pierfranco
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> One-all mailing list
> On...@cr...
> http://diana.create-net-ml.org/mailman/listinfo/one-all
>   

-- 

Matteo Bordin
Soluta.net, Italy
http://www.soluta.net

Mob:   +39-346-017-9168
Tel:   +39-0423-915547
Fax:   +39-0423-915547
ICQ:   297565827
Skype: matteobordin
**************************************
The information transmitted is intended only for the person or entity to
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.

Re: [One-project-devel] transitions in the protocol model

[Claire F. <cf...@ts...>]

Hi Pierfranco,

As far as I understand due to the distributed nature of the ONE environment,
the decision was to apply a "state-machine" methodology as opposed to a
"workflow" methodology.  As such, the meta-model complies with state-machine
conventions.

I understand that you feel that state-machine conventions may not be very
"usable" but I believe there are many helpful additions that could be
included in the factory graphical representations without re-designing the
meta-model to manage a hybrid of workflows and state-machines.  For example:
each transition represents a change in state caused by either an event or
action, perhaps these transitions could be colour-coded to indicate that the
transition is an event or action.

Just trying to answer some of your questions:
" Why is the MM linking transition with stages which in turn contain the
actions?" This is a state-machine formalism. Please note the transition is
associated with an action or event. I'm not sure I understand why you would
consider actions within stages a constraint? 

"seeing arrow from stage to stage and from there to actions is misleading
and hardening the comprehension of the model" 
I think this is an issue which we really should ask our user group to
comment on i.e. Coopservice. But at an initial look, I do understand that
using terminology like "ingress" and "egress" in the factory may of course
cause problems to a business user (as opposed to a computer scientist). A
suggestion would be to change these to more "technology agnostic" semantics
such as "Entry action" and "Exit Action". This is a simple change that could
be made as part of the factory. Also I thought it was agreed in the
Waterford, that it would be possible to just include graphical
representations (such as a dotted line arrow) to indicate a "send message"
from one user and "receive message" at the receiver. Another possible way to
materialise the idea of the dependency between the two behaviours
(state-machines) is: When the designer add an action "SendMessage()" in one
side (Owner or Participant), the editor can suggest to him by opening a
popup (or something similar) to add an event "ReceiveMessage" in the other
side. That could be one of the help facilities that the tools provide to the
users.

You must remember also that the run-time uses the concepts of the meta-model
also so including such formal communication messaging between state-machines
to improve usability in the models will have no meaning to the run-time. 

Best Regards,
Claire

-----Original Message-----
From: Pierfranco Ferronato [mailto:pfe...@so...] 
Sent: Wednesday, November 21, 2007 11:44 AM
To: Claire Fahy; Jason Finnegan; ONE Project Developer Mailing List; Sonia
Rigo
Cc: Andrea Danzi
Subject: transitions in the protocol model

Hi all,

we are due to improve the Editor with respect of the event notations. We
wish to show actual arrows going from "create message action" to "wait
event action": this is what the user shall expect to see since this his
the actual desiderata and it'd greatly improve the readability.
Since the MM defines the transitions to and from Stages instead of
Events directly, the graphical notation we wish to adopt will differ
from the MM: we have to show something which will not be reflected in
the model in the same way, a manual coding is necessary: Java hand
coding is necessary and this is doable and we ca do it (IT'S NOT A
MATTER OF SIMPLIFYING OUR EFFORT) but the issue is here another In my
humble opinion.

Why is the MM linking transition with stages which in turn contain the
actions? What is the criteria here? If we going to customize the editor
supporting the MM as it is now, we'd not be in the position of using the
ecore MM directly: seeing arrow from stage to stage and from there to
actions is misleading and hardening the comprehension of the model.
It'be straightforward to see arrow going from action at action straight
from the MM.

Unless there is something I miss here, please tell me, I'd suggest to
amend the MM,

best
Pierfranco

-- 
Soluta.net

Pierfranco Ferronato
CIO and Founder
Soluta.Net,Italy
Innovation in Action
http://www.soluta.net

Tel: +39-0423-915547
Fax: +39-0423-915547
ICQ: 297565827
Skype: pferronato

The information transmitted is intended only for the person or entity to
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.

Re: [One-project-devel] Code Logging

[Matteo B. <mb...@so...>]

Hi All,
I suggest the use of "log4j" version 1.2.xx in all one project.
I  would suggest  to use the log4j in standard mode without a  wrapper.
For example  :

package org.one_project.one_neg_mod.test;
....
....
class myclass {
    private Logger logger = Logger.getLogger(this.getClass().getName());

    public void muMethod(){
        logger.trace(messages.getString("Trace"));      //Trace logger
        logger.debug(messages.getString("Debug"));    //Debug logger
        logger.info(messages.getString("Info"));            //Info logger
        logger.warn(messages.getString("Warn"));      //Warn logger
        logger.error(messages.getString("Error"));      //Error logger
        logger.fatal(messages.getString("Fatal"));            //Fatal logger
    }
}

We use the getLogger() with class name because it will be easy to enable 
or disable log for a particular one-application.
I would propose also to use java internationalization[1] for the log 
message, or put the message into a specific class, we suggest to not 
hard-coded the message.

For any problems/question/propose do not hesitate to email .

Bye
Matteo

[1]: http://java.sun.com/docs/books/tutorial/i18n/index.html

On 21/11/2007 21.58, Pierfranco Ferronato wrote:
> fine for me
>
>
> Claire Fahy wrote:
>   
>> Hi All,
>>
>>  
>>
>> The process of adding appropriate logging to our engine and
>> transformation code is beginning here.
>>
>>  
>>
>> In order to be compatible with all, I just wondered if there is a
>> standard logging framework being used across the project? I would
>> suggest the use of “log4j”, any opinions?
>>
>>  
>>
>> Best Regards,
>>
>> Claire
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> One-project-devel mailing list
>> One...@li...
>> https://lists.sourceforge.net/lists/listinfo/one-project-devel
>>     
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> One-project-devel mailing list
> One...@li...
> https://lists.sourceforge.net/lists/listinfo/one-project-devel
>   

-- 

Matteo Bordin
Soluta.net, Italy
http://www.soluta.net

Mob:   +39-346-017-9168
Tel:   +39-0423-915547
Fax:   +39-0423-915547
ICQ:   297565827
Skype: matteobordin
**************************************
The information transmitted is intended only for the person or entity to
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.

[One-project-devel] One Node schematic diagram

[Pierfranco F. <pfe...@so...>]

Hi,

I want to share with you this schematic diagram that was made here
internally to focus on ONE node runtime dependencies.

The dashed boxes indicate that they are optional elements in a ONE node
configuration/installation. So do all the "components" installed over
sopod shown in the right side.

In addition all these component are allowed to "exit" the node to talk to:
Engine->Engine
DKB->DKB P2P Network

In case you feel comfortable with this picture I'll publish it in the wiki

best
Pierfranco

-- 
Soluta.net

Pierfranco Ferronato
CIO and Founder
Soluta.Net,Italy
Innovation in Action
http://www.soluta.net

Tel: +39-0423-915547
Fax: +39-0423-915547
ICQ: 297565827
Skype: pferronato

The information transmitted is intended only for the person or entity to
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.

Re: [One-project-devel] annoucement

[Pierfranco F. <pfe...@so...>]

Hi,

reply follow sbelow:

Claire Fahy wrote:
> Hi,
>=20
> Some replies to below:
>=20
> 1) It seems strange that the Negotiation Setup would handle the public
> announcement and not the private invitation? The setup will have access=
 to
> the "contact list" as it also part of "MyONE" so maybe it would make mo=
re
> sense to handle the invitation?
yes I understand and I had just a concern (when I thought about it)
about the fact that invitation has to be done only when the negotiation
engine is up and running and properly set up. If we keep this operation
in the setup we have to implement a sort of "transactions" (allow me to
use this term) in order to be guaranteed before sending invitation that
the engine in the right node is ready. My idea of leaving the invitation
in the Engine has this objective. Technically it is as simple as
retrieving the participants list from the DKB (the model instance has
already be stored) and using a proper component or framework of the ONE
Node that will take care about sending the emails.
What'd you suggest?

> 2) "there an issue related to period that goes from the time the negoti=
ation
> is announced and the date-time where the readiness superstage begins li=
ving
> in the engine. I suggest we "start" the negotiation just after the
> announcement but does not exit the initial state until the "date-time s=
tart
> of the negotiation" (can we call it "initiation of the negotiaiton"?) i=
s
> reached."
>=20
> We should just ensure the understanding of the "start-date" (however it=
 will
> be described in the model) can not be misconstrued by the participant.
> Otherwise he/she may miss their admission opportunity (if they believe =
that
> the start-date refers to the very start of the negotiation, not just th=
e
> "readiness" stage).
OK
>=20
> 3)Sorry my question 8 was a little unclear, I meant what information wo=
uld
> be "visible" (on the GUI) to the participant when he/she checks the rec=
ent
> negotiatons? We checked a few similar websites (for eg.,
> http://www.e-tenders.gov.ie/search/search_mainpage.aspx) and came up wi=
th
> the suggested list below.
OK, I can suggest "the time till the _expected_ end", "item negotiated"?
>=20
> 4) I think we can agree on the updating of info from the engine to DKB.=
 The
> only concern we would have is the issue of node redundancy (in the even=
t
> that the owner node fails during negotiaton), although I guess you've
> handled this with your "backup" node.
yes

>One of the main reasons we asked
> initially was because you included an "Update" message in your sequence=

> diagram between engine and DKB - was this referring to logging (or of
> course, changes in the Information model due to the addition of issues =
at
> runtime) once the negotiation is completed?
BWT: I was assuming the announcement follows the storing of the
negotiation instance in the DKB

I was considering the update of the address of the engine node, nothing m=
ore

kindly
Pierfranco
>=20
> Thanks for your help,
> Best Regards,
> Claire
>=20
> -----Original Message-----
> From: Pierfranco Ferronato [mailto:pfe...@so...]=20
> Sent: Tuesday, November 20, 2007 12:54 PM
> To: Claire Fahy
> Cc: 'Jason Finnegan'; 'ONE Project Developer Mailing List'; 'Andrea Dan=
zi';
> 'Shane Dempsey'; 'Sonia Rigo'
> Subject: Re: annoucement
>=20
> Ciao,
>=20
> tks, see my replies below
>=20
> Claire Fahy wrote:
>> Hi Pierfranco,
>>
>> After having studied your sequence diagram, we still have some outstan=
ding
>> questions:
>> 1) What component will do the announcement, "set-up" or "console"=20
> the setup will do the announcement (creating the instance from the mode=
l
> 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
> below.
> 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.
>=20
>> 3) How is the negotiation privately announced, where (i.e. what
> component?)
>> is the invitation coming from?=20
> good point, the negotiation console shall IMO as soon as it receives th=
e
> annoucement
>> 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?
>>From the "Bible" (W1.2) I read "Private Negotiation A negotiation where=

> only predefined participants can join."
>=20
> Hence there is no specific need to handle private negotiations
> differently, apart that only invited participant can join.
>=20
>> 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 reach=
ed.
>> 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
>=20
>> 8) What is the information available to the users with the announcemen=
t of
> a
>> negotiation (private and public case)? We have made a preliminary list=
 of
>> info that could be presented:
>> 	a) Title/Description of negotiation (comes from negotiation
>> instance)
>> 	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 becom=
e
> 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
> believe.
> 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 mode=
l)
>> Obviously there will be a need to maybe link into area where "further
>> information" is available. This might detail "items", "issues", "crite=
ria"
>> and "attributes".
> sure these are all runtime information
>> 9) What information will need to be updated from the engine to the DKB=
? We
>> 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.
>=20
>> I've attached a sequence diagram (.jpg) with a number of possible
>> alternatives for the "Announce/Deploy" sequence. I haven't added this =
to
> the
>> EA repository yet until we fully agreed it. I also didn't integrate it=

> with
>> your sequence diagram (the node delegation process..etc) yet just to t=
ry
> to
>> keep it less complicated for the moment. I will add that our preferenc=
e
>> would be "Alternative 1 "!
>>
>> I hope this helps,
> Sure, thank's lot
> I'm digging in the sequence, be back soon
> best
> Pierfranco
>> Claire
>> -----Original Message-----
>> From: Pierfranco Ferronato [mailto:pfe...@so...]=20
>> Sent: Wednesday, November 14, 2007 5:27 AM
>> To: Jason Finnegan
>> Cc: ONE Project Developer Mailing List; Claire Fahy; Andrea Danzi; Sha=
ne
>> Dempsey; Sonia Rigo
>> Subject: Re: annoucement
>>
>> hi,
>> I'm in a hurry, will reply 15/11/2007, in any case the sequence is und=
er
>> the component "setup" insider the "component model" viewpoint.
>>
>> Kind Regards
>> Pierfranco
>>
>> Soluta.net
>>
>> Pierfranco Ferronato
>> CIO and Founder
>> Soluta.Net,Italy
>> Innovation in Action
>> http://www.soluta.net
>>
>> Tel: +39-0423-915547
>> Fax: +39-0423-915547
>> ICQ: 297565827
>> Skype: pferronato
>>
>> The information transmitted is intended only for the person or entity =
to
>> which it is addressed and may contain confidential and/or privileged
>> material. Any review, retransmission, dissemination or other use of, o=
r
>> 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 conta=
in
>>> the up-to-the-minute status information or just a pointer to a DKB wh=
ere
>>> 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 update=
s
>>> to the DHT for each Negotiation (start and Finish).
>>> However maintaining status information in the DHT(soapod) would requi=
re
>>> possible hundreds of updates which could occur in a short amount of t=
ime
>>> and cause problems.
>>> (i'm assuming status information would  include current state, highes=
t
>>> 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 ne=
ed
>>> to be called once, with no updates required, which will scale better
>>> than trying to keep sopaod updated with possibly thousands of concurr=
ent
>>> negotiation status changes.
>>>
>>>
>>>
>>> PS. Pierfranco we have not been able to find your Setup sequence Diag=
ram
>>> in EA, where exactly is it?
>>>
>>>
>>> Jason
>>>
>>> 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 annoucemen=
t
>>>> 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 reca=
p
>>>> 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 ever=
y
>>>> 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=
=2E
>>>> And the list of updated negotiation instances will require just
>>>> calling the SOAPOD registy and the DKB *ONCE*,
>>>>
>>>> best
>>>> Pierfranco
>>>>
>>>>
>>>> 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 mu=
ch
>>>>> faster Soapod updates will be.
>>>>>
>>>>> We had some discussions here and came up with the following proposa=
l.
>>>>> The Soapod service registry should contain an entry representing th=
e
>>>>> 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 no=
t
>>>>> be fully up to date).
>>>>>
>>>>> If a user wanted to do a search for Negotiations based on keywords =
we
>>>>> 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 dat=
a.
>>>>>
>>>>> Before proceeding it would be good to have a more detailed picture =
on
>>>>> how the DKB data replication is to be implemented. Given that Soapo=
d
>>>>> already implements a DHT it might be reasonable for us to coordinat=
e
>>>>> to produce a consistent overlay with the DKB.
>>>>>
>>>>> Jason
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Pierfranco Ferronato wrote:
>>>>>
>>>>>> Ciao,
>>>>>>
>>>>>> in the EA repository, the Negotiation Setup has a nested sequence
>>>>>> diagram describing the scenario of this functionality named
>>>>>> "Announcement".
>>>>>>
>>>>>> 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 abo=
ut
>>>>>> the announced negotiation. My concern is related to the fact that
>>>>>> the DKB might not be very fast in updating the entire DKB nodes an=
d
>>>>>> some participant might miss these critical information. In additio=
n
>>>>>> 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 nod=
es
>>>>>> but also for keeping track of the running negotiations. It could
>>>>>> keep an index made of negotiation id and it's status (and some mor=
e
>>>>>> 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
>>>>>> terminated.
>>>>>> 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 avoidin=
g
>>>>>> the portal or other components to constantly poll the registry
>>>>>>
>>>>>> Any comment?
>>>>>> Best Regards
>>>>>> Pierfranco
>>>>>>
>>
>> ----------------------------------------------------------------------=
--
>>
>=20
>=20

Re: [One-project-devel] Code Logging

[Pierfranco F. <pfe...@so...>]

I was too quick...we need more details thought...
There is the need to define a common pattern/mark or the log and where
to store it and where/how, eventually, to configure it.

I believe Matteo (SN) has the onus of defining such standard,

Kind Regards
Pierfranco

Claire Fahy wrote:
> Hi All,
>=20
> =20
>=20
> The process of adding appropriate logging to our engine and
> transformation code is beginning here.
>=20
> =20
>=20
> In order to be compatible with all, I just wondered if there is a
> standard logging framework being used across the project? I would
> suggest the use of =E2=80=9Clog4j=E2=80=9D, any opinions?
>=20
> =20
>=20
> Best Regards,
>=20
> Claire
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> -----------------------------------------------------------------------=
--
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> _______________________________________________
> One-project-devel mailing list
> One...@li...
> https://lists.sourceforge.net/lists/listinfo/one-project-devel

Re: [One-project-devel] Code Logging

[Pierfranco F. <pfe...@so...>]

fine for me


Claire Fahy wrote:
> Hi All,
>=20
> =20
>=20
> The process of adding appropriate logging to our engine and
> transformation code is beginning here.
>=20
> =20
>=20
> In order to be compatible with all, I just wondered if there is a
> standard logging framework being used across the project? I would
> suggest the use of =E2=80=9Clog4j=E2=80=9D, any opinions?
>=20
> =20
>=20
> Best Regards,
>=20
> Claire
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> -----------------------------------------------------------------------=
--
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> _______________________________________________
> One-project-devel mailing list
> One...@li...
> https://lists.sourceforge.net/lists/listinfo/one-project-devel

Re: [One-project-devel] Code Logging

[Alessandro S. <se...@fb...>]

Hi Claire,
for us, log4j is fine.

Best Regards,
Alessandro

Claire Fahy wrote:
> Hi All,
>
> The process of adding appropriate logging to our engine and transformation code is beginning here.
>
> In order to be compatible with all, I just wondered if there is a standard logging framework being used across the project? I would suggest the use of “log4j”, any opinions?
>
> Best Regards,
> Claire
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> One-project-devel mailing list
> One...@li...
> https://lists.sourceforge.net/lists/listinfo/one-project-devel
>   

[One-project-devel] Code Logging

[Claire F. <cf...@ts...>]

Hi All,

 

The process of adding appropriate logging to our engine and transformation
code is beginning here. 

 

In order to be compatible with all, I just wondered if there is a standard
logging framework being used across the project? I would suggest the use of
"log4j", any opinions?

 

Best Regards,

Claire

Re: [One-project-devel] annoucement

[Claire F. <cf...@ts...>]

Hi,

Some replies to below:

1) It seems strange that the Negotiation Setup would handle the public
announcement and not the private invitation? The setup will have access to
the "contact list" as it also part of "MyONE" so maybe it would make more
sense to handle the invitation?

2) "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."

We should just ensure the understanding of the "start-date" (however it will
be described in the model) can not be misconstrued by the participant.
Otherwise he/she may miss their admission opportunity (if they believe that
the start-date refers to the very start of the negotiation, not just the
"readiness" stage).

3)Sorry my question 8 was a little unclear, I meant what information would
be "visible" (on the GUI) to the participant when he/she checks the recent
negotiatons? We checked a few similar websites (for eg.,
http://www.e-tenders.gov.ie/search/search_mainpage.aspx) and came up with
the suggested list below.

4) I think we can agree on the updating of info from the engine to DKB. The
only concern we would have is the issue of node redundancy (in the event
that the owner node fails during negotiaton), although I guess you've
handled this with your "backup" node.  One of the main reasons we asked
initially was because you included an "Update" message in your sequence
diagram between engine and DKB - was this referring to logging (or of
course, changes in the Information model due to the addition of issues at
runtime) once the negotiation is completed?

Thanks for your help,
Best Regards,
Claire

-----Original Message-----
From: Pierfranco Ferronato [mailto:pfe...@so...] 
Sent: Tuesday, November 20, 2007 12:54 PM
To: Claire Fahy
Cc: 'Jason Finnegan'; 'ONE Project Developer Mailing List'; 'Andrea Danzi';
'Shane Dempsey'; 'Sonia Rigo'
Subject: Re: annoucement

Ciao,

tks, see my replies below

Claire Fahy wrote:
> Hi Pierfranco,
> 
> After having studied your sequence diagram, we still have some outstanding
> questions:
> 1) What component will do the announcement, "set-up" or "console" 
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
below.
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
component?)
> is the invitation coming from? 
good point, the negotiation console shall IMO as soon as it receives the
annoucement
> 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?
>From 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 of
a
> negotiation (private and public case)? We have made a preliminary list of
> info that could be presented:
> 	a) Title/Description of negotiation (comes from negotiation
> instance)
> 	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
believe.
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", "criteria"
> and "attributes".
sure these are all runtime information
> 9) What information will need to be updated from the engine to the DKB? We
> 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 to
the
> EA repository yet until we fully agreed it. I also didn't integrate it
with
> your sequence diagram (the node delegation process..etc) yet just to try
to
> 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
best
Pierfranco
> Claire
> -----Original Message-----
> From: Pierfranco Ferronato [mailto:pfe...@so...] 
> Sent: Wednesday, November 14, 2007 5:27 AM
> To: Jason Finnegan
> Cc: ONE Project Developer Mailing List; Claire Fahy; Andrea Danzi; Shane
> Dempsey; Sonia Rigo
> Subject: Re: annoucement
> 
> hi,
> I'm in a hurry, will reply 15/11/2007, in any case the sequence is under
> the component "setup" insider the "component model" viewpoint.
> 
> Kind Regards
> Pierfranco
> 
> Soluta.net
> 
> Pierfranco Ferronato
> CIO and Founder
> Soluta.Net,Italy
> Innovation in Action
> http://www.soluta.net
> 
> Tel: +39-0423-915547
> Fax: +39-0423-915547
> ICQ: 297565827
> Skype: pferronato
> 
> The information transmitted is intended only for the person or entity to
> 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 contain
>> the up-to-the-minute status information or just a pointer to a DKB where
>> 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 require
>> possible hundreds of updates which could occur in a short amount of time
>> 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 need
>> to be called once, with no updates required, which will scale better
>> than trying to keep sopaod updated with possibly thousands of concurrent
>> negotiation status changes.
>>
>>
>>
>> PS. Pierfranco we have not been able to find your Setup sequence Diagram
>> in EA, where exactly is it?
>>
>>
>> Jason
>>
>> 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*,
>>>
>>> best
>>> Pierfranco
>>>
>>>
>>> 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 much
>>>> 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 we
>>>> 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 on
>>>> 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.
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Pierfranco Ferronato wrote:
>>>>
>>>>> Ciao,
>>>>>
>>>>> in the EA repository, the Negotiation Setup has a nested sequence
>>>>> diagram describing the scenario of this functionality named
>>>>> "Announcement".
>>>>>
>>>>> 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 about
>>>>> 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 nodes
>>>>> 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
>>>>> terminated.
>>>>> 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
>>>>> Pierfranco
>>>>>
>>>>
>>
> 
> 
> ------------------------------------------------------------------------
> 

[One-project-devel] transitions in the protocol model

[Pierfranco F. <pfe...@so...>]

Hi all,

we are due to improve the Editor with respect of the event notations. We
wish to show actual arrows going from "create message action" to "wait
event action": this is what the user shall expect to see since this his
the actual desiderata and it'd greatly improve the readability.
Since the MM defines the transitions to and from Stages instead of
Events directly, the graphical notation we wish to adopt will differ
from the MM: we have to show something which will not be reflected in
the model in the same way, a manual coding is necessary: Java hand
coding is necessary and this is doable and we ca do it (IT'S NOT A
MATTER OF SIMPLIFYING OUR EFFORT) but the issue is here another In my
humble opinion.

Why is the MM linking transition with stages which in turn contain the
actions? What is the criteria here? If we going to customize the editor
supporting the MM as it is now, we'd not be in the position of using the
ecore MM directly: seeing arrow from stage to stage and from there to
actions is misleading and hardening the comprehension of the model.
It'be straightforward to see arrow going from action at action straight
from the MM.

Unless there is something I miss here, please tell me, I'd suggest to
amend the MM,

best
Pierfranco

--=20
Soluta.net

Pierfranco Ferronato
CIO and Founder
Soluta.Net,Italy
Innovation in Action
http://www.soluta.net

Tel: +39-0423-915547
Fax: +39-0423-915547
ICQ: 297565827
Skype: pferronato

The information transmitted is intended only for the person or entity to
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.

Re: [One-project-devel] annoucement

[Pierfranco F. <pfe...@so...>]

Ciao,

scenario number one is to be preferred, I'll update my sequence
best
Pierfranco


Claire Fahy wrote:
> Hi Pierfranco,
>=20
> After having studied your sequence diagram, we still have some outstand=
ing
> questions:
> 1) What component will do the announcement, "set-up" or "console"=20
> 2) Is the negotiation announced (publicly) by placing on the DKB?
> 3) How is the negotiation privately announced, where (i.e. what compone=
nt?)
> is the invitation coming from?=20
> 4) Should the private negotiation be stored in the DKB? If so, will acc=
ess
> to this entry in the DKB require a secure login?
> 5) How are private invitees invited, for example: email, MyONE..?
> 6) When is the negotiation started, after or before announcement?
> 7) What component triggers the start of the negotiation?
> 8) What is the information available to the users with the announcement=
 of a
> negotiation (private and public case)? We have made a preliminary list =
of
> info that could be presented:
> 	a) Title/Description of negotiation (comes from negotiation
> instance)
> 	b) Negotiation ID
> 	c) Current state
> 	d) Owner name
> 	e) Negotiation Description
> Obviously there will be a need to maybe link into area where "further
> information" is available. This might detail "items", "issues", "criter=
ia"
> and "attributes".
> 9) What information will need to be updated from the engine to the DKB?=
 We
> have come up with the preliminary information:
> 	a) State
> 	b) Superstate
> 	c) Issues
> 	d) Criteria
> 	e) Attribute
> 	f) Offer
> I've attached a sequence diagram (.jpg) with a number of possible
> alternatives for the "Announce/Deploy" sequence. I haven't added this t=
o the
> EA repository yet until we fully agreed it. I also didn't integrate it =
with
> your sequence diagram (the node delegation process..etc) yet just to tr=
y to
> keep it less complicated for the moment. I will add that our preference=

> would be "Alternative 1 "!
>=20
> I hope this helps,
> Claire
> -----Original Message-----
> From: Pierfranco Ferronato [mailto:pfe...@so...]=20
> Sent: Wednesday, November 14, 2007 5:27 AM
> To: Jason Finnegan
> Cc: ONE Project Developer Mailing List; Claire Fahy; Andrea Danzi; Shan=
e
> Dempsey; Sonia Rigo
> Subject: Re: annoucement
>=20
> hi,
> I'm in a hurry, will reply 15/11/2007, in any case the sequence is unde=
r
> the component "setup" insider the "component model" viewpoint.
>=20
> Kind Regards
> Pierfranco
>=20
> Soluta.net
>=20
> Pierfranco Ferronato
> CIO and Founder
> Soluta.Net,Italy
> Innovation in Action
> http://www.soluta.net
>=20
> Tel: +39-0423-915547
> Fax: +39-0423-915547
> ICQ: 297565827
> Skype: pferronato
>=20
> The information transmitted is intended only for the person or entity t=
o
> 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.
>=20
>=20
>=20
> Jason Finnegan wrote:
>> Hi all,
>> I think we agree on everything apart from whether Soapod should contai=
n
>> the up-to-the-minute status information or just a pointer to a DKB whe=
re
>> 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=
e
>> possible hundreds of updates which could occur in a short amount of ti=
me
>> 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=
d
>> to be called once, with no updates required, which will scale better
>> than trying to keep sopaod updated with possibly thousands of concurre=
nt
>> negotiation status changes.
>>
>>
>>
>> PS. Pierfranco we have not been able to find your Setup sequence Diagr=
am
>> in EA, where exactly is it?
>>
>>
>> Jason
>>
>> 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*,
>>>
>>> best
>>> Pierfranco
>>>
>>>
>>> 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=
h
>>>> faster Soapod updates will be.
>>>>
>>>> We had some discussions here and came up with the following proposal=
=2E
>>>> 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=
e
>>>> 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=
=2E
>>>>
>>>> Before proceeding it would be good to have a more detailed picture o=
n
>>>> 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.
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Pierfranco Ferronato wrote:
>>>>
>>>>> Ciao,
>>>>>
>>>>> in the EA repository, the Negotiation Setup has a nested sequence
>>>>> diagram describing the scenario of this functionality named
>>>>> "Announcement".
>>>>>
>>>>> 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=
t
>>>>> 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=
s
>>>>> 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
>>>>> terminated.
>>>>> 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
>>>>> Pierfranco
>>>>>
>>>>
>>
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20

Re: [One-project-devel] annoucement

[Pierfranco F. <pfe...@so...>]

Ciao,

tks, see my replies below

Claire Fahy wrote:
> Hi Pierfranco,
>=20
> After having studied your sequence diagram, we still have some outstand=
ing
> questions:
> 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
below.
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=
nt?)
> is the invitation coming from?=20
good point, the negotiation console shall IMO as soon as it receives the
annoucement
> 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=
=2E
> 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=
 of a
> negotiation (private and public case)? We have made a preliminary list =
of
> info that could be presented:
> 	a) Title/Description of negotiation (comes from negotiation
> instance)
> 	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
believe.
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=
ia"
> and "attributes".
sure these are all runtime information
> 9) What information will need to be updated from the engine to the DKB?=
 We
> 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=
o the
> EA repository yet until we fully agreed it. I also didn't integrate it =
with
> your sequence diagram (the node delegation process..etc) yet just to tr=
y to
> keep it less complicated for the moment. I will add that our preference=

> would be "Alternative 1 "!
>=20
> I hope this helps,
Sure, thank's lot
I'm digging in the sequence, be back soon
best
Pierfranco
> Claire
> -----Original Message-----
> From: Pierfranco Ferronato [mailto:pfe...@so...]=20
> Sent: Wednesday, November 14, 2007 5:27 AM
> To: Jason Finnegan
> Cc: ONE Project Developer Mailing List; Claire Fahy; Andrea Danzi; Shan=
e
> Dempsey; Sonia Rigo
> Subject: Re: annoucement
>=20
> hi,
> I'm in a hurry, will reply 15/11/2007, in any case the sequence is unde=
r
> the component "setup" insider the "component model" viewpoint.
>=20
> Kind Regards
> Pierfranco
>=20
> Soluta.net
>=20
> Pierfranco Ferronato
> CIO and Founder
> Soluta.Net,Italy
> Innovation in Action
> http://www.soluta.net
>=20
> Tel: +39-0423-915547
> Fax: +39-0423-915547
> ICQ: 297565827
> Skype: pferronato
>=20
> The information transmitted is intended only for the person or entity t=
o
> 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.
>=20
>=20
>=20
> Jason Finnegan wrote:
>> Hi all,
>> I think we agree on everything apart from whether Soapod should contai=
n
>> the up-to-the-minute status information or just a pointer to a DKB whe=
re
>> 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=
e
>> possible hundreds of updates which could occur in a short amount of ti=
me
>> 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=
d
>> to be called once, with no updates required, which will scale better
>> than trying to keep sopaod updated with possibly thousands of concurre=
nt
>> negotiation status changes.
>>
>>
>>
>> PS. Pierfranco we have not been able to find your Setup sequence Diagr=
am
>> in EA, where exactly is it?
>>
>>
>> Jason
>>
>> 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*,
>>>
>>> best
>>> Pierfranco
>>>
>>>
>>> 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=
h
>>>> faster Soapod updates will be.
>>>>
>>>> We had some discussions here and came up with the following proposal=
=2E
>>>> 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=
e
>>>> 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=
=2E
>>>>
>>>> Before proceeding it would be good to have a more detailed picture o=
n
>>>> 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.
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Pierfranco Ferronato wrote:
>>>>
>>>>> Ciao,
>>>>>
>>>>> in the EA repository, the Negotiation Setup has a nested sequence
>>>>> diagram describing the scenario of this functionality named
>>>>> "Announcement".
>>>>>
>>>>> 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=
t
>>>>> 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=
s
>>>>> 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
>>>>> terminated.
>>>>> 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
>>>>> Pierfranco
>>>>>
>>>>
>>
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20

Re: [One-project-devel] annoucement

[Pierfranco F. <pfe...@so...>]

Hi,

sorry for the late reply.

Jason Finnegan wrote:
> Hi all,
> I think we agree on everything apart from whether Soapod should contain
> the up-to-the-minute status information or just a pointer to a DKB where
> 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.
I agree, the issue here is related to how much data to fit in the
registry and how to use it.
> Our approach means only two updates
> to the DHT for each Negotiation (start and Finish).
> However maintaining status information in the DHT(soapod) would require
> possible hundreds of updates which could occur in a short amount of time
> and cause problems.
> (i'm assuming status information would  include current state, highest
> offer received, if an open auction)
I've not the same assumption, what you listed are to be asked to the
negotiation engine when joining the negotiation or when redirected to
the node where the negotiation is actually running.

> 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 need
> to be called once, 
yes, but this'd require to call (at the worst case, which might be the
more probable) 10 remote different nodes and it has to happen while the
used is waiting for the list of negotiations in the screen.
>with no updates required, which will scale better
> than trying to keep sopaod updated with possibly thousands of concurrent
> negotiation status changes.

I suggest the following:
some data to be added  in the registry such as:
- date-time to be started
- status: simply if it has started or not (computable from the previous
value)
- node address
- owner name
- node name ad address where is it running or is supposed to run

All the rest of the data are to be fetched AT THE ENGINE NODE when asked
for "Details" for a single negotiation:
- actual bid value
- number of participants
- detailed stage it is in, or will be
- others

Notice that the actual exe information are asked to the engine node not
the DKN, 'cause highly dynamic information such as "current price" are
not to be stored in the DKB,

Have we reached a common agreement?

best
Pierfranco


> 
> 
> PS. Pierfranco we have not been able to find your Setup sequence Diagram
> in EA, where exactly is it?
> 
> 
> Jason
> 
> 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*,
>>
>> best
>> Pierfranco
>>
>>
>> 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 much
>>> 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 we
>>> 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 on
>>> 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.
>>>
>>> Jason
>>>
>>>
>>>
>>>
>>>
>>> Pierfranco Ferronato wrote:
>>>
>>>> Ciao,
>>>>
>>>> in the EA repository, the Negotiation Setup has a nested sequence
>>>> diagram describing the scenario of this functionality named
>>>> "Announcement".
>>>>
>>>> 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 about
>>>> 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 nodes
>>>> 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
>>>> terminated.
>>>> 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
>>>> Pierfranco
>>>>
>>>
>>>
>>
> 
> 

Re: [One-project-devel] annoucement

[Claire F. <cf...@ts...>]

Hi Pierfranco,

After having studied your sequence diagram, we still have some outstanding
questions:
1) What component will do the announcement, "set-up" or "console" 
2) Is the negotiation announced (publicly) by placing on the DKB?
3) How is the negotiation privately announced, where (i.e. what component?)
is the invitation coming from? 
4) Should the private negotiation be stored in the DKB? If so, will access
to this entry in the DKB require a secure login?
5) How are private invitees invited, for example: email, MyONE..?
6) When is the negotiation started, after or before announcement?
7) What component triggers the start of the negotiation?
8) What is the information available to the users with the announcement of a
negotiation (private and public case)? We have made a preliminary list of
info that could be presented:
	a) Title/Description of negotiation (comes from negotiation
instance)
	b) Negotiation ID
	c) Current state
	d) Owner name
	e) Negotiation Description
Obviously there will be a need to maybe link into area where "further
information" is available. This might detail "items", "issues", "criteria"
and "attributes".
9) What information will need to be updated from the engine to the DKB? We
have come up with the preliminary information:
	a) State
	b) Superstate
	c) Issues
	d) Criteria
	e) Attribute
	f) Offer
I've attached a sequence diagram (.jpg) with a number of possible
alternatives for the "Announce/Deploy" sequence. I haven't added this to the
EA repository yet until we fully agreed it. I also didn't integrate it with
your sequence diagram (the node delegation process..etc) yet just to try to
keep it less complicated for the moment. I will add that our preference
would be "Alternative 1 "!

I hope this helps,
Claire
-----Original Message-----
From: Pierfranco Ferronato [mailto:pfe...@so...] 
Sent: Wednesday, November 14, 2007 5:27 AM
To: Jason Finnegan
Cc: ONE Project Developer Mailing List; Claire Fahy; Andrea Danzi; Shane
Dempsey; Sonia Rigo
Subject: Re: annoucement

hi,
I'm in a hurry, will reply 15/11/2007, in any case the sequence is under
the component "setup" insider the "component model" viewpoint.

Kind Regards
Pierfranco

Soluta.net

Pierfranco Ferronato
CIO and Founder
Soluta.Net,Italy
Innovation in Action
http://www.soluta.net

Tel: +39-0423-915547
Fax: +39-0423-915547
ICQ: 297565827
Skype: pferronato

The information transmitted is intended only for the person or entity to
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 contain
> the up-to-the-minute status information or just a pointer to a DKB where
> 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 require
> possible hundreds of updates which could occur in a short amount of time
> 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 need
> to be called once, with no updates required, which will scale better
> than trying to keep sopaod updated with possibly thousands of concurrent
> negotiation status changes.
> 
> 
> 
> PS. Pierfranco we have not been able to find your Setup sequence Diagram
> in EA, where exactly is it?
> 
> 
> Jason
> 
> 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*,
>>
>> best
>> Pierfranco
>>
>>
>> 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 much
>>> 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 we
>>> 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 on
>>> 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.
>>>
>>> Jason
>>>
>>>
>>>
>>>
>>>
>>> Pierfranco Ferronato wrote:
>>>
>>>> Ciao,
>>>>
>>>> in the EA repository, the Negotiation Setup has a nested sequence
>>>> diagram describing the scenario of this functionality named
>>>> "Announcement".
>>>>
>>>> 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 about
>>>> 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 nodes
>>>> 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
>>>> terminated.
>>>> 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
>>>> Pierfranco
>>>>
>>>
>>>
>>
> 
> 

Re: [One-project-devel] annoucement

[Pierfranco F. <pfe...@so...>]

hi,
I'm in a hurry, will reply 15/11/2007, in any case the sequence is under
the component "setup" insider the "component model" viewpoint.

Kind Regards
Pierfranco

Soluta.net

Pierfranco Ferronato
CIO and Founder
Soluta.Net,Italy
Innovation in Action
http://www.soluta.net

Tel: +39-0423-915547
Fax: +39-0423-915547
ICQ: 297565827
Skype: pferronato

The information transmitted is intended only for the person or entity to
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 contain
> the up-to-the-minute status information or just a pointer to a DKB where
> 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 require
> possible hundreds of updates which could occur in a short amount of time
> 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 need
> to be called once, with no updates required, which will scale better
> than trying to keep sopaod updated with possibly thousands of concurrent
> negotiation status changes.
> 
> 
> 
> PS. Pierfranco we have not been able to find your Setup sequence Diagram
> in EA, where exactly is it?
> 
> 
> Jason
> 
> 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*,
>>
>> best
>> Pierfranco
>>
>>
>> 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 much
>>> 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 we
>>> 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 on
>>> 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.
>>>
>>> Jason
>>>
>>>
>>>
>>>
>>>
>>> Pierfranco Ferronato wrote:
>>>
>>>> Ciao,
>>>>
>>>> in the EA repository, the Negotiation Setup has a nested sequence
>>>> diagram describing the scenario of this functionality named
>>>> "Announcement".
>>>>
>>>> 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 about
>>>> 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 nodes
>>>> 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
>>>> terminated.
>>>> 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
>>>> Pierfranco
>>>>
>>>
>>>
>>
> 
> 

Re: [One-project-devel] annoucement

[Jason F. <jfi...@ts...>]

Hi all,
I think we agree on everything apart from whether Soapod should contain 
the up-to-the-minute status information or just a pointer to a DKB where 
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 require 
possible hundreds of updates which could occur in a short amount of time 
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 need 
to be called once, with no updates required, which will scale better 
than trying to keep sopaod updated with possibly thousands of concurrent 
negotiation status changes.



PS. Pierfranco we have not been able to find your Setup sequence Diagram 
in EA, where exactly is it?


Jason

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*,
>
> best
> Pierfranco
>
>
> 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 much 
>> 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 we 
>> 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 on 
>> 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.
>>
>> Jason
>>
>>
>>
>>
>>
>> Pierfranco Ferronato wrote:
>>
>>> Ciao,
>>>
>>> in the EA repository, the Negotiation Setup has a nested sequence 
>>> diagram describing the scenario of this functionality named 
>>> "Announcement".
>>>
>>> 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 about 
>>> 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 nodes 
>>> 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 
>>> terminated.
>>> 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
>>> Pierfranco
>>>
>>
>>
>


-- 
Jason Finnegan
Telecommunications Software and Systems Group
Waterford Institute of Technology
Cork Road
Waterford
Ireland
Tel:00353 (0) 51 302961
Fax:00353 (0) 51 302901
mail: jfi...@ts...
web: http://www.tssg.org

Re: [One-project-devel] annoucement

[Andrea D. <and...@cr...>]

Hi all,

    sorry, I'll give you my feedback as soon as possible......be patient
please ....I prefer to spend more time on this issue, have a clear
understanding of the problem and try to formalize my proposal.

Andrea

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*,
>
> best
> Pierfranco
>
>
> 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 much
>> 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 we
>> 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 on
>> 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.
>>
>> Jason
>>
>>
>>
>>
>>
>> Pierfranco Ferronato wrote:
>>
>>> Ciao,
>>>
>>> in the EA repository, the Negotiation Setup has a nested sequence
>>> diagram describing the scenario of this functionality named
>>> "Announcement".
>>>
>>> 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 about
>>> 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 nodes
>>> 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
>>> terminated.
>>> 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
>>> Pierfranco
>>>
>>
>>
>

Re: [One-project-devel] annoucement

[Pierfranco F. <pfe...@so...>]

I understand I was not clear....

>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'd rewrite as follows:

These two are logically
  separated items but could be merged if we assume that the Engine is
  going to load a negotiation (hence becoming a in-memory process) just 
after the announcement even if it has
  not initiated yet: i.e. even if the starting date-time has yet to 
come. I'd support this approach that is in-line with my setup seq. 
diagram in EA.

best
Pierfranco

Re: [One-project-devel] GUI interface for MyONE area

[Pierfranco F. <pfe...@so...>]

Hi,

I was not probably clear. We will use our current APIs for calling the 
portal components (HTTPS via AJAX and from the back-end straight to 
Spring based APIs), but all the functionalities shall also be exposed 
externally as a WS, in order to let third party application to extend 
ONE: e.g. supporting mobile devices.

If this is more feasible via a unique WSDL interface instead of one for 
each component, it would be fine for me, except some concern about the 
deployment of new versions of a component that'd affect a common WSDL. 
This would not be a relevant issue in a project like ONE...

best
Pierfranco



Jason Finnegan wrote:
> Hi Pierfranco,
> I have an issue with the requirement that every component expose a web 
> service interface, this would mean a lot of work(and slow execution) if 
> every interaction between the console and the engine had to go through a 
> web service interface. I think it may be better to limit the the web 
> service interfaces to individual components such as the DKB or 
> recommender, as they have simpler interfaces and less interaction with 
> other components
> 
> Another option would be to bundle the engine and console  into a single 
> component , as was done in the demo.
> 
> Jason
> 
> 
> Pierfranco Ferronato wrote:
> 
>> ...thanks Sonia, in addition *every component* shall also expose a web 
>> service interface; as already decided and as recently highlighted 
>> during the review,
>>
>> kindly
>> Pierfranco
>>
>> Soluta.net
>>
>> Pierfranco Ferronato
>> CIO and Founder
>> Soluta.Net,Italy
>> Innovation in Action
>> http://www.soluta.net
>>
>> Tel: +39-0423-915547
>> Fax: +39-0423-915547
>> ICQ: 297565827
>> Skype: pferronato
>>
>> The information transmitted is intended only for the person or entity to
>> 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.
>>
>>
>>
>> Sonia Rigo wrote:
>>
>>> Hi all,
>>> After the first end to end implementation presented at the review, we 
>>> are organizing better the MyONE area, with all the components that 
>>> composed it
>>>
>>> We identify the follow components :
>>> -SetUp and Announce :to define a new Negotiation Instance
>>> -Console: to manage the active Negotiation
>>> -Contact List management : where user can insert -modify-delete his 
>>> contacts
>>> -Account Management : where the user can manage his ONE account
>>> -List of Negotiation instance : from which he can start a new 
>>> Negotiation using a previous configuration ( useful for some periodic 
>>> negotiation )
>>> -List of Negotiation Model : where choose the model from which run 
>>> the SetUp
>>> -Search of Negotiation Model
>>> -Search of a Contact
>>> -Search of Negotiation Instance
>>>
>>> Now we ask to the partners to collaborate in the construction of the 
>>> GUI components. The idea is that who is responsible of the components 
>>> in the TA, has to define also the GUI for the component  (and SN 
>>> integrate it inside MyONE and/or ONEPortal). In  detail :
>>> CN has to define the GUI components for all the User Management 
>>> (personal Account Management,  Registration , Contact List 
>>> Management  and so on)
>>> WIT has to define the GUI for manage all the operation related to the 
>>> active negotiation (list of active Negotiation, Join to a public 
>>> Negotiation and so on...)
>>>
>>> What do you think? Any comment?
>>> Best Regards
>>>
>>>
>>
> 
> 

Re: [One-project-devel] annoucement

[Pierfranco F. <pfe...@so...>]

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*,

best
Pierfranco


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 much 
> 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 we 
> 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 on 
> 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.
> 
> Jason
> 
> 
> 
> 
> 
> Pierfranco Ferronato wrote:
> 
>> Ciao,
>>
>> in the EA repository, the Negotiation Setup has a nested sequence 
>> diagram describing the scenario of this functionality named 
>> "Announcement".
>>
>> 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 about 
>> 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 nodes 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 terminated.
>> 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
>> Pierfranco
>>
> 
> 

Re: [One-project-devel] annoucement

[Jason F. <jfi...@ts...>]

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 much 
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 we 
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 on 
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.

Jason





Pierfranco Ferronato wrote:

> Ciao,
>
> in the EA repository, the Negotiation Setup has a nested sequence 
> diagram describing the scenario of this functionality named 
> "Announcement".
>
> 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 about 
> 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 nodes 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 terminated.
> 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
> Pierfranco
>


-- 
Jason Finnegan
Telecommunications Software and Systems Group
Waterford Institute of Technology
Cork Road
Waterford
Ireland
Tel:00353 (0) 51 302961
Fax:00353 (0) 51 302901
mail: jfi...@ts...
web: http://www.tssg.org

[One-project-devel] annoucement

[Pierfranco F. <pfe...@so...>]

Ciao,

in the EA repository, the Negotiation Setup has a nested sequence 
diagram describing the scenario of this functionality named "Announcement".

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 about 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 nodes 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 terminated.
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
Pierfranco

-- 
Soluta.net

Pierfranco Ferronato
CIO and Founder
Soluta.Net,Italy
Innovation in Action
http://www.soluta.net

Tel: +39-0423-915547
Fax: +39-0423-915547
ICQ: 297565827
Skype: pferronato

The information transmitted is intended only for the person or entity to
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.