[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] Modelling sessions
Hey William,
Thanks for taking the time to answer these questions.
[snip]
>
> Regarding the choice between using a domain-specific <drop-database/>
> message or a WS-RL <wsrl:Destroy/> message, the focus of the
discussion
> was on addressing, not on the payload. Without a more complete use
case,
> I don't really have a recommendation between the two. If the
> drop-database request expects the database to be destroyed and does
not
> imply any other behavior (like backing it up first or doing things in
a
> special way for a symbolic linked database) then using <wsrl:Destroy/>
> is an option. Which doesn't mean it has to be used.
>
I personally see a service as an entity that encapsulates (but does not
explicitly expose and model) resources and receives/send messages. How
it manages those resources is up to the service. I read from your reply
above that there is no clear view on when the resource-pattern should be
applied. If it is the case that the resource-pattern and the "common"
lifetime requirements for resources are not applicable in simple cases
like this because the application semantics take precedence, as should
be the case I think, how should application architects make the decision
when to use the resource pattern? Will the group consider a set of use
cases illustrating how the resource-pattern is necessary and the
benefits it brings? Perhaps we could then discuss alternatives that
utilise existing technology and identify the limitations with what we
have today. It seems to me that at the moment a solution is presented
without a clear definition of the problem.
> Finally, if you want to drop two databases at once I can see two
> options. If this is a common operation and most of your interactions
are
> at this level, you might want to address the database server, not the
> databases themselves. Even when you are using WS-Resources, the
designer
> picks what to model as a resource. The DB server, each DB or even each
> table. Depends on what works best for your use case.
>
What's wrong with
<body>
<operationRequest>
<drop-database>
<databaseId>databaseA</databaseId>
</drop-database>
<from-db-instance>savas</from-db-instance>
</operationRequest>
</body>
What would the advantage of modelling the DB instance as a WS-Resource
be? What will it bring to my architecture?
I heard general comments about common ways of accessing metadata and
resource properties. Building on this example, what would the
ResourceProperties represent for a WS-Resource that models a database
instance? Would it be the schemas of all the databases in the instance?
Would it be the data encapsulated by all the databases? Would it be its
current operational status?
At least with application-specific payloads, the service architects can
define _today_ what the kind of information they want to convey.
<body>
<get-schema>
<databaseId>databaseA</databaseId>
</get-schema>
</body>
> The other option, if you decide to model each DB as Ws-Resource, is to
> create a service group to contain a set of databases that you manage
> together. Currently, WS-ServiceGroup does not support invocation of
> operations on members of the group, but this is something that we are
> going to need for management (see WSMF Collections).
>
Again, what is the advantage of introducing a new concept, the service
group (which should really be called "resource group" in this case),
over using a simple approach based on the structure of the XML payload
that can have application-specific semantics?
What would it be mean to send a <wsrl:Destroy> message to a WS-Resource
that represents a database? Would the database be taken offline or
destroyed completely? With application-specific messages you could have
this:
<drop />
<take-offline />
Etc.
Best regards,
.savas.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]