the subscription segments specified here offer more functionality than
needed. They also
address (internal) administration functionality of the retailer to
manage subscription. We
therefore propose to replace this chapter with the new proposed
interfaces as follows
and move the current description either to an annex or delete it.
Due to the changes the text needs editorial work reflecting the changes.
(4.3.1, 4.4)
4.5.1.1 delete create_subscriber operation. This is done by the retailer
system administrator,
which needs this operation. Add a new interface InitialRegistration and
the operation
void register_me (in Subscriber, in end_user). this operation allows the
creation of subscriber
and end-users. The user has than the rigth to use further
segments.Should this go into the initial interface?
Replace in modify_subscriber operation the Subscriber by PropertyList
subscriber_properties.
The exceptions are related to properties, e.g. readonly etc.
When the administrator creates the new customer/subscriber, he gives the
subscriber
the right to use the subscriber admin related interfaces. No other user
can get access
to these segments.
Rename the delete_subscriber operation with unregister_me (). the
operation deactivates
all relationships the subscriber has. The result of this operation
is that all its users, contracts and profiles have to be deactivated
(not deleted as
there might be open bills etc.).
4.5.1.2 remove subscriberInfoQuery interface, add operation
get_subscriber to subscriberMgmt
interface, remove subscriberId from operation.
4.5.2.1 create_service_contract remove subscriber_id. the subscriber
only gets access with
the subscriber id. Add already exist exception
modify_service_contract, remove subscriber_id.
4.5.2.2 remove ServiceContractInforQuery interface, add operation
get_service_contact and
list_subscribed_services to ServiceContractMgmt interface, remove
SubscriberId from
both operations
4.6.1 rename deploy_service to register_service, remove ProviderId, as
the administrator
only provides this interface to srevice providers.
operation modify_service, add explanation that the provider can only
modify the service
properties. Is this operation necessary?
operation withdraw_service, rename to unregister_service, remove
providerId
Remove interface ServiceTemplateQuery annd add operations to
ServiceTemplateMgmt.
remove PorviderId, add for list_service_templates that this is a list of
retailer service templates.
4.7.1 move all operation related to SAGs to subscriber admin segment,
add new
UserManagement interface. Delete the interface SagInfoQuery, move
operations to
UserMgmt or SagMgmt
move create_sag, modify_sag, delete_sag, create_user, add_sag_users,
remove_sag_users
and from (4.7.1.2) list_sags, get_sag, list_sag_users to subscriber
admin segment. Delete
subscriberId as only the subscriber get the right for those interfaces
(from the administrator)
move operations modify_user, delete_user, get_user, list_users to
subscriber admin and
create a new interface UserMgmt for that. Replace in modify_user the
subscriberID and
endUser by userId user_id, userProperties user_properties, add new
operation
void modify_user_sec-props
{in UserId user_id, in PropertyList
security_properties}
raises PropertyError
4.7.2 move serviceProfileMgmt interface to subscriber administration
segment, delete
serviceProfileQuery interface (4.7.2.2) and move operations to
ServiceProfileMgmt
interface.
create_service_profile, delete SubscriberId as only the subscriber gets
this interface,
remove serviceProfileId, its part of serviceProfile
Modify_serviceProfile, remoce subscriberID,replace ServiceProfile by
ServiceProfileId
service_profile_id and PropertyList service_properties, only the service
properties can be
changed.
Remove subscriberId from all operations, as only the subscriber gets
these interfaces.
assign(), rename assign_service_profile, deassign rename
deassign_service_profile,
remove interface ServiceProfileInfoQuery, move operations to
serviceProfileMgmt
interface.
Remove subscriberId
delete list_assigned_users operation.
Add two new operation in Subscriber Segment; assign_sub_segment (in
SegmentID segment_id,
in SagId, sag_id), maybe in a new interface SubscriberAuthorisation ?
and add deassign_sub_segment (in SegmentID segment_id, in SagId,
sag_id). these operations are
used for assigning subscription segments to users. The subscriber may
want to authorise
more users to administer its entries. the authorisation can only be done
to a group,
(see information model), because only there is the for the profiles.
4.8.1 userProfileMgmt interface
modify_security_properties, remove SubscriberId and UserID,
rename modify_user_profile to modify_user_properties, remove
SubscriberId and UserID,
add void create_user_service_profile (in endUserServiceProfile end_user
_serviece_profile)
the user service profile can be empty.
modify_user_serviec_profile, remove SubscriberId and UserID,
delete_user_service_profile, remove SubscriberId and UserID,
get_user_description, delete description, remove remove SubscriberId and
UserID,
list_user_service_profile_ids, remove ids, remove SubscriberId and
UserID,
get_user_service_profile, remove SubscriberId and UserID,
delete UserProfileInfoQuery interface, move operations to
UserProfilemgmt.