| Oracle® Communications Services Gatekeeper Accounts and SLAs Guide Release 5.0 Part Number E16617-02 |
|
|
View PDF |
| Oracle® Communications Services Gatekeeper Accounts and SLAs Guide Release 5.0 Part Number E16617-02 |
|
|
View PDF |
An application's usage policies of Oracle Communications Services Gatekeeper are specified in Service Level Agreement (SLA) XML files. There is an SLA associated with the service provider group and one associated with the application group.
For more information on this administration model, see Chapter 1, "Creating and Maintaining Service Provider and Application Accounts."
For a sample of a complete SLA, see Appendix A, "Sample SLA."
This chapter describes:
The xsds for the SLAs are in /sla_schema/ in Middleware_Home/ocsg_5.0/modules/com.bea.wlcp.wlng.account_5.0.0.0.jar:
app_sla_file.xsd is the application group SLA xsd.
sp_sla_file.xsd is and the service provider group SLA xsd.
An SLA contain can contain three different types of contracts:
<serviceContract>
<serviceTypeContract>
<composedServiceContract>
The SLA must contain at least one <serviceContract>. The <serviceTypeContract> and <composedServiceContract> elements are optional.
The <serviceTypeContract> element includes usage restrictions per service type. The <serviceContract> element defines restrictions on a more granular level: per interface and method. The <composedServiceContract> element defines usage restrictions that apply to multiple communication services.
It is possible to override parts of a <serviceContract> based on time-of-day and day-of-week. This is not possible in a <serviceTypeContract> or <composedServiceContract>.
Example 7-1 shows the service provider level SLA XML file's main structure.
Note:
If the SLA XML file has white space before the
<?xml...> tag, the SLA will not load.Example 7-1 Service Level Agreement Structure
<Sla [serviceProviderGroupID | applicationGroupID] ="<Group>"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="[sp_sla_file.xsd | app_sla_file.xsd]">
<serviceTypeContract>
<serviceTypeName></serviceTypeName>
<startDate></startDate>
<endDate></endDate>
<rate></rate>
<quota></quota>
</serviceTypeContract>
<serviceContract>
<startDate></startDate>
<endDate></endDate>
<scs></scs>
<contract>
....
</contract>
<overrides>
<override>
<startDate></startDate>
<endDate></endDate>
<startDow></startDow>
<endDow></endDow>
<startTime></startTime>
<endTime></endTime>
<contract>
...
</contract>
</override>
</overrides>
</serviceContract>
<composedServiceContract>
<composedServiceName></composedServiceName>
<service>
<serviceTypeName></serviceTypeName>
<method>
<scs></scs>
<methodName></methodName>
</method>
</service>
<service>
<serviceTypeName></serviceTypeName>
</service>
<startDate></startDate>
<endDate></endDate>
<rate>
<reqLimit></reqLimit>
<timePeriod></timePeriod>
</rate>
<quota>
<qtaLimit></qtaLimit>
<days></days>
<limitExceedOK></limitExceedOK>
</quota>
</composedServiceContract>
</Sla>
This element contains service contracts specifying the conditions under which a service provider or an application is allowed to access and use service capabilities.
The serviceProviderGroupID attribute specifies the service provider group to which the service provider belongs and for which group the SLA is valid. For SLAs on application level, the applicationGroupID attribute is used instead to specify the application group to which the application belongs and for which the SLA is valid.
The xmlns:xsi attribute contains processing information and should not be changed.
The xsi:noNamespaceSchemaLocation attribute points to the xsd for the service provider group SLA or the application group SLA, depending on which type of SLA it is:
app_sla_file.xsd is the application group SLA xsd
sp_sla_file.xsd is and the service provider group SLA xsd
The SLA for a a service provider group of application group can contain one or more of the following child elements:
Parent: <Sla>
This element contains contractual data specifying the conditions under which a service provider or an application is allowed to access and use specific service types in Services Gatekeeper. One <serviceTypeContract> element is needed for each service type that a service provider or an application can access.
The data to be defined in the <serviceTypeContract> element for each interface is described below.
The <serviceTypeContract> element contains the following child elements:
Parent: <serviceTypeContract>, <service>
This element specifies the service type to which a <serviceTypeContract> or <service> applies. It specifies an identifier that defines the service type. Use the Plug-in Manager's listServiceType operation to get a list of the service type names. See section “Managing and Configuring the Plug-in Manager” in System Administrator's Guide for information on how to get a list of service types using the listServiceType operation.
For example, the service type for the interfaces for Parlay X 2.1 Short Messaging and RESTful Short Messaging interfaces is Sms.
There can be only one <serviceTypeContract> for a specified <serviceTypeName> element defined in the SLA for a group in the combined set of SLAs (the local SLA and the geo-redundant SLA). For example, if a geo-redundant service provider group SLA defines a <serviceContract> for the CallNotification service type, this service type not be defined in the local service provider group SLA.
Example 7-2 <serviceTypeContract> Element
...
<serviceTypeContract>
<serviceTypeName>CallNotification</serviceTypeName>
<startDate>2008-11-01</startDate>
<endDate>2008-11-30</endDate>
<rate>
<reqLimit>25</reqLimit>
<timePeriod>1000</timePeriod>
</rate>
<quota>
<qtaLimit>250</qtaLimit>
<days>1</days>
<limitExceedOK>true</limitExceedOK>
</quota>
</serviceTypeContract>
<serviceTypeContract>
<serviceTypeName>Sms</serviceTypeName>
<startDate>2008-11-01</startDate>
<endDate>2008-11-30</endDate>
<rate>
<reqLimit>35</reqLimit>
<timePeriod>1000</timePeriod>
</rate>
<quota>
<qtaLimit>350</qtaLimit>
<days>1</days>
<limitExceedOK>true</limitExceedOK>
</quota>
</serviceTypeContract>
...
Parent: <Sla>
This element contains contractual data specifying under which conditions a service provider or an application is allowed to access and use specific interfaces and methods in Services Gatekeeper. One <serviceContract> element is needed for each application-facing interface that a service provider or an application can access.
The <serviceContract> element contains the following child elements:
The <contract> element directly following the <scs> element contains the default restrictions.
To override these default restrictions, use a <contract> inside an <override> element.
See Structure of a Contract for details about the child elements contained within a <contract> element.
Parent: <Sla>
This element is defined all the services that comprise a composed service. The <composedServiceContract> element must contain at least one <service> element.
The <composedServiceContract> element contains the following child elements:
See Structure of a Composed Service Contract for information about composed services and the <service> element.
Parent: <serviceTypeContract>, <serviceContract>, <composedServiceContract>, <override>, <nodeContract>, <globalContract>,
For a <serviceTypeContract>, <serviceContract> or <composedServiceContact>, this element specifies the date the application can start using the service capability.
For an <override>, it specifies the first date that the contract data in the <override> element is valid.
For a <nodeContact>, it specifies the date that the service provider can begin to access the network.
For a <globalContact>, it specifies the date that Services Gatekeeper can begin to access the network on behalf of any service provider.
Use format YYYY-MM-DD.
A later start date on the service provider level service contract overrides this date.
Parent: <serviceTypeContract>, <serviceContract>, <composedServiceContract>, <override>, <nodeContract>, <globalContract>
For a <serviceTypeContract>, <serviceContract> or <composedServiceContact>, this element specifies the last date the application can use the service capability.
For an <override>, it specifies the last date that the contract data in the <override> element is valid.
For a <nodeContact>, it specifies the last date that the service provider can access the network node.
For a <globalContact>, it specifies the last date that Services Gatekeeper can access the network on behalf of any service provider.
Use format YYYY-MM-DD.
An earlier end date on the service provider level service contract overrides this date.
Parent: <serviceContract>, <method>
This element specifies the application-facing interface to which the service contract or composed service contract applies. The content is a Java representation of the Web Service Definition Language (WSDL) that defines the interface.
Use the Plug-in Manager's getServiceInfo operation to get a list of the application-facing interfaces. You need to pass the appropriate service type as a parameter to the getServiceInfo operation. You can obtain a list of service types with the Plug-in Manager's listServiceTypes operation. See section “Managing and Configuring the Plug-in Manager” in System Administrator's Guide for information on using the getServiceInfo and listServiceTypes operations.
Typically, the Java representation is expressed according to the pattern below:
package_name.standard indicator.plugin.interface_name_from_WSDL
For example, the Java representation of the interfaces for Parlay X 2.1 Short Messaging interfaces are:
com.bea.wlcp.wlng.px21.plugin.SendSmsPlugin
com.bea.wlcp.wlng.px21.plugin.ReceiveSmsPlugin
com.bea.wlcp.wlng.px21.plugin.SmsNotificationManagerPlugin
There can be only one <serviceContract> for a specified <scs> defined for a group in its combined set of SLAs (the local SLA and the geo-redundant SLA). For example, if the geo-redundant service provider group SLA defines a <serviceContract> for the com.bea.wlcp.wlng.px21.plugin.SendSmsPlugin interface, this interface can not be defined in the local service provider group SLA.
Parent: <serviceContract>
This element is a container of one or more <override> elements.
SLAs enforced across geo-redundant sites can not contain an <overrides> element.
Parent: <overrides>
The contract data specified within this element is used to override the default contractual data specified in the <contract> element that directly follows the <scs> element.
When an override occurs, only the restrictions specified in the <override> element are used. All restrictions specified in the default contract are disregarded if not they are not explicitly restated in the <override> element.
Each <override> element can contain the following child elements:
<startDate>: Specifies the start date that the contract data in the <override> element is valid. If omitted, the start date for the service contract is used.
<endDate>: Specifies the end date that the contract data in the <override> element is valid. If omitted, the end date for the service contract is used.
<startDow>: Specifies the starting weekday for which the contract data in the <override> element is valid.
<endDow>: Specifies the end weekday for which the contract data in the <override> element is valid. Use 1 for Sunday, 2 for Monday and so on. Optional if <startDow> is not specified.
<startTime>: Specifies the start time for which the contract data in the <override> element is valid.
<endTime>: Specifies the end time for which the contract data given within the <override> element is valid.
<contract>: Specifies the contract data that overrides the default contract data specified directly after the <scs> element. See Structure of a Contract for details about the elements contained within a <contract> element.
For an override to be active all of the following conditions must be true:
Today's date must be the same as or later than the start date.
Today's date must be earlier than end date (must not be the same date).
Current time must be between the start time and end time. If the end time is earlier than the start time, the time period spans midnight.
Current day of week must be between start day of week and end day of week or equal to start day of week or day of week. If end day of week is less than start day of week, the time period spans the weekend.
Since several <override> elements can be defined with different settings for the time periods for which the restrictions applies, make sure the time periods do not overlap. if time periods overlap, there is no guarantee which contract applies.
Example 7-3 <overrides> Element with Two <override> Children
<overrides>
<override>
<startDate>2008-11-01</startDate>
<endDate>2008-11-30</endDate>
<startDow>2</startDow>
<endDow>2</endDow>
<startTime>09:00:00</startTime>
<endTime>10:00:00</endTime>
<contract>
...
</contract>
</override>
<override>
<startDate>2008-12-01</startDate>
<endDate>2008-12-30</endDate>
<startDow>2</startDow>
<endDow>2</endDow>
<contract>
...
</contract>
</override>
</overrides>
Parent: <serviceTypeContract>, <methodRestriction>, <composedServiceContract>
This element defines the maximum number of requests to be guaranteed over a short time period, measured in milliseconds.
The <rate> element contains the following child elements:
Parent: <rate>, <nodeRestriction>, <globalRestriction>
This element specifies the maximum number of requests over the time period specified in the corresponding <timePeriod> element.
Parent: <rate>, <nodeRestriction>, <globalRestriction>
This element specifies the time period in which the corresponding <reqLimit> applies, in milliseconds.
Parent: <serviceTypeContract>, <methodRestriction>, <composedServiceContract>
This element defines the maximum number of requests over a long period of time, measured in days.
The counters associated with the quota are reset at the beginning of each time period.
The <quota> element contains the following child elements:
Parent: <quota>
This element defines the maximum number of requests over the time period defined in the <days> element. Only one <qtaLimit> element can be specified per <quota> element.
Parent: <quota>
This element defines the time period to which the quota limit applies, specified in days. Only integers are valid.
The starting day (day 0) is the same day as the <startdate> element for the service contract. See <startDate>. Only one <days> element can be specified per <quota> element.
Parent: <quota>
This element specifies the action to take if the quota limit is exceeded. If true, the request will be allowed even if the quota is exceeded. If false, the request will be rejected. An alarm is always emitted if the limit is exceeded
Parent: <override>
Specifies the starting weekday for which the contract data given within the <override> element is valid. Use 1 for Sunday, 2 for Monday and so on. Optional.
Parent: <override>
Specifies the end weekday for which the contract data in the <override> element is valid. Use 1 for Sunday, 2 for Monday and so on. Optional if <startDow> is not specified
Parent: <override>
Specifies the start time for which the contract data given within the <override> element is valid. Use format hh:mm:ss, where hh can be 00–24. Optional.
Parent: <override>
Specifies the end weekday for which the contract data in the <override> element is valid. Use 1 for Sunday, 2 for Monday and so on. Optional if <startDow> is not specified.
Parent: <serviceContract>
Deprecated.
This element specifies whether the SLA is enforced across geo-redundant sites.
Caution:
This element should not be used. Instead, use the loadGlobalNodeSlaByType operation to enforce an SLA across geo-redundant sites. If an SLA with the<enforceAcrossGeoSites> element set to true is loaded under the non-geographically redundant SLA type, exceptions are thrown and the SLA provisioning fails.The previous behavior is maintained for backwards compatibility as described below.
Specify <enforceAcrossGeoSites>true<enforceAcrossGeoSites> if the SLA should be enforced across geo-redundant site, otherwise false. The default is false.
If set to true, the SLA cannot contain any <override> elements.
The decision of whether to enforce the SLA across geo-redundant sites is taken at load time using the SLA type parameter.
Optional element. If not used, the default is false.
Example 7-4 illustrates the structure of the <contract> element in an SLA.
Example 7-4 Contract Structure
<contract>
<guarantee>
<methodGuarantee>
<methodNameGuarantee></methodNameGuarantee>
<reqLimitGuarantee></reqLimitGuarantee>
<timePeriodGuarantee></timePeriodGuarantee>
</methodGuarantee>
</guarantee>
<methodRestrictions>
<methodRestriction>
<methodName></methodName>
<rate>
<reqLimit></reqLimit>
<timePeriod></timePeriod>
</rate>
<quota>
<qtaLimit></qtaLimit>
<days></days>
<limitExceedOK></limitExceedOK>
</quota>
</methodRestriction>
</methodRestrictions>
<methodAccess>
<blacklistedMethod>
<methodName></methodName>
</blacklistedMethod>
</methodAccess>
<requestContext>
<contextAttribute>
<attributeName></attributeName>
<attributeValeu></attributeValue>
</contextAttribute>
</requestContext>
<resultRestrictions>
<resultRestriction>
<methodName></methodName>
<parameterRemovalName></parameterRemovalName>
<parameterMatch>
<parameterName></parameterName>
<parameterValues></parameterValues>
</parameterMatch>
<filterMethod></filterMethod>
</resultRestriction>
</resultRestrictions>
</contract>
Parent: <serviceContract>, <override>
This element includes all contract-specific data. There is one <contract> element for every <serviceContract> element and one for every <override> element.
The <contract> element can contain the following child elements:
Parent: <contract>
This optional element specifies the number of method requests that the service provider or application is guaranteed during a specified time period. The time period is expressed in milliseconds.
Method requests from service providers and applications for which the method is tagged as guaranteed have precedence over requests from service providers and applications not having the method tagged as guaranteed.
Requests are given high priority if the request rate is below either the request rate specified in the service-provider-level SLA or the application-level SLA, whichever has the higher request rate. For example, if the service-provider-level SLA guarantees 30 requests per second and the application-level SLA guarantees 40 requests per second, the application level-SLA applies.
The <guarantee> element contains one or more <methodGuarantee> elements.
Each method specified by a <methodGuarantee> must have a corresponding <methodRestriction> element. The time period defined for a method must be identical in both the <guarantee> and <methodRestriction> elements.
Parent: <guarantee>
This element specifies a method for which high priority service is guaranteed. See <guarantee> for details.
The <methodGuarantee> element contains the following child elements:
The <methodGuarantee> element is ignored for mobile-originated traffic.
Parent: <methodGuarantee>
This element specifies the name of the method to have guaranteed precedence.
Use the Plug-in Manager's getServiceInfo operation to get a list of valid method names for a service type. You need to pass the appropriate service type as a parameter to the getServiceInfo operation.You can obtain a list of service types with the Plug-in Manager's listServiceTypes operation. See section “Managing and Configuring the Plug-in Manager” in System Administrator's Guide for information on using the getServiceInfo and listServiceTypes operations.
Parent: <methodGuarantee>
This element specifies the length of time for which the guarantee is applied, in milliseconds.
Parent: <methodGuarantee>
This element specifies the number of requests to be guaranteed over the time period specified in the corresponding <timeperiodGuarantee>.
Parent: <guarantee>
This optional element restricts the number of method requests that an application is allowed over a specified time period. A restriction over a short time period is called a rate. A rate typically spans a few seconds. A restriction over a longer time period is called a quota. A quota typically spans several days.
The <methodRestrictions> element contains one or more <methodRestriction> elements. One <methodRestriction> element is needed for each method for which usage should be restricted. Only one <methodRestrictions> element is allowed per contract.
The <methodRestrictions> element is ignored for mobile-originated traffic.
Example 7-5 shows a sample <methodRestrictions> element with restrictions for quotas and rates. It specifies the usage restrictions for the SendSms and SendSmsLogo methods. The usage restriction for the rate is 5 requests per second (5 requests divided by 1000 milliseconds). The usage restriction for the quota is 600 requests over a 3 day period.
Example 7-5 Method Restrictions Element
<methodRestrictions>
<methodRestriction>
<methodName>sendSms</methodName>
<rate>
<reqLimit>5</reqLimit>
<timePeriod>1000</timePeriod>
</rate>
<quota>
<qtaLimit>600</qtaLimit>
<days>3</days>
<limitExceedOK>true</limitExceedOK>
</quota>
</methodRestriction>
<methodRestriction>
<methodName>sendSmsLogo</methodName>
<rate>
<reqLimit>5</reqLimit>
<timePeriod>1000</timePeriod>
</rate>
<quota>
<qtaLimit>600</qtaLimit>
<days>3</days>
<limitExceedOK>true</limitExceedOK>
</quota>
</methodRestriction>
</methodRestrictions>
The most restrictive limit is always enforced, so if a restriction in a service-provider-level SLA is more restrictive than a restriction defined in an application-level SLA, the service-provider-level SLA is enforced.
If the application does not have any usage restrictions within the allowed methods, omit the <methodRestrictions> element.
Parent: <methodRestrictions>
This element specifies restrictions on the usage of a method in the application-facing interface.
The <methodRestriction> element contains the following child elements:
Parent: <methodRestriction>, <blackListedMethod>, <methodParameters>, <resultRestriction>, <method>
This element specifies the name of the method to restrict.
Use the Plug-in Manager's getServiceInfo operation to get a list of valid method names for a service type. You need to pass the appropriate service type as a parameter to the getServiceInfo operation.You can obtain a list of service types with the Plug-in Manager's listServiceTypes operation. See section “Managing and Configuring the Plug-in Manager” in System Administrator's Guide for information on using the getServiceInfo and listServiceTypes operations.
Parent: <contract>
This optional element is used to block the application from accessing one or more methods in the service capability.
If the application is allowed to access all methods, omit the <methodAccess> element.
The <methodAccess> element contains the <blackListedMethod> child element.
Parent: <methodAccess>
This element contains one <methodName> child element.
It prohibits use of the method specified in its <methodName> child element.
Use a separate <blacklistedMethod> element for each method to block.
Parent: <contract>
This optional element is used both to allow and to prohibit certain parameters values provided by applications.
The <params> element contains zero (0) or more <methodParameters> elements.
Example 7-6 shows a <params> element that allows allowed parameter values A, B, and C for the sendMessage method. No other values for this parameter are allowed.
Parent: <params>
This optional element specifies method parameter values to allow or prohibit.
It contains the following child elements:
Parent: <methodParameters>, <parameterMatch>
This element specifies the name of the parameter whose values are to be allowed or prohibited. The content of this element is the Java representation of the parameter defined in the WSDL. The parameter representation is arg0.name_of_parameter_as_defined_in_WSDL.
You can use the Plug-in Manager's getServiceInfo operation to get a list of valid parameter names for the method. You need to pass the appropriate service type as a parameter to the getServiceInfo operation.You can obtain a list of service types with the Plug-in Manager's listServiceTypes operation. See section “Managing and Configuring the Plug-in Manager” in System Administrator's Guide for information on using the getServiceInfo and listServiceTypes operations.
Example 7-7 shows an example of the parameters that getServiceInfo returns for the sendMessage method for the MultimediaMessaging service type.
Example 7-7 Sample Output from getServiceInfo (type: MultimediaMessaging) for SendMessage
Interface: com.bea.wlcp.wlng.px21.plugin.SendMessagePlugin
Method: sendMessage
Arguments:
java.net.URI arg0.addresses[]
java.math.BigDecimal arg0.charging.amount
java.lang.String arg0.charging.code
java.lang.String arg0.charging.currency
java.lang.String arg0.charging.description
java.lang.String arg0.priority.value
java.lang.String arg0.receiptRequest.correlator
java.net.URI arg0.receiptRequest.endpoint
java.lang.String arg0.receiptRequest.interfaceName
java.lang.String arg0.senderAddress
java.lang.String arg0.subject
Return arguments:
java.lang.String arg0.result
If the parameter is an array (for example, arg0.addresses[]), do not use the brackets in the SLA. For the example, the parameter name in the SLA should be:
<parameterName>arg0.addresses</parameterName>.
Parent: <methodParameters>
This element contains a list of parameter values to allow or prohibit, when contained in a <methodParameters> element. Multiple values can be defined, separated by white space.
If the SLA is regulating the Binary SMS Communication Service, UDH values must be specified in decimal, not hexadecimal, format. In the following example, any UDH with the values of 04, 05, 44, or 7F will be blocked:
<methodParameters>
<methodName>sendBinarySms</methodName>
<parameterName>arg0.binaryMessag[0].udh</parameterName>
<parameterValues>4 5 68 127</parameterValues>
<acceptValues>false</acceptValues>
</methodParameters>
Parent: <parameterMatch>
This element contains one or more <parameterValue> elements.
Parent:<parameterValues> complex
Each <parameterValue> element contains the value of the <parameterName> to match if this element is the grandchild of a <parameterMatch> element. The value can be expressed as a regular expression.
Parent: <methodParameters>
This element specifies whether the parameter values controlled by the containing <params> element are allowed or prohibited.
If <acceptValues> is true, the parameter values specified in the <parameterValues> element are allowed and all other values are prohibited. If false, the specified parameter values are prohibited and all other values are allowed
Parent: <contract>
This optional element is used to send additional parameters, which may not be defined in the interface, to a plug-in. The concept is similar to parameter tunneling, except that the attribute-value pairs are defined in the SLA instead of being passed by the application. For more information see “Parameter Tunneling” in Platform Development Studio Developer's Guide.
The <requestContext> element contains one or more <contextAttribute> elements.
Example 7-8 shows a <requestContext> element that assigns values to two context attributes.
Example 7-8 <requestContext> Example
<requestContext>
<contextAttribute>
<attributeName>com.bea.wlcp.wlng.plugin.sms.testName1</attributeName>
<attributeValue>testValue1</attributeValue>
</contextAttribute>
<contextAttribute>
<attributeName>com.bea.wlcp.wlng.plugin.sms.testName2</attributeName>
<attributeValue>testValue2</attributeValue>
</contextAttribute>
</requestContext>
Parent: <requestContext>
A <contextAttribute> element defines the attribute-value pairs to be sent to the plug-in.
This element contains the following one of each of the following child elements:
A plug-in can retrieve the value specified in <attributeValue> using the name specified in <attributeName>. The plug-in must implement the functionality for fetching the value by name. For more information, see “Using Request Context Parameters in SLAs” in Platform Development Studio Developer's Guide.
See the “Tunneled Parameters” sections in the Communication Service Guide for descriptions of the context attributes that are applicable to your communication service. Note that not all communication services support tunneled parameters and context attributes.
Parent: <contextAttribute>
This element contains the name that the plug-in uses to fetch the attribute.
Parent: <contextAttribute>
This element contains the value associated with the corresponding <attributeName> in the <contextAttribute> element.
Parent: <contract>
This optional element is used to filter results returned from application-initiated requests.
This element contains one or more <resultRestriction> elements.
Example 7-9 illustrates a results filter for the getData() method.
The getData() method returns an array of data, where data is a complex type consisting of the name-value pair:
dataName
dataValue
Example 7-9 <resultRestrictions> Element for Blacklisting Array Parameter Values
<resultRestrictions>
<resultRestriction>
<methodName>getData</methodName>
<parameterRemovalName>result.data[].dataName</parameterRemovalName>
<parameterMatch>
<parameterName>result.data[].dataName</parameterName>
<parameterValues>
<parameterValue>ssn<parameterValue>
<parameterValue>homephone<parameterValue>
<parameterValues>
</parameterMatch>
<filterMethod>BLACK_LIST</filterMethod>
</resultRestriction>
<resultRestrictions>
Assuming the result before the filter is applied is:
result.data[0].dataName = “cellphone”
result.data[0].dataValue =”415-555-1234”
result.data[1].dataName = “ssn”
result.data[1].dataValue =” 123 45 6789”
result.data[2].dataName = “homephone”
result.data[2].dataValue =”415-333-4444”
After applying the result filter, the result is:
result.data[0].dataName = “cellphone”
result.data[0].dataValue =”415-555-1234”
because <filterMethod> is BLACK_LIST and <parameterValues> filters out ssn and homephone. Those data items are removed from the result returned to the application.
If <filterMethod> had been WHITE_LIST, the result after applying the filter would be:
result.data[0].dataName = “ssn”
result.data[0].dataValue =”123 45 6789”
result.data[0].dataName = “homephone”
result.data[0].dataValue =”415-333-4444”
Only these parameters would match the filter that filters in the values in <parameterValues>.
If <parameterRemovalName> had been result.data instead of result.data[] the filtered result would be null in both cases, since both filters match. The absence of the [] means that all results starting from the result.data hierarchy should be removed, given that the filter matches the result.
Parent: <resultRestrictions>
This element defines a result restriction.
The result restriction makes it possible to remove parameters returned from application-initiated requests.
The return parameter to which the restriction applies is expressed as a String representation of a Java class. Arrays are expressed using the [] notation directly following the parameter name. The notation format is:
arg0.result.name_of_parameter_as_defined_in_WSDL when the parameter is a single entity.
arg0.result[].name_of_parameter_as_defined_in_WSDL when the parameter is an array.
If the return parameter is a complex type, the hierarchy is expressed using dot notation. For example, if an array for the dateTime parameter is returned, the return value expressed in XML is:
<xsd:complexType name="SmsMessage"> <xsd:sequence> <xsd:element name="message" type="xsd:string"/> <xsd:element name="senderAddress" type="xsd:anyURI"/> <xsd:element name="smsServiceActivationNumber" type="xsd:anyURI"/> <xsd:element name="dateTime" type="xsd:dateTime" minOccurs="0" maxOccurs="1"/> </xsd:sequence> </xsd:complexType>
The String representation is:
arg0.result[].dateTime.firstDayOfWeek arg0.result[].dateTime.lenient arg0.result[].dateTime.minimalDaysInFirstWeek arg0.result[].dateTime.time.date arg0.result[].dateTime.time.hours arg0.result[].dateTime.time.minutes arg0.result[].dateTime.time.month arg0.result[].dateTime.time.seconds arg0.result[].dateTime.time.time arg0.result[].dateTime.time.year arg0.result[].dateTime.timeInMillis arg0.result[].dateTime.timeZone.ID arg0.result[].dateTime.timeZone.rawOffset arg0.result[].message arg0.result[].senderAddress arg0.result[].smsServiceActivationNumber
The <resultRestriction> element contains the following child elements:
<methodName>: method for which to restrict the return parameter.
<parameterMatch>: optional filter value to match
<filterMethod>: defines how the filter is applied
Parent: <resultRestriction>
The <parameterRemovalName> element defines which part of a complex return parameter is affected by the restriction.
It is possible to specify a leaf or a node in the hierarchy of the parameter. When a node is specified, the node and all its siblings are removed.
If the <parameterRemovalName> element is:
<parameterRemovalName>arg0.result[].dateTime.timeZone.ID</parameterRemovalName>
only the timeZone.ID part of the result parameter is removed, because the element specifies a leaf.
If the <parameterRemovalName> element is:
<parameterRemovalName>arg0.result[].dateTime.time</parameterRemovalName>
all of the dateTime siblings are removed from the result parameters, because the element specifies a node. In this case, the following values would be removed:
arg0.result[].dateTime.time.date
arg0.result[].dateTime.time.hours
arg0.result[].dateTime.time.minutes
arg0.result[].dateTime.time.month
arg0.result[].dateTime.time.seconds
arg0.result[].dateTime.time.time
arg0.result[].dateTime.time.year
If the specified parameter is a Boolean, the parameter is not removed but set to false.
For information on how to get a list of valid parameter names for a method with a specific service type, follow the instructions for <methodName>.
Parent:<resultRestriction>
This element is optional.
If <parameterMatch> is used, result filtering occurs only if the parameter defined in the <parameterName> child element has a value defined in one of its <parameterValue> child elements.
The <parameterMatch> element contains the following child elements:
<parameterName>: exactly one
<parameterValues> complex: exactly one
Parent: <resultRestriction>
This element defines how the filter defined in <parameterMatch> is applied.
The value is an enumeration. Valid values are:
BLACK_LIST
WHITE_LIST
If <filterMethod> is defined as BLACK_LIST, all parameters matching <parameterRemovalName> are removed if the request matches the filter.
If <filterMethod> is defined as WHITE_LIST, only the parameters matching <parameterRemovalName> are kept if the request matches the filter.
A composed service contract is enforced for a composed service.
A composed service is created by combining multiple communication services, all of which must be available and registered in Services Gatekeeper. You can then define and apply enforcements on the composed service, instead of defining identical enforcements separately for each service. A request of any one of the communication services that participate in the composed service is treated as a request of the composed service for the purposes of SLA enforcement.
A single SLA can contain composed service contracts as well as simple service contracts. A composed service contract is located at the same level in the SLA hierarchy as a service contract.
You can define a composed service contract in an application group SLA or in a service provider group SLA.
The composed service contract is created when an SLA containing a <composedServiceContract> element is loaded using the loadApplicationGroupSlaByType or loadServiceProviderGroupSlaByType operations.
A composed service contract includes all the service types of its constituent communication services and all the request rate and quota restrictions that may be applied to those services under an individual service type contract.
A composed service contract can optionally be defined at the method level of granularity so that enforcement is implemented on only specified methods. If individual methods are not specified for a specific service in the composed service contract, enforcement is applied for all methods of the specified service.
A single SLA can contain multiple composed service contracts.
A single communication service can participate as a component in multiple composed service contracts. For example, one composed service named “Messaging” could be composed of the Short Messaging and Multimedia Messaging communication services, while another composed service named “LocationNotification”, defined in the same SLA, could be composed of the Short Messaging and Terminal Location communication services. In this case, the shared Short Messaging service would be subject to the enforcements of both composed service contracts.
It is possible to specify different enforcements that affect a single service within a single SLA. If the enforcements in the multiple contracts are different, the more restrictive enforcement is applied to requests of the shared service. But because separate counters are maintained for each service within a composed service, requests of the non-shared service are not counted towards the limit of the shared service.
For example, imagine an SLA that contains the following contracts, all of which include the Sms service:
a service contract for the Sms service that allows 40 requests per second
a Messaging composed service contract, composed of the Sms service and the Multimedia Messaging service, that allows 50 requests per second
a LocationNotification composed service contract, composed of the Sms service and the Terminal Location service, that allows 60 requests per second
The maximum number of requests to the Sms service will be 40 requests per second. But a request of one of the non-shared services, for example of the Multimedia messaging or Terminal Location service, does not count against this 40-request limit on the Sms service.
All communication services in a composed service share the same budget restrictions in the composed service contract. Any request of the composed service triggers a decrease in the budget. If a request exceeds the budget restriction, subsequent requests of the composed service are denied. The result is that if one of the services in the composed SLA causes the budget of the composed SLA to be exceeded, requests from the other constituent services are denied.
Example 7-10 shows an SLA that contains a simple service contract for the Short Messaging service and a composed service contract for a composed service named “Messaging.”
The Messaging composed service includes the sendSMS and sendSmsLogo operations in the ParlayX2.1 Short Messaging communication service and all of the operations that Services Gatekeeper supports in the ParlayX2.1 Multimedia Messaging communication service.
Example 7-10 Service Level Agreement with Composed Service Contract
<Sla xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" serviceProviderGroupID="default_sp_group" >
<serviceContract>
<startDate>2010-04-17</startDate>
<endDate>2011-04-17</endDate>
<scs>com.bea.wlcp.wlng.px21.plugin.SendSmsPlugin</scs>
</serviceContract>
<composedServiceContract>
<composedServiceName>Messaging</composedServiceName>
<service>
<serviceTypeName>Sms</serviceTypeName>
<method>
<scs>com.bea.wlcp.wlng.px21.plugin.SendSmsPlugin</scs>
<methodName>sendSMS</methodName>
</method>
<method>
<scs>com.bea.wlcp.wlng.px21.plugin.SendSmsPlugin</scs>
<methodName>sendSmsLogo</methodName>
</method>
</service>
<service>
<serviceTypeName>MultiMediaMessage</serviceTypeName>
</service>
<startDate>2010-04-17</startDate>
<endDate>2011-04-17</endDate>
<rate>
<reqLimit>50</reqLimit>
<timePeriod>50</timePeriod>
</rate>
<quota>
<qtaLimit>100</qtaLimit>
<days>1</days>
<limitExceedOK>false</limitExceedOK>
</quota>
</composedServiceContract>
</Sla>
Parent: <composedServiceContract>
This element describes the unique, user-defined name for the composed service.
Parent: <composedServiceContract>
This element defines a constituent communication service in the composed service. The service must be available and registered in Services Gatekeeper.
There must be at least one <service> element in a <composedServiceContract> element. Normally there are multiple <service> elements.
The <service> element contains the following child elements:
The service is identified by the <serviceTypeName> child element of the <service> element. The <serviceTypeName> element is required.
The <method> child element of the <service> element is optional.
Parent: <service>
This optional element, if used, specifies a method of the service to which the composed service contract's enforcements are applied. There can be multiple <method> child elements of a single <service> element.
If at least one <method> element is specified, only the specified method or methods participate in the composed service.
If there are no <method> elements contained in a <service> element, enforcement is applied to all of the service's methods.
The <method> element contains the following child elements:
|
 Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|