Defining Service Provider Level and Application Level Service Agreements

An application's access rights to BEA WebLogic Network 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 Creating and maintaining service provider and application accounts.

If there is a conflict of values between the service provider SLA and the application SLA, the most restrictive value always applies.

Structure of a Service Level Agreement

The xsds for the SLAs are found in directory $DOMAIN_HOME/policy/sla_schema. The application group SLA xsd is app_sla_file.xsd and the service provider group SLA is sp_sla_file.xsd.

The SLA contains two main types of information specified by the attributes in the <Sla> tag and the contents of the <serviceContract> tags. Listing D-1 Service level agreement XML file overview shows the service provider level SLA XML file's main structure and the relation between the <Sla> and the <serviceContract> tags. Differences between the SLA files on service provider and application level are described in the tag descriptions below the listing.

<Sla [serviceProviderGroupID | applicationGroupID] ="spGroup1"

		<startDate></startDate>

		<endDate></endDate>

		<scs></scs>

				<startDate></startDate>

				<endDate></endDate>

				<startDow></startDow>

				<endDow></endDow>

				<startTime></startTime>

				<endTime></endTime>

		<enforceAcrossGeoSites></enforceAcrossGeoSites>

<Sla>

This tag contains a number of service contracts specifying under which conditions a service provider or an application is allowed to access and use service capabilities.

The serviceProviderGroupID attribute specifies service provider group the service provider belongs to and for which the SLA is valid. For SLAs on application level the applicationGroupID attribute is used instead. It specifies the application group the application belongs to and for which the SLA is valid.

The xmlns:xsi and xsi:noNamespaceSchemaLocation attributes contains processing information and should not be changed.

This tag contains contractual data specifying under which conditions a service provider or an application is allowed to access and use specific services in Network Gatekeeper. One <serviceContract> tag is needed for each service capability a service provider and application shall have access to.

The data to be defined in the <serviceContract> tag for each service capability is described below.

This tag specifies the date the application can start using the service capability. Use format YYYY-MM-DD.

This tag specifies the last date the application can use the service capability. Use format YYYY-MM-DD.

<scs>

The <contract> tag directly following the <scs> tag contains the default restrictions.

This tag, including the sub tags, can also be defined within the <override> tag in order to override the default restrictions, see <overrides> and <overrides>.

The contract data specified within this tag is used for overriding the default contractual data given in the <contract> tag directly following the <scs> tag.

When an override occurs, only the restrictions given in the <override> section are used. That is, all restrictions that are present in the normal contract will be disregarded if not explicitly restated in the override section. No quota definitions are valid within the override section.

<startDate>, specifies the start date the contract data given within the <override> tag is valid. Use format YYYY-MM-DD. Optional tag. If omitted, the start date for the service contract is used.
<endDate>, specifies the end date the contract data given within the <override> tag is valid. Use format YYYY-MM-DD. If omitted, the end date for the service contract is used.
<startDow>, specifies the starting weekday for which the contract data given within the <override> tag is valid. Use 1 for Sunday, 2 for Monday and so on. Optional tag.
<endDow>, specifies the end weekday for which the contract data given within the <override> tag is valid. Use 1 for Sunday, 2 for Monday and so on. Optional tag if <startDow> is not given.
<startTime>, specifies the start time for which the contract data given within the <override> tag is valid. Use format hh:mm:ss, where hh can be 00-24. Optional tag.
<endTime>, specifies the end time for which the contract data given within the <override> tag is valid. Use format hh:mm:ss, where hh can be 00-24. Optional tag if <startTime> is not given.
<contract>, specifies the contract data that overrides the contract data given directly after the <scs> tag. The tags that can be defined within the <contract> tag are described in the sections describing the contract data for each service capability.

Today's date must be the same as or later than startDate
Todays' date must be earlier than endDate (must not be the same date)
Current time must be between startTime and endTime. endTime being earlier than startTime means the limit spans midnight.
Current day of week must be between startDow and endDow or equal to startDow or endDow. endDow being less than startDow means the limit spans the week end.

Since several <override> tags can be defined, with different settings for the time periods for which the restrictions applies, make sure the time periods do not overlap. In the case of overlapping time periods, there is no guarantee which contract that applies.

		<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>

		<startDate>2008-12-01</startDate>

		<endDate>2008-12-30</endDate>

		<startDow>2</startDow>

		<endDow>2</endDow>

