[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Simple example scenario
Jeff,
I think I said in the examples and schema that the query actually uses
XPath. XQuery is another matter altogether.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/12/2003 04:49 |
| | AM |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Gearard Woods/Irvine/IBM@IBMUS |
| cc: <provision@lists.oasis-open.org> |
| Subject: RE: [provision] Simple example scenario |
| |
>------------------------------------------------------------------------------------------------------------------------------|
Gerry,
Just to be clear, your proposal for filtering is to use the XQuery 1.0
specification as defined by the W3C? It looks like that is what you are
proposing, but I just want to make sure I have it right.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Wednesday, March 12, 2003 12:27 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example scenario
Jeff,
I think it's in there in section "6 querySubscriptions". It's easy to
miss
and I have to admit that there's an error in it - the example in the
package that I sent out is missing quotes. It looks like this:
...
<query
xmlns="urn:oasis:names:tc:SPML:0.1:provisioning:spmlquery">
<select>//parameters/ns1:EMailAccount[ns1:address='wjl@tiny.com']</selec
>;
...
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/11/2003 06:11 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS
|
| cc: <provision@lists.oasis-open.org>
|
| Subject: RE: [provision] Simple example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
Thanks for updating this example. But, I do not seem to see any example
of
what the select element in the ProvisioningQuery element would look
like.
Is there an example that I missed?
Anyway, could you post an example of the select statement as it applies
to
the Tiny Telecom example? Thanks.
Jeff Bohren
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Tue 3/11/2003 8:02 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example scenario
Jeff,
I've attached an updated scenario implementation which now
includes a
filtered search. The scheme that I've adopted for purposes
of
this example
uses an iterator model to traverse arbitrarily large result
sets. In the
context of this kind of Web Service, particularly for
RA-PSP
interaction,
I'm not sure that this has great utility since the
overriding
requirement
will probably not be to suck millions of
accounts/users/objects from the
service but to interact with the limited set to which the
RA
is authorized.
In any case, this should meet the stated scalability
requirements - in the
true sense of the word.
Gerry
(See attached file: query_scenario.ZIP)
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/10/2003 06:52 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS
|
| cc: provision@lists.oasis-open.org
|
| Subject: RE: [provision] Simple example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
I am not talking about returning 30 million records in a
search response.
That would be a search WITHOUT a filter. Which is, of
course,
what I am
trying to avoid. The scalability I am referring to is the
ability to look
for a set of records, in a large record set, that match a
specific
criteria. This has nothing to do with directories and has
everything to do
with provisioning (and is one of our agreed to use cases).
Unless you think
that provisioning only means a client pushing data to a
server, then this
is a provisioning issue.
Handling large data sets is an entirely different issues.
The
current SPML
specification does not address this issue, and neither does
your proposal.
I would like nothing more than to stop talking about
searches.
Just
supplement the Tiny Telecom example you posted with sample
of
a scalable
search mechanism. For this example just assume scalable
means
to find some
small number of accounts that satisfy a search criteria.
You
can make it as
"Provisioning centric" as you like. Work it in any way you
like, just show
me how it is done.
Note that all the previous paragraphs discuss provisioning.
Now I am confused about suspending accounts. You created
the
ProvisioningSubscriptionState element in you proposed
schema
to represent
the state of accounts. First you say that explicitly
representing such
things in your protocol is one of the features that makes
if
more
"Provisioning Centric", and now you seem to be saying that
it
was just an
unimportant example. Which is it? Is explicity representing
account state
part of your proposed protocol or not? If it is part of
your
protocol, then
tell me how you handle things that can not be suspended (or
locked, or
terminated). This is part of the provisioning discussion
you
want to have.
I do understand your concerns and I agree with many of
them.
But simply
put, you have yet to convinced me that the current approach
is
unworkable,
insufficient, or will not be adopted by the industry at
large.
You are
asking me to do several things: first flush the last 6
months
of work the
committee has done, give up on the Burton interop, give up
a
solution that
I have seen work in practice, and implement your proposed
solution in the
OpenNetwork Technologies provisioning web service (note
that
this
implementation will require some sort of search
capability).
If you think
raising these issues means I am ignoring yours, you are
wrong.
I will
continue to raise these issues as they are important to the
decision at
hand.
Jeff Bohren
OpenNetwork Technologies
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Mon 3/10/2003 5:21 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example
scenario
Jeff,
I should really have come up with some example
other than
suspending an
account - we seem to be getting stuck on that.
I
am equally
open to
debating search behaviour but the other points
that I'm trying
to impress
upon you seem to be falling on deaf ears. But
let's address
search anyway
and then move on to what I consider to be more
interesting and
relevant
topics. You cannot argue that the currently
proposed search
mechanism is
scalable, particularly if you intend to
support
SOAP. In your
example of a
recon of 15-30 million records, the current
search mechanism
will require
that you collect all of the results, embed
them
in a SOAP
envelope, and
return this huge data set to the client. The
scalability
issues are evident
but I'll enumerate them: memory constraints
on
the PST or PSP
whichever is
performing the search; bandwidth requirements
on
the network;
memory
constraints again on the client that requested
the search once
the results
are returned. In the spirit of cooperation,
let
me suggest
that you
consider RFC 2696 (but you'll need to put
controls back in).
You simply cannot claim that you have solved
the
search
problem once and
for all, that my examples haven't, and use
that
to justify
ignoring my
other complaints. I will address the
implementation of
searching in my
proposed scenario if it comes down to it but
we
need first to
discuss the
model since the model is the central argument.
First though,
I think we
need to dispel this argument that the problem
is
a federated
namespace
problem. If that were the case then I need to
buy a
meta-directory not a
provisioning system and we are all on the
wrong
committee. It
might be
easy to simply say that the current proposal
is a
bottom-up
approach and
that I'm suggesting a top-down approach. My
real
argument is
that we need
to talk about provisioning and what that means
in
terms of a
simple useful
model that integrates well with modern web
services
technology, not how we
simply get an attribute value from point A to
point B. We
need to address
the problem at the right level of abstraction
so
that the
foundation we
build today will continue to meet the needs of
the community
when/if we go
on to address the other apsects of a
provisioning
model such
as
entiltlements, policies and even simpler
issues
such as change
notifications.
I'm not out to win an argument here, I simply
want to do the
right thing.
At this point I don't want to reiterate my
apparently wasted
arguments on
provisioning-centric solutions because I think
my
views are
clear. We can
continue to talk about attributes,
objectclasses,
controls,
DSML search
filters etc. as much as you want. My question
is
when are we
going to
start talking about provisioning?
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/10/2003 11:44 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard
Woods/Irvine/IBM@IBMUS
|
| cc:
provision@lists.oasis-open.org
|
| Subject: RE: [provision] Simple
example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
Let me answer some of this with an example.
In the Tiny Telecom example, the friends and
family account
has up to
ten contacts that can be associated with it.
Since people
could be a
contact for more than one person it makes
sense
that the
contact could
be an independent record. In this case
creating
the friends
and family
account could consist of:
1) Creating or looking up one or more contacts
2) Creating a friends and family account with
references to
the newly
created or existing contacts
This example illustrates two points. First not
everything in a
provisioning system is an account that can be
suspended.
Second,
searching for existing records may be an
important part of a
provisioning process. Note that nothing I say
in
this
paragraph has
anything to do with directories.
Finding existing contacts in a telco
environment
may require
searching
through millions of records. Our current
filtered
search
mechanism will
support this in a fashion that has been
demonstrated to be
scalable in
other deployments.
And of course there is the reconciliation
issue
inherent in
enterprise
provisioning. That requires some kind of
parameterized query
(filtered
search) to be done correctly.
So is some form of parameterized query
(filtered
search) a
requirement?
Not for all systems, but the spec must define
it
for where it
is
required or it not complete. It is certainly a
requirement for
our PST
product.
Could some sort of XML Query be used as a
parameterized query
(filtered
search)? It's a possibility, but I would like
to
see an
example before I
could say whether it was a good solution.
I am willing to keep an open mind on this and
consider all
proposed
solutions, but I am unwilling to agree to a
solution that does
not
include well thought out solution to
parameterized queries
(filtered
searches). I would also judge such a solution
on
how well it
meets our
specific scalability needs (i.e. it must scale
to
15-30
million user
populations).
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Monday, March 10, 2003 2:03 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example
scenario
Jeff,
Although we've probably covered most of this
in
the call this
morning, I
imagine that we'll want to keep this thread
going
through the
week so
I'll
address the questions that you have here.
Filtered search I think we've agreed is made
more
difficult
when the
schema
becomes more complex. My approach to this
problem is twofold
and I
think
we've touched on these before. First, if
really
required by
the PST
requirements and use cases then I would argue
a
solution could
be found
in
one of the XML query langauges currently
available.
Alternatively, I
would
question the need for a full blown query
language
at all
considering the
use cases. I tend to favour this latter
position
and think
that the use
cases could be satisfied with a set of methods
and schema
elements
targeted
to querying aspects of the model. I can
expand
on this if you
want some
more concrete examples.
PSP-PST communication doesn't differ
significantly from RA-PSP
communication in this approach. The model
would
be the same
but
obviously,
it would be common to have the PSP support
many
targets.
I disagree with your point about the state
implying accounts,
the
enumerations seem relatively general to me.
If
you are
arguing that
they
are not extensive enough then I would agree
that
there is
probably room
for
more.
As we discussed in the call, since we are
satisfying the same
use cases,
our operations (which to me embody the use
cases)
will appear
very
similar.
Where the significant difference lies is in
the
model used in
theses
conversations. As far as the target being
semantically
equivalent to an
objectclass I would have to say that no, a
target
is a
distinct entity.
A
target has identity which an objectclass does
not. An
objectclass
implies
type - a target encapsulates schema. I think
there is a
significant
difference here.
The current request schema message satisfies
the
query target
schema
uses
cases as does the getTarget method in my
example.
Constraining the schema is an important point
and
here I think
is where
we
diverge most in our approaches and general
philosophy. I
don't see the
need to constrain the schema any more than
LDAP
or the current
approach
dictates what specific objectclasses may be
used.
I think
I've argued
before that the target schema is a contract
and
the PSP or RA
on the
other
side of the relationship needs to understand
the
language of
the
contract,
as identified by the schema namespace. My
examples provide
only for
the
ability to declare what schema element
represents
the type of
the
target.
As I mentioned earlier too, I don't want to
even
restrict the
schema
language to XML-Schema. It should be possible
to
use other
schema
languages, a good example might be Oasis'
Relax
NG.
The philosophical difference at the root of
the
schema
argument is
critical. My view is that the SPML should be
a
vehicle for
the
communication of provisioning-related
information. This does
not extend
to
constraining the target schema which should be
opaque to the
provisioning
system. The SPML only provides the
provisioning
model not the
target
model.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/10/2003 04:43 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard
Woods/Irvine/IBM@IBMUS
|
| cc:
<provision@lists.oasis-open.org>
|
| Subject: RE: [provision] Simple
example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
I am just starting to look at the scenario
this
morning, so I
don't know
how much of an example I can have back to you
by
today's
meeting.
Looking at it, I do have some concerns and
questions.
Concerns:
My biggest concern is that you do not show an
example of a
filtered
search. This scenario should include it
somehow.
This scenario does not show an example of the
communication
between a
PSP and a PST. That should also be included.
The ProvisioningSubscriptionState type implies
that all SPML
will be
used for is for provisioning accounts, and
further, that those
accounts
will support the enumerated states. I don't
believe that these
assumptions are valid or add any value.
Questions:
Is there any semantic difference between
createSubscriptionRequest and
addRequest? Likewise is
modifySubscriptionRequest
the same as
modifyRequest and deleteSubscriptionRequest
the
same as
deleteRequest?
Using the word "subscription" would seem to
imply
that the
protocol only
supports subscriptions, what ever that means.
Also, is the
"target"
element semantically the same as the
"objectclass" attribute
in the
current spec?
Your query targets concept seems to imply the
same concept as
the
current SPML schema query for object classes.
Is
that correct?
The type ProvisioningTargetType contains an
XSD
schema
element. Is this
intended to be completely open ended? If not
how
is it to be
constrained?
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Friday, March 07, 2003 5:03 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example
scenario
Jeff,
I'm attaching a set of documents that attempt
to
take that
next step.
As I
said in a previous message, I'm punting on the
filtered search
for now
until there is at least some feedback on the
overall strategy
but the
scenario does include provisioning an e-mail
account. To view
the
scenario, unzip the attached file and open
examples/telecom/telecom.html.
Gerry
(See attached file: scenario.zip)
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/04/2003 04:51 |
| | AM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard
Woods/Irvine/IBM@IBMUS
|
| cc:
<provision@lists.oasis-open.org>
|
| Subject: RE: [provision] Simple
example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
Gerry,
I suggest doing email as at least as a part;
since that is
what we
already have examples for in the current draft
specifications.
It should
not be much work to add it to what you have
already laid out.
Anyway, the next step should be for you to
take
the scenario
you suggest
(with an added email component) and lay out
the
specific RAs,
PSPs, and
PSTs and do a rough system design. It does not
need to be in
detail, but
there needs to be enough information that you
can
do the
examples using
your proposed approach and I can do the
examples
using the
current
approach.
There is still one concern, however. I'm not
sure
if this
scenario will
illustrate the filtered search problem. I have
no
problem
doing this
exercise, since it should be very informative,
but I will not
support
changing the current data model without a
corresponding
filtered search
solution.
Perhaps as part of the provisioning process
there
could be
some searches
done for possible pre-existing similar
accounts
at the service
providers?
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Tuesday, March 04, 2003 2:20 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Simple example
scenario
Jeff,
I was hoping to take on something a little
more
substantive
but go deep
rather than wide. In other words, rather than
illustrate the
use of
each
of the operations, I'd like to go through the
steps and data
formats
that
you would realistically expect to see used to
describe a
target (or set
of
targets) and provision it, including the SOAP
messages if you
think
that's
appropriate. I don't want to burden you with
a
lot of work or
anything,
I
just want to show what each would look like
soup
to nuts, so
to speak.
I realise that this kind of thing takes time.
If
you feel it
should be
less detailed then let's simplify it but I'd
rather not make
it too
simple.
The important aspects to me are:
- The use of schema since that's one of the
hotspots in our
conversation.
Obviously there are elements in this scenario
that work in my
favour
including cardinality, enumerations, formatted
strings and
complex types
but since those come up in real life I think
that's fair.
- The overall message passing sequence and
content. It's not
clear to
me
which approach would be more chatty or more
verbose in a real
life
situation. Also, this might clarify some of
the
implementation
difficulties since we were debating the level
of
complexity
for an
implementation.
- The composite or aggregate abilities of each
solution.
Would adding an e-mail service to the phone
account be enough
do you
think?
Gerry
|---------+---------------------------->
| | Jeff Bohren |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 03/03/2003 07:21 |
| | PM |
| | |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard
Woods/Irvine/IBM@IBMUS,
provision@lists.oasis-open.org
|
| cc:
|
| Subject: RE: [provision] Simple
example scenario
|
|
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Gerry,
We use the hosted email service example
throughout the spec
document, so
it
would be a good idea to work that into the
scenario. Perhaps
it can be
an
email service that is accessable from the
handset.
Jeff Bohren
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Mon 3/3/2003 5:09 PM
To:
provision@lists.oasis-open.org
Cc:
Subject: [provision] Simple
example
scenario
Further to our discussion in the
conference call
today, I'd
like to suggest
the following scenario as a
starting
point for a
comparitive
study of the
current SPML and the alternative
approach that we
have been
debating. Any
changes, improvements or comments
are, of course,
welcome.
Gerry
Tiny Telecom provides mobile
phone
services to
California
residents. In
addition to the five types of
basic
account that
Tiny
offers:
personal,
personal anytime, family,
corporate,
and prepaid,
subscribers
are offered a
full range of options which are
generally handled
by Tiny's
partners or
subsidiaries. These options
include
voice mail,
caller ID,
call
forwarding, text messaging, web
access,
long-distance,
handset
options, and
a comprehensive friends and
family
calling plan.
To create
a
basic
account, Tiny requires the
subscriber's full
name, a user
name, a credit
card number (and expiration), and
a
valid
California
driver's
license
number. Subscribers may also
provide an e-mail
address for
notification of
changes in the account policy or
for
opt-in
notification of
special offers
from partners. Basic plans have
a
two year term
and for a
limited time all
new accounts receive free caller
ID
as part of a
promotion
by
one of Tiny's
partners.
The friends and family plan is
one
of the most
popular
options
and allows
subscribers to select a set of 10
contacts that
may be
called
at a
significant discount. To
identify
these
contacts,
subscribers
are required
to provide their names and phone
numbers.
Tiny has implemented a
provisioning
service that
manages
their
basic
accounts and also allows partner
services to be
provisioned.
A typical
usage scenario for the service is
the
implementation of the
self-service
facility on Tiny's website. This
facility is
implemented
as a
Java servlet
that is a client of the
provisioning
service and
goes
through
the following
sequence of operations:
1. Offer the user a selection of
provisionable
services
offered by Tiny and
partners
2. Query the schema of the
services
requested
3. Present a form allowing the
user
to enter the
required
and
optional
fields
4. Submit the provisioning
request
for the
services
5. Notify the user of the success
or
failure of
the request
For the purposes of this
scenario,
assume that
the
subscriber
requests
voice mail, text messaging, and
lists two family
members in
the friends and
family plan. The user also
selects
the default
handset
which
they will
receive by mail. When the
account
is activated,
a password
is
automatically assigned to access
voice mail.
Before the
phone
is received
by the user, they return to the
self-service
website to
check
the status of
the request. The self-service
facility allows
the user to
retrieve details
of the account which now reflects
the fact that
an account
has
been
activated, provides access to the
voicemail
password, and
notifies the user
that the request for text
messaging
has been
denied for
technical reasons.
----------------------------------------------------------------
To subscribe or unsubscribe from
this elist use
the
subscription
manager: <
http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist
use
the
subscription
manager:
<http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist
use
the
subscription
manager:
<http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
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] | [List Home]