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