| Oracle® Communications Services Gatekeeper System Administrator's Guide Release 5.1 E37531-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Services Gatekeeper System Administrator's Guide Release 5.1 E37531-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how to generate, deploy and configure SOAP2SOAP communication services.
You can create SOAP2SOAP communication Services using the Platform Development Studio or directly from the Services Gatekeeper Administration Console
Based on a set of service WSDLs and callback WSDLs, a SOAP2SOAP communication service acts as a proxy service and provides the functionality provided by Services Gatekeeper container services, such as:
SLA enforcement
EDR, CDR, and alarms
Authentication, access control, and accounting
SOAP2SOAP plug-in services can be instantiated using the plug-in manager. The plug-in instances process traffic and connect to individual network nodes. The instances are managed independently of each other.
For application-initiated requests, all requests are routed to the network node defined for the plug-in instance.
For network-triggered requests, the network node should distinguish the application instance the request is targeted to by adding the application instance ID to the URL:
http://IP_Address_of_AT_server:port/context-root_nt/plug-in instance ID_nt/application_instance_ID
The endpoint at which the application instance has implemented the Web Service is provisioned using "Operation: addApplicationEndPoint": see "Provisioning Workflow for SOAP2SOAP Communication Services" for a list of related operations.
If the number of HTTP requests that time-out during a certain time-period exceeds the maximum allowed, the plug-in instance is taken out of operation for a configurable time-period. The HTTP time-out behavior is valid for request between the plug-in instance and the network node. The purpose of this feature is to prevent network nodes that are malfunctioning from incoming requests.
SOAP2SOAP communication services can be generated and deployed using the Administration console:
See "Generated Artifacts for the Communication Service" for a description of the generated artifacts.
To generate a SOAP2SOAP communication service from the Administration console, open the SOAP-SOAP Generation page by selecting OCSG > SOAP-SOAP from the Domain Structure group and enter configuration properties for the communication service using the information in to Table 21-2.
Table 21-1 SOAP-SOAP Communication Service Generation Fields
| Field | Description |
|---|---|
|
Name |
Identifier that ties together a collection of Web Services. Will be a part of the names of the generated war and jar files and the package names for the for the communication service. Following is a list of the generated EARs and the WARs and JARs: wlng_at_Communication service name.ear:
wlng_nt_Communication service name.ear:
|
|
Version |
The version to be used in META-INF/MANIFEST.MF in the EARs for the communication service. |
|
ServiceType |
Defines the service type. Used in SLAs, EDRs, statistics, and so on. The service type to use in the SLAs is: com.bea.wlcp.wlng.soap2soap.ServiceType.plugin.interface_name from_WSDL Example: SmsServiceType |
|
ContextPath |
The context path for the Web Service. Example: myService |
|
Service WSDLs |
Enter the name of and path to each WSDL file that includes the service definition to be implemented by the new communication service. Use one file per line. The files must reside on a file system that can be reached by the Administration server. Examples: D:\standards\ParlayX2.1\wsdl\parlayx_sms_send_service_2_2.wsdl D:\standards\ParlayX2.1\wsdl\parlayx_sms_notification_manager_service_2_3.wsdl D:\standards\ParlayX2.1\wsdl\parlayx_sms_receive_service_2_2.wsdl |
|
Callback WSDLs |
Enter the name of and path to each WSDL file that includes the callback service definition to be used by the new communication service in sending information to the service provider's application. Use one file per line. The files must reside on a file system that can be reached by the Administration server. Example: D:\standards\ParlayX2.1\wsdl\parlayx_sms_notification_service_2_2.wsdl |
On successful generation of the communication service, the deployment screen is displayed: see "Deploy a Communication Service".
You can also generate a SOAP2SOAP communication service by using the Eclipse wizard provided with the Platform Development Studio. See "Using the Eclipse Wizard" in the Oracle Communications Services Gatekeeper Platform Development Studio Developer's Guide.
After a SOAP2SOAP communication service has been generated using the Administration Console (see "Generate a Communication Service"), the deployment screen is displayed.
When deploying directly from the Administrating console, complete the entry fields described in Table 21-2 and click the Deploy SOAP2SOAP button. In this case, the communication service is deployed to the same domain as where it was generated.
Table 21-2 SOAP-SOAP Communication Service Deployment Fields
| Field | Description |
|---|---|
|
Name |
Name of the communication service. Same as the name entered in the Name field in SOAP2SOAP Communication Service screen. Do not change this. |
|
Version |
The version use when deploying the communication services. |
|
UserName |
User name for an Oracle Communications Services Gatekeeper administrative user. |
|
Password |
Password that corresponds to the user name. |
The generated communication service can also be deployed using WebLogic tools: see "Generated Artifacts for the Communication Service".
After the communication service has been deployed, create one or more plug-in instances. See "Managing and Configuring SOAP2SOAP Communication Services" for more information.
When a SOAP2SOAP communication service is generated, the following directory structure is created in the directory Domain_Home/soap2soap on the Administration Server.
Example 21-1 Directory Structure from Generating SOAP2SOAP Communication Services
+- <Communication service name>_<version>/ +- build.properties +- build.xml +- common.xml +- <Communication service name>/ +- common/+- resources/ +- enabler/ +- facade/ +- handlerconfig.xml +- dist/ +- com.bea.wlcp.wlng.soap2soap.<service type>.store_<version>.jar +- wlng_at_<Communication service name>.ear +- wlng_nt_<Communication service name>.ear +- plugins/ |+- soap/ +- tmp/
All Java source files, build files, configuration files, and deployable artifacts are created under the directory Domain_Home/soap2soap. The source files are there mainly for reference. The only files that are necessary to deploy the communication service are:
wlng_at_communication_service_name.ear
wlng_nt_communication_service_name.ear
wlng_at_communication_service_name.ear should be deployed in the Access Tier server.
wlng_nt_communication_service_name.ear should be deployed in the Network Tier server.
The generated communication service can be deployed as a part of the generation process, as described above, or using standard WebLogic Server tools.
See "Deploy and Undeploy Communication Services and plug-ins" for information on how to deploy the files using WebLogic Server tools.
This section contains a description of the configuration attributes and operations available for SOAP2SOAP-type of plug-in instances.
| To see a | Refer to |
|---|---|
|
Detailed list of necessary for managing and configuring a plug-in instance |
|
|
Configuration workflow |
|
|
List of operations and attributes related to management and provisioning |
|
|
Reference of management attributes and operations |
| Property | Description |
|---|---|
|
Managed object in Administration Console |
domain name > OCSG > server name > Communication Services > plug-in instance ID |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlngt InstanceName is same as plug-in instance ID Type=com.bea.wlcp.wlng.httpproxy.management.HTTPProxyMBean |
|
Network protocol plug-in service ID |
Defined when generating the SOAP2SOAP plug-in using the Platform Development Studio. When generated fm the Administration console, the ID is Name_soap_plugin. |
|
Network protocol plug-in instance ID |
The ID assigned when the plug-in instance is created: see "Managing and Configuring the Plug-in Manager". |
|
Supported Address Scheme |
Defined when generating the SOAP2SOAP plug-in using the Platform Development Studio. When generated fm the Administration console, the address scheme is always an empty string. |
|
Application-facing interfaces |
Derived from the package name of the network protocol plug-in, assigned when the plug-in was generated, and the name of the interface as defined in the WSDL. For application-initiated request:
For network-triggered requests:
See "Managing and Configuring the Plug-in Manager" for information on how to list the interfaces. |
|
Service type |
Given when the plug-in was generated using the Platform Development Studio or the administration console. |
|
Exposes to the service communication layer a Java representation of: |
Depends on the WSDLs used. |
|
Interfaces with the network nodes using: |
The same protocol as exposed by the application-facing interfaces. |
|
Deployment artifacts |
communication service identifier_protocol_plugin.jar, communication service identifier_service.jar and communication service identifier_callback.war, packaged in wlng_nt_communication service.ear communication service identifier_callback.jar and communication service identifier.war, packaged in wlng_at_communication service identifier.ear communication service identifier was given in the Eclipse wizard or the Administration console when the communication service was generated. protocol is configurable when using the Eclipse wizard. If the communication service was generated using the Administration console, it is always |
Following is an outline for configuring the plug-in using the Administration Console:
Create one or more instances of the plug-in service: see "Managing and Configuring the Plug-in Manager". Use the plug-in service ID as detailed in "Properties for SOAP2SOAP Plug-ins".
Using the Administration Console or an MBean browser, select the MBean for the plug-in instance. The MBean display name is the same as the plug-in instance ID assigned when the plug-in instance was created.
Configure the authentication credentials to be used by the plug-in towards the network node:
Specify which authentication method to use towards the network node:
Specify the URL of the network node to connect to:
Specify the HTTP time-out behavior:
Specify heartbeat behavior; see Configuring Heartbeats.
Set up the routing rules to the plug-in instance: see "Configuring the Plug-in Manager". Use the plug-in instance ID and address schemes detailed in "Properties for SOAP2SOAP Plug-ins".
Note:
If the SOAP2SOAP plug-in is the only plug-in for the service enabler, routing based on destination address is not applicable. All requests will be routed to the plug-in instance. If there are non-SOAP2SOAP plug-ins in the service enabler, the routing applies.Provide the administrator of the network node server with the URL to which it should deliver network-triggered requests. The default URL is
http://IP Address:port/context-root_nt/plug-in instance ID/application instance ID
The default context-root is the communication service ID, as specified when the communication service was generated.
The plug-in instance ID is the ID of the plug-in instance. The network node is assumed to specify which application instance the request is targeted to by adding the application instance ID as the suffix in the URL.
If required, create and load a node SLA. For details see "Defining Global Node and Service Provider Group Node SLAs" and "Managing SLAs" in the Oracle Communications Services Gatekeeper Accounts and SLAs Guide.
Continue with the provisioning of service provider accounts and application accounts.
For each application that uses SOAP2SOAP communication services and supports network-triggered requests, set up a mapping between the application instance ID and the URL for the Web service that the application instance implements. Use the following operations to manage the callback URLs for the application instances:
Following is a list of attributes and operations for configuration and maintenance:
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies whether HTTP Basic Authentication shall be used when authenticating with the network node. Enter:
true to use HTTP Basic Authentication
false otherwise.
Scope: Cluster
Unit: Seconds
Format: Integer
Specifies a time period during which a number of HTTP time-outs are counted.
Scope: Cluster
Unit: Not applicable
Format: Integer
Specifies the number of HTTP time-outs allowed during a time-period. The time-period is specified in Attribute: HttpTimeoutPeriod.
If the number of time-outs are exceed, the plug-in instance transfers to state disconnected, which means that it does not accept new requests. It stays disconnected during the time-period defined in Attribute: ReactivateTime.
Scope: Cluster
Unit: Seconds
Format: Integer
Specifies the HTTP time-out value. If this value is exceeded, the request is considered to be lost and the counter that tracks the number of requests that encountered HTTP time-outs is increased.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the URL to the network node.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the password to use when connecting to the network node.
Scope: Cluster
Unit: Seconds
Format: Integer
Specifies the time a plug-in instance is kept in state disconnected when the number of HTTP time-outs have exceeded the maximum number, specified in Attribute: HttpTimeoutThreshold, over a time-period, specified in Attribute: HttpTimeoutPeriod.
Scope: Cluster
Unit: Not applicable
Format: String
Specifies the user name to use when connecting to the network node.
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies whether Web Services Security UserName Token is used to authenticate with the network node.
true to use UserName Token Authentication
false otherwise.
Scope: Cluster
Adds the URL to which network-triggered requests per application instance should be forwarded. The application is assumed to implement the callback web service on this URL.
Signature:
addApplicationEndPoint(AppinstanceId: String, CallbackUrl: String)
Scope: Cluster
Displays the URL to which network-triggered requests for a given application instance should be forwarded.
Signature:
getApplicationEndPoint(AppinstanceId: String)
Scope: Cluster
Displays a list of all registered callback URLs.
Signature:
listApplicationEndPoints()
Scope: Cluster
Removes the URL to which the network-triggered requests for a given application instance are forwarded.
Signature:
removeApplicationEndPoint(AppinstanceId: String)
|
 Copyright © 2007, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