Specify <enforceAcrossGeoSites>true<enforceAcrossGeoSites> if the SLA shall be enforced across geo-redundant site, otherwise false.

Contract structure

The listing below illustrates the structure of the <contract> segment of an SLA.

This tag serves to hold together all service-specific data. A <contract> tag occurs once for every <scs> and once for every <override>.

This tag is used to specify a service code that can be used for charging purposes. A service code specified by the application in the application-facing interfaces will be replaced with this code.

This tag is used to specify a number of method requests the service provider or application is guaranteed during a specified time period (in milliseconds). Method requests from service providers and applications having the method tagged as guaranteed will have precedence above 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 stated 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> tag must encapsulate the <methodNameGuarantee>, <reqLimit>, and <timePeriod> tags within a <methodGuarantee> tag.

Each method in <methodNameGuarantee> must also be defined in <methodRestrictions>. The time period defined for a certain method must be identical in both the <guarantee> tag and the <methodRestriction>. See <methodRestriction>.

The number of requests to be guaranteed over the time period given in <timeperiod>.

This tag is used for restricting the number of method requests an application is allowed to do over a short time period, the short time period is referred to as a rate, typically spanning a few seconds. A longer time period, referred to as a quota, typically spans several days.

One <methodRestrictions> tag, including one or more <methodRestriction> tags, is needed for each method that should have restricted usage. Only one <methodRestrictions> tag is allowed.

		<methodName>putMessage</methodName>

			<reqLimit>5</reqLimit>

			<timePeriod>1000</timePeriod>

			<qtaLimit>600</qtaLimit>

			<days>3</days>

			<limitExceedOK>true</limitExceedOK>

		<methodName>putMmMessage</methodName>

			<reqLimit>5</reqLimit>

			<timePeriod>1000</timePeriod>

			<qtaLimit>600</qtaLimit>

			<days>3</days>

			<limitExceedOK>true</limitExceedOK>

The example above specifies the usage restrictions for the methods putMessage and putMmMessage. The usage restriction for the short time period is 5 requests per second (5 requests divided by 1000 milliseconds). The usage restriction for the longer time period, the quota, is 600 requests over a 3 day period.

If the application does not have any usage restrictions within the allowed methods, the whole <restriction> tag should be deleted or commented out.

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 the one being enforced.

Contains restrictions for a method in the application-facing interface. Encapsulates the tags:

<methodName>
<rate>
<quota>

<rate>

This tag defines the maximum number of requests to be guaranteed over a short time period, rate.

<reqLimit> defines the maximum number of requests over the timeperiod given in <timePeriod>
<timePeriod> defines the time period, given in milliseconds.

<quota>

The counters associated with the quota are reset at the beginning of each time period.

<qtaLimit> defines the maximum number of requests over the timeperiod defined in <qtaLimit>.
<days> defines the timeperiod period, given in days (only integers are valid). The starting day (day 0) is the same day as the <startdate> for the service contract. Only one quota limit and time period can be specified per <quota> tag.
<limitExceedOK> is used to specify what action to take if the quota limit is exceeded. If it is defined as true, the request will be allowed even if the quota is exceeded. If it is defined as false, the request will be rejected. An alarm is always emitted if the limit is exceeded.

This tag 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, the <methodAccess> tag should be omitted.

This tag is used to either allow or deny certain parameters values to be provided by applications.

The <params> tag can encapsulate one or more <methodParameters> tags, each containing a <methodName>, <parameterName>, <parameterValues> and <acceptValues> tag.

In the example below, the parameter Content-type is allowed to contain only the parameter values text/application and text/plain for the method sendMessageReq. No other values for this parameter are allowed.

		<methodName>sendMessageReq</methodName>

		<parameterName>Content-type</parameterName>

		<parameterValues>text/application text/plain</parameterValues>

		<acceptValues>true</acceptValues>

Encapsulates the <methodName>, <parameterName>, <ParameterValue> and <acceptValues> tag.

<methodName> contains name of the method whose parameters are to be allowed or denied.
<parameterName> contains the name of the parameter whose values are to be defined as allowed or denied.
<parameterValue> tag contains a list of allowed values. Several values can be defined, separated by white space.
<acceptValues> tag defines if the parameter values shall be allowed or denied. If the tag contains true, the parameter values given are allowed and all other values are denied. If the tag contains false, the parameter values given are denied and all other values are allowed.

A <contextAttribute> tag contains one <attributeName> and one <attributeValue> tag.

A plug-in can retrieve the value specified in <attributeValue> using the name specified in <attributeName>.

    <attributeName>com.bea.wlcp.wlng.plugin.sms.testName1</attributeName>

    <attributeValue>testValue1</attributeValue>

    <attributeName>com.bea.wlcp.wlng.plugin.sms.testName2</attributeName>

    <attributeValue>testValue2</attributeValue>

SLA tags for individual traffic paths

Parlay X 2.1 Third Party Call (BC)

This tag is used to specify the maximum number of active calls the application is allowed to have. If there is no restriction, the tag is deleted or commented out.

This tag is used to specify the maximum number of call legs in a call the application is allowed to have. If there is no restriction, the tag should be deleted or commented out.

Backwards compatible Parlay X 2.1 Short Messaging and MultiMedia Messaging (BC)

This tag is used to define if incoming, mobile originated messages are to be stored in the mailbox.

If true, incoming messages are stored in the mailbox and applications can poll for and list messages stored in the mailbox. When a message arrives to the inbox, an acknowledgement will be sent to the network that the message has been delivered.

If false, incoming messages are not stored in the mailbox. Applications will not be able to poll for messages. When a messages is delivered to an application, an acknowledgement will be sent to the network that the message has been delivered.

The tag is optional, and if omitted the behavior is the same as defining the tag value as false. For performance reasons it is better to omit the tag than to set it to false.

This tag is used for specifying the allowed charging amounts for SMSes. The amounts are specified as a string with spaces between the allowed amounts.

This tag is used for specifying the maximum number of characters allowed in a SMS message. This size can be larger than 160.

This tag is used for specifying the allowed charging amounts for MMSes. Specified as a string with spaces between the allowed amounts.

This tag is used for specifying which content types are allowed in MMS messages. The allowed content types are specified as a string with spaces between the values representing the content types. The content types are specified as MIME types (Type/Subtype), for example image/gif.

This tag is used for specifying which content types are allowed in SMS messages sent from an application. The allowed content types are specified as a string with spaces between the values representing the content types.

NORMAL for text SMSs.
RINGTONE|SM for ringtones in SmartMessaging format.
RINGTONE|EMS for ringtones in EMS format.
LOGO|SM for logos in SmartMessaging format.
LOGO|EMS for logos in EMS format.

Parlay X 2.1 Payment

This tag is used to specify the currencies allowed in the transactions handled by the charging service. The currency code is specified according to the ISO 4217 standard. To avoid too small and too large amounts in transactions, it is possible to specify a maximum and a minimum amount for each currency.

One <allowedCurrency> tag (including the <currencyCode>, <minAmount>, and <maxAmount> tags) is needed for each allowed currency. If all currencies are allowed, the tag is deleted or commented out.

Extended Web Services WAP Push

This tag is used for specifying the maximum number of bytes allowed in a message.

This tag is used for specifying which content types are allowed in a message. The allowed content types are specified as a string with spaces between the values representing the content types.

The content types are specified as MIME types (Type/Subtype), for example image/gif.

For MIME multipart messages, the individual body parts are not evaluated. In order to allow multipart messages, multipart/mixed and/or multipart/related should be included in this tag.

Managing Service Providers and Applications

Defining Service Provider Level and Application Level Service Agreements

Structure of a Service Level Agreement

<Sla>

<serviceContract>

<startdate>

<enddate>

<scs>

<contract>

<overrides>

<override>

<enforceAcrossGeoSites>

Contract structure

<contract>

<serviceCode>

<guarantee>

<methodNameGuarantee>

<reqLimit>

<timePeriod>

<methodRestrictions>

<methodRestriction>

<methodName>

<rate>

<quota>

<methodAccess>

<params>

<methodParameters>

<requestContext>

SLA tags for individual traffic paths

Parlay X 2.1 Third Party Call (BC)

<maxNoOfActiveCalls>

<maxNoOfCallLegsInCall>

Backwards compatible Parlay X 2.1 Short Messaging and MultiMedia Messaging (BC)

<persistMessage>

<allowedCharging>

<maxMessageSize>

<allowedMmCharging>

<maxMmMessageSize>

<allowedContentTypes>

<allowedEncodingTypes>

Parlay X 2.1 Payment

<currencyRestriction>

Extended Web Services WAP Push

<maxMessageSize>

<allowedContentTypes>

SLA attributes for individual traffic paths