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