[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Simple example scenario
Jeff,
I just received your implementation of the scenario in the current approach
and I have to admit that it looks like you've done a very comprehensive
job. I'd like to spend some time with it over the next couple of days and
perhaps it might be useful if we both summarised our perspectives on the
comparitive advantages and shortcomings of each based on the exercise. I
think this would benefit committee members who don't have the time to wade
through a lot of XML, and would help to highlight the important points of
our recent discussions with these concrete examples at our fingertips.
Since you feel so strongly about the need for filtered searches, I'll post
an updated set of examples with a filtered search to redress the balance
and provide a better point of comparison.
To address your confusion about suspending accounts, I think the problem
comes down to misunderstandings about the schema. It appears to me that
you have misinterpreted my proposed schema and arrived at the conclusion
that all "subscriptions" are accounts and that the model only supports
entities that can be suspended/locked/terminated etc. I was not dismissing
the value of being able to express these notions at all, I was trying to
make light of your continued misinterpretation. Personally, I feel the
idea of state and lifecycle are very important in a provisioning model.
You obviously feel differently but regardless, there is nothing in the
schema that requires that these features be used. Perhaps the problem is
the name subscription although I have to admit that it's hard to find a
term that is not overloaded with even more meaning so I think I'll stick
with it for now.
On the general concerns expressed in your previous message, I want to point
out that I appreciate what I'm asking the committee to consider but that
makes this exercise no less valuable in my opinion. It's encouraging to me
that the attendance at the committee meetings seems to have grown and
includes more interested parties than even a few months ago. This is not
at all surprising because of the increased profile of provisioning of late,
and the entry of large interests such as IBM into the market. Beyond that,
there is a real need for a solid provisioning service definition as we're
all too aware. The discussion we've been having is the start of what, I
imagine, will be a continued wave of questions regarding approach and
current technology trends as the spec undergoes more scrutiny. You and
OpenNetworks have obviously, as you have frequently pointed out, committed
to DSMLv2. There are others, Tivoli among them, who have immediate
problems that cannot be addressed by this kind of solution without, as I
frequently point out, jumping through a lot of uncomfortable hoops. As we
near the end of this exercise, and since you bring it up, I should say that
I feel that the responsibility of the PSTC is not to Burton or any single
member of the committee but to the community of consumers the PSTC's
product. If the community is not served then any number of analyst events
won't matter.
Gerry
|---------+---------------------------->
| | "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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]