MHonArc v2.5.2 -->
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