CentraSite 10.5 | CentraSite User’s Guide | Runtime Governance | Virtual Service Asset Management | Managing Virtual Service Assets through CentraSite Control | Virtual SOAP Service Management | Adding Virtual Service from an Existing Service
 
Adding Virtual Service from an Existing Service
To create and manage a Virtual Service asset in CentraSite Control, you must have the following permissions:
*Create Assets —OR— Manage Assets
*Manage Runtime Policies (required to configure Virtual Services)
*Mediator Publisher (required to deploy Virtual Services)
Note:
If user has View permission on a Web Service and Create Assets permission for the organization where you will add the Virtual Service, then the user can virtualize that Service. However, the user will not be permitted to configure the processing steps for the Virtual Service that is virtualized unless the user also has the Manage Runtime Policies permission for that organization. Only users with Manage Runtime Policies permission can configure these steps.
Consider identifying a small group of users who will be responsible for configuring the processing steps for a Virtual Service and give this group a role that includes the Manage Runtime Policies permission. Because these users might configure the Virtual Services that other users have added to the catalog, they will also need Modify permission on the actual Virtual Service. To ensure that these users have access to the Virtual Services that they need to configure, consider creating a design/change-time policy that automatically gives this group of users Modify permission on the Virtual Service after it is virtualized.
The following general guidelines apply when adding a Virtual Service in CentraSite Control:
*Ensure that the interface for the Native Service is completely implemented, and that interface is reflected in the WSDL file that is registered for the Web Service in the CentraSite registry.
*An instance of the Web Service is deployed and running at a known point in network.
*The metadata for the Native Service is valid and up-to-date. If the metadata for the Native Service has not been completely specified or is out-of-date, you should update it before you generate the Virtual Service so that you do not carry inaccurate/incomplete data into the Virtual Service.
*To add a Virtual Service asset from an existing (Native) Service
1. In CentraSite Control, go to Asset Catalog > Browse.
2. In the list of asset types, select Service.
3. In the Assets pane, right-click a Web Service for that you want to create a proxy service, and then click Details.
The Web Service Details page is displayed.
4. On the Actions menu, click Virtualize.
Important:
You can not virtualize a Web Service asset that does not have an associated WSDL file.
5. In the Virtualize Web Service wizard, provide the required information for each of the displayed data fields.
Field
Description
Name
(Optional). Name of the Virtual Service.
The name of a Virtual Service asset must be NCName-conformant, meaning that:
*The name must begin with a letter or the underscore character (_).
*The remainder of the name can contain any combination of letters, digits, or the following characters: . - _ (that is, period, dash, or underscore). It can also contain combining characters and extender characters (for example, diacriticals).
*The name cannot contain any spaces.
*Furthermore, if the Virtual Service name contains any non-conformant character, upon publishing the Virtual Service to any gateway, the non-conformant character is simply replaced with the underscore character (_) in Mediator. However, in CentraSite the Virtual Service name defined by you is displayed.
For more information about the NCName type, see http://www.w3.org/TR/xmlschema-2/#NCName
Note:
The name of a Virtual Service asset must be unique within an organization. If, for example, a Virtual Service asset with the same name already exists in the CentraSite registry, a warning message will be issued.
Description
(Optional). The description for the Virtual Service.
Note:
This is the description information that users will see when they view this Virtual Service asset in the CentraSite user interfaces. Therefore, we recommend that you specify a meaningful description for each Virtual Service.
Organization
The organization to which you want to add the Virtual Service. (The Organization list only displays organizations for which you have the Manage Assets permission or at least the Create Assets permission.)
Note:
Select the organization with care. You cannot change the organization assignment after the Virtual Service is added to the catalog. You can, however, export a Virtual Service from one organization and import it to another.
Version
(Optional). The version identifier for the Virtual Service. You can enter any string in this field, that is, the version identifier does not need to be numeric. You can also leave the field blank. You can later create new versions of the Virtual Service to indicate that the Virtual Service has been updated. The default is 1.0.
Examples:
0.0a
1.0.0 (beta)
Pre-release 001
V1-2007.04.30
You can use any versioning scheme you choose. The version identifier does not need to be numeric. This is the "public" version identifier that CentraSite Control shows to users when it displays the list of services.
In addition, CentraSite automatically generates a system version number, which is visible on the Virtual Service detail page. The system version number is independent from the version number you specify here. For more information, see the CentraSite User’s Guide.
Create a Run-Time Policy
Select this check box to specify the behavior for the run-time policy (or policies) associated with the Virtual Service. If you select the check box, the run-time policy or policies associated with the Virtual Service will be created automatically when the Web Service is virtualized. If you do not select the check box, the run-time policy or policies will not be created when the Web Service is virtualized.
This check box is not disabled, since the run-time policy creation fromCentraSite is disabled by default. However, you can enable the same by modifying thecentrasite.xml file. For the procedure, see Enabling CentraSite Run-Time Aspects. If the CentraSite run-time policy configuration is enabled, you can select the check box if you have the Manage Runtime Policies organization-level permission.
6. Click Next.
7. In the Attribute Mapping dialog box, choose the attributes of the Web Service you want to copy to the Virtual Service.
Follow these general guidelines, when specifying attributes for the Virtual Service:
*If you choose a parent attribute, by default, all of its child attributes are copied as well.
*To remove a parent attribute or a child attribute, clear the corresponding check box.
*When you cancel the selection of a parent attribute, CentraSite revokes the selection of all its child attributes.
*Attributes defined as required in the asset’s type definition and all referenced objects to which the asset has an association are internally copied from Native Service to the Virtual Service. By default, the check boxes of these attributes are selected and disabled in the Attribute Mapping dialog box.
8. Click Finish.
The WSDL interface and the entry/exit protocol (for example, HTTP, HTTPS or JMS) of the Virtual Service are identical to the Web Service.
The details page of the newly created Virtual Service asset is displayed.
9. Configure the extended attributes (contained within the profiles) of the Virtual Service asset to suit your requirements.
Note:
Although the type definition of a Web Service asset contains one or more custom profiles, the newly created Virtual Service will not contain any of these custom profiles.