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