[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]