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