[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Simple example scenario
Agreed. Lets aim for Mondays meeting to have a high-level overview of Gerry's proposal with pro-s & cons and the same for the current specification. At this meeting I propose we achieve the following: - Evenly access propos and cons of each approach - Understand the impact and next steps for both - Take a committee vote on Gerry's proposal I'd also like the committee to keep in mind that regardless of the outcome, this debate is very positive. In two weeks we have driven new concepts and "test cases" through the current specification and enhanced our common understanding of the current and future models for a provisioning protocol. In re-opening this issue I believe Gerry has helped us take a step back and review our current specification outside the current delivery chain. This can only be a good thing. With that, I would also like to add that this is not a win/loose situation for either side of the debate - it's all good! Remember the TC is bigger than the 1.0 specification. It is my sincere hope that that we have achieved so far in this committee is the start of an ongoing process that goes past 1.0 to address the needs of a growing and changing market. Specifications can and do change - 1.0 is a release not a fixed immutable point in time or functionality... As this is an important decision point for the committee I suggest all members attend Monday's call. Gavenraj, I suggest you and I spend some time this week to accurately assess member status to ensure we have a clear published list of voting members ready for the meeting. =========================================================== Darran Rolls http://www.waveset.com Waveset Technologies Inc drolls@waveset.com 512) 657 8360 -----Original Message----- From: Paul Madsen [mailto:Paul.Madsen@entrust.com] Sent: Wednesday, March 12, 2003 8:01 AM To: provision@lists.oasis-open.org Subject: RE: [provision] Simple example scenario I personally would welcome the sort of summary of pros/cons for each model that Gerry proposes Paul >-----Original Message----- >From: Gearard Woods [mailto:gewoods@us.ibm.com] >Sent: Tuesday, March 11, 2003 5:12 PM >To: Jeff Bohren >Cc: provision@lists.oasis-open.org >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> > ---------------------------------------------------------------- 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]