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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

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


Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.44]



I see 2 different issues in your comments:

1)  Would it be better (cleaner, more understandable, etc) to have 2
operations (createTransientEntity & createPersistentEntity) rather than a
boolean parameter? I favor the 2 operation model as this is clearer for the
developers of both the Producer and Consumer.

2) If we choose the 2 operation model, would it be better to factor the
createPersistentEntity operation into a separate portType? I think the
fundamental tradeoff here is complexity. The question is whether requiring
a Producer that only supports the creation of such persistent entities
though out-of-band means to implement an operation that always returns null
(or throws a spec defined fault) is worse than requiring Consumers to deal
with this being an optional operation (potentially breaking the goal of
this level of the spec supporting plug-n-play of Producers). In this case,
I would strongly favor requiring the Producer to implement the operation
and having the spec define the expected behaviour.



                                                                                                                     
                      Eilon Reshef                                                                                   
                      <eilon.reshef@webc        To:       wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org       
                      ollage.com>               cc:                                                                  
                                                Subject:  RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec    
                      06/03/2002 01:10           0.44]                                                               
                      AM                                                                                             
                                                                                                                     
                                                                                                                     



Rich,

Sorry for the late response --

I am slightly concerned with the approach of consolidating the "create"
operations into a single concept. Not to beat a dead horse, but your
previous analysis revealed different operations, such as:
- Creating a transient thingy from a persistent one ("instantiation").
  This is a relatively simple concept.
- Creating a persistent thingy from another persistent one.
  This is a much more complex beast, that raises questions such
  as inheritance, cloning, etc. - not sure that there's a single
  operation here.
- Creating a persistent thingy from a transient one.
  This is even a more complex beast: the question of what gets
  persisted etc. is tough (e.g., the user has just typed in a
  stock symbol, does that get persisted?). It probably deserves
  a different interface.
- Creating a transient thingy from another transient one.
  Not sure if that's needed at all.

In addition, I foresee many services, especially in the WSIA world but
possibly even in WSRP in B2B scenarios, where an organization would provide
run-time access to a WSIA service / portlet but would not support creating
new persistent thingies, etc. (which require manual processes that relate
to
approval, billing, etc.).

I believe we would be much better off defining the run-time model
separately
(i.e., creating transient thingies and transferring them throughout the
interaction), and then merge it with the management aspects, which, as
Alejandro suggested, may even be better encapsulated as separate
interfaces,
and even if not - have a completely different spin to them.

Any thoughts?

Eilon

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, May 30, 2002 9:30 AM
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: Re: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.44]



Sorry about this duplication, but I just remembered that I had intended to
turn on line numbers so as to make the discussion easier (provided we all
use them to point at the area we are commenting on). Here is the version
with this turned on.

(See attached file: WSIA-WSRP Joint Spec Draft 0.44.doc)




                      Rich

                      Thompson/Watson/I        To:
wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org
                      BM@IBMUS                 cc:

                                               Subject:
[wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.44]
                      05/30/2002 08:57

                      AM










As requested on Tuesday, here is a modified version of the Draft Spec that
reflects having orthogonal concepts of "sessions" and "entities" carried
throughout the API. Thomas has inserted a few initial comments from a WSRP
perspective (in particular, potential answers to some of the open questions
in the Note blocks).

(See attached file: WSIA-WSRP Joint Spec Draft 0.44.doc)



#### WSIA-WSRP Joint Spec Draft 0.44.doc has been removed from this note on
May 30 2002 by Rich Thompson



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>







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


Powered by eList eXpress LLC