Managing SOAP Services

SOAP services managed by the Sentinet infrastructure must be registered in the Sentinet Repository. To register a physical (backend) SOAP service in the Sentinet Repository, select the Repository folder item that the service will be added to, click the Add toolbar button and select the Physical Service->SOAP menu option. Alternatively, you can right-click on the folder item and select the Add->Physical Service->SOAP menu option. Note: if a folder already has registered services, new services can be added to an existing Services group.

Add Physical Service SOAP menu option — Figure. Add Physical Service **SOAP** menu option.

A new SOAP service is added to the Sentinet Repository using the Add Service Wizard that imports service metadata, creates service elements in the Repository and creates a service's first version. There are four options for importing service metadata:

Import Option	Description
WSDL from URL	Import service metadata from a URL that provides WSDL document(s).
WSDL From File(s)	Browse to one or more WSDL part files that cumulatively provide the complete service WSDL metadata. Click Clear button to reset selected files set.
Metadata Set from File	Single MetadataSet document file formatted in compliance with WS-MetadataExchange (MEX) specification (https://specs.xmlsoap.org/ws/2004/09/mex/WS-MetadataExchange.pdf). Several industry tools (for example Microsoft svcutil.exe utility) support MetadataSet documents.
Do not import service metadata	Selecting this option either creates a new service (as a container for future service versions), or a new service and its first service version as Schema First service version. This option can be used when: 1. A new service and its first service version are added with the purpose to design service version as Schema First Service version (see Schema First Service Versions chapter for more details). 2. Service version will be added later to a service container using the same Add Service Wizard. 3. A new service version will be later designed from schemas (see Schema First Service Versions chapter for more details). 4. A new service version will be added from a Sentinet export package.

Figure. Add Service Wizard import options.

The Add Service Wizard creates a new service with its first service version from the existing metadata document(s) if one of the following options is selected:

WSDL from URL
WSDL from File(s)
Metadata Set from File

With any of these options selected, the Repository Web Services Application will download service metadata from the source(s) provided in the import options field. After service metadata is downloaded and parsed by the Repository Web Services Application, the service version structure is presented for the review on the next page of the Add Service Wizard.

Note

Sentinet user has to select all WSDL and XSD schema files when using WSDL from File(s) option. It is not unusual for service metadata to be described by multiple documents (multiple WSDLand XSD files) rather than a single WSDL file. Multiple files can be selected in the File Open dialog box that provides selection for files.

Advanced metadata import options include:

Choice of the Serializer that will be used to process WSDL or Metadata Set documents. Auto is the default and recommended setting. Other serializer options are Data Contract and XML serializer - use these only when the Auto option does not work or produces undesirable results.
Create Schema First service version setting. This setting registers first version of the service as a "Schema First" service version (see Schema First Service Versions chapter for more details). The default setting for this Advanced option can be changed in the User Preferences.
Convert RPC-Literal style operations to Document style setting will cause the conversion of RPC operations to Document style during the metadata import process.
Use wrapped parameters setting is required when special-casing is necessary for document-wrapped-literal styled documents for parameters that are not unwrapped. Use this option when during the WSDL import Sentinet shows error message like "Metadata cannot be processed. An exception was thrown in a call to a WSDL export extension: System.ServiceModel.Description.XmlSerializerOperationBehavior"

Click Next > button to advance to the next screen (review screen):

Add Service Wizard and service structure review — Figure. **Add Service** Wizard and service structure review.

On the metadata review screen, a user can select which service endpoints (if any) will be registered during service registration. Note: if no service endpoints are available in the metadata or the user did not select any service endpoint (contract and schema registration only), then the imported service metadata will be stripped of any policies available in the original service metadata, as policies are attached to service endpoints and their bindings.

By default, a service registered in the Sentinet Repository is promoted to the Active state unless the Sentinet user specifies otherwise, or unless the service is imported with no service endpoints, in which cases the service is registered in the Draft state. Services that are registered manually rather than from existing metadata documents, are always registered in the Draft state.

To add a new service version to an existing service, select the Repository service tree element and click the Add->Service Version option in the toolbar. Alternatively, right-click the selected service and choose Add->Service Version menu option. Service versions are added using the Add Service Version Wizard that goes through exactly the same steps as the Add Service Wizard except that it does not have Do not import service metadata option and it has Design From Schemas option instead.

If the Repository Web Services Application identifies issues with parsed service metadata, it shows errors and warnings in the Add Service (Service Version) Wizard review page.

If Do not import service metadata option was selected in the Add Service Wizard, a user has an option to:

Create a new service as a container for future service versions. Add Service Version Wizard can be later used to create new service version(s). Service name must be provided with this option.
Create a new service and its first service version. New Service version will always be created as a "Schema First" service version (see Schema First Service Versions chapter for more details). Service name must be provided with this option.

Service

Select a Service tree item in the Repository view to review its properties in the Service SUMMARY tab. The Service SUMMARY can be used to review the basic properties of all service versions and to modify the service-friendly name and description.

Note

Sentinet allows assignment of additional reference metadata in the form of attachment links, documents and keywords or tags (see the Metadata Attachments chapter in this guide).

Service Versions

Select a service version tree item in the Repository view to review service version properties in the SUMMARY tab. The service version summary screen is split into two horizontal or vertical panes depending on your User Preferences layout (default is horizontal). The top pane shows the service tree structure that reflects the service definition provided by the service metadata (WSDL). Users can modify service version endpoints, endpoint service identities and policies associated with endpoints, but the service interface and schema definitions cannot be changed for non-virtual services. Users must create a new service version if the non-virtual service interface or schema definition requires change (unless SOAP service is created as Schema First service).

The table below lists service version properties for non-virtual services. Select a service tree element such as Service, Interface, Operation or Endpoint to view or modify respective element's properties.

Service Version Element	Property	Description
Service	State	Service version state (Draft, Active, Obsolete or Retired)
Service	Service Key	Service unique identifier
Service	Service QName Name	Name of the service in its metadata
Service	Service QName Namespace	Service namespace in its metadata
Service Interface	Protection Requirements	Interface-level message protection requirements (Not Set, Sign, Encrypt and Sign, None). Sentinet implements Microsoft WCF Message Protection Levels (https://msdn.microsoft.com/en-us/library/aa347692.aspx). When protection requirement is set to “Not Set,” the effective protection level is determined by the protection level explicitly specified at the levels lower than the interface, or by the highest protection level supported by the endpoint binding and security policies if all lower level protection requirements are also not set.
Service Interface	Session Support	Microsoft-specific requirement on service interface sessions support (Supported, Required, Not Allowed), https://msdn.microsoft.com/en-us/library/ms733040.aspx
Service Interface	Interface QName Name	Name of the service interface in its metadata
Service Interface	Interface QName Namespace	Service interface namespace in its metadata
Operation	Name	Operation name
Operation	Exchange Pattern	Operation exchange pattern
Operation	Deprecated	Marks operation as deprecated (for publishing and informational purposes only).
Operation	Protection Requirements	Same as Service Interface Protection Requirements property but applied to operation level.
Operation	Session Control	Microsoft-specific requirement on service operation session initiation (https://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontractattribute.isinitiating.aspx) and session termination (https://msdn.microsoft.com/en-us/library/system.servicemodel.operationcontractattribute.isterminating.aspx)
Operation	Transaction Flow	Operation-level transaction flow requirement that supports WS-AtomicTransaction and OleTransactions protocols. See https://msdn.microsoft.com/en-us/library/ms733116.aspx for more details.
Request Message	Action	SOAP Action of the request message
Request Message	Direction	Request Message direction
Request Message	Body Protection Requirements	Same as Service Interface Protection Requirements property, but applied to operation’s Message level
Response Message	Action	SOAP Action of the response message
Response Message	Direction	Response Message direction
Response Message	Body Protection Requirements	Same as Service Interface Protection Requirements property, but applied to operation’s Message level
Fault Message	Action	SOAP Action of the fault message
Fault Message	Body Protection Requirements	Same as Service Interface Protection Requirements property but applied to operation’s Message level.
Message Header	Protection Requirements	Same as Service Interface Protection Requirements property but applied to Message Header level.
Endpoint	Name	Endpoint WSDL name property
Endpoint	Physical Address	Endpoint actual transport-specific network address at which service is listening for the incoming messages.
Endpoint	Logical Address	WS-Addressing “To” address, or Endpoint Logical Address. By default, this is the same address as Physical Address. In some rare cases, SOAP services that use WS-Addressing SOAP headers may need to specify “To” address with its own value different from the endpoint Physical Address.
Endpoint	Service Identity	Service Identity assigned to a service version endpoint when endpoint security policy requires specific identity type (see “Service Identity” section below for more details).
Endpoint	Policy	Security and other policies associated with a service endpoint. Policies are expressed as WCF binding configurations (see “Endpoint Policy” section below for more details).
Endpoint	Published	If set to Yes, endpoint will be published in the service metadata (WSDL) document generated by the Sentinet Repository. If set to No, endpoint will not be published in the service WSDL document. (see Service Version Metadata section below for more details on accessing service WSDL documents).
Endpoint	Advanced. Federation. Token Encryption Certificate	X.509 certificate configured with the service endpoint that will be used to decrypt SAML tokens encrypted by external Security Token Services that issue SAML tokens (see Endpoint Advanced Settings section below for more details on Token Encryption Certificates).

Note

Sentinet allows assignment of additional reference metadata in the form of attachment links, documents and weighted keywords or tags (see the Metadata Attachments chapter in this guide).

Service Identity

When a physical SOAP service is registered in the Sentinet Repository using external WSDL document(s), its endpoints are automatically assigned service endpoint identities (if the WSDL document actually defines those identities). A service endpoint can be assigned only one identity. The identity type should match the one that is required by the endpoint policy. Sentinet supports all known standard service identities:

X.509 certificate
Windows Service Principal Name (SPN)
Windows User Principal Name (UPN)
DNS name

Note

Virtual REST services may also be assigned Token Validation Keys for inbound endpoints, which require OAuth service policy and the policy requires knowledge of Token Validation Keys (signing secrets), and when these signing secrets are not configured using <signingSecrets> element.

A specific service endpoint identity can be changed. For example, when a service endpoint is configured with X.509 certificate that needs to be updated, Sentinet Repository can be used to assign the new certificate to a service endpoint. When the service endpoint identity is updated, its WSDL document generated by the Sentinet Administrative console emits a new identity. This helps service consumers to stay in sync with service changes (consumers can use WSDL provided by the Sentinet Administrative console to regenerate their proxies and other required configurations). If a service is virtualized through Sentinet Virtual Service(s), then the virtual service will automatically be updated with the knowledge of the physical service's new identity, thus enabling service consumers to operate with no changes when the physical service's identity changes (service identity changes in this case affect only virtual services and those are automatically updated by the Sentinet infrastructure).

To add a new identity to a service endpoint that does not have an assigned identity and requires it, click the Add button located above the Service Identity table.

Service endpoint Add Identity button — Figure. Service endpoint **Add Identity** button.

Figure. Service endpoint [...] modify and [x] remove identity buttons.

Add Identity button launches the Add Identity Wizard that offers four types of service identities:

Add Identity wizard. Identity type selection. — Figure. **Add Identity** wizard. Identity type selection.

When Service Principal Name (SPN) or User Principal Name type is selected, the next screen prompts to enter a Windows SPN or UPN identity (see https://msdn.microsoft.com/en-us/library/ms733130.aspx for more details on Windows SPN/UPN identity types).

When the X.509 Certificate Identity type is selected, the user is prompted to browse for a base-64 .CER file that contains a X.509 certificate public part.

Figure. Add Identity wizard. Browse for X.509 certificate public part .CER file.

After the certificate is uploaded, its details can be reviewed, the certificate can be saved to another file, or the certificate can be replaced. Replacing a service certificate identity is necessary when a certificate has expired, about to expire, or must be replaced to ensure a specific certificate trust chain. Service SPN or UPN identity is typically updated when the service hosting process is reassigned a Windows account identity that the process is running under. Users update a service identity to:

Ensure updated identity is properly recorded in the Repository.
Ensure service WSDL emitted by the Sentinet Repository contains a recent (updated) identity.
Ensure that virtual services will automatically use an updated virtualized service identity during runtime.

Endpoint Policy

When a service is registered in the Sentinet Repository, its endpoints are assigned policies according to imported service metadata WS-Policy assertions for SOAP services, and Swagger/OpenAPI document for REST services (if Swagger was used to register REST service). Sentinet expresses these policies through its User Interface drop-down choices (Design view for typical security policies and communication protocols), or an advanced Source view of the WCF standard binding configuration elements that take the form of:

<bindings>
  <…WCF Binding…/>  
</bindings>

where <...WCF Binding.../> is an XML fragment with the exact WCF representation of the endpoint binding along with its security, reliability and other policies. Because a policy in Sentinet is expressed through a WCF binding, it also includes a communication transport scheme requirement that must match the actual endpoint address scheme, and possibly other non-interoperable communication and policy elements and attributes specific to Microsoft WCF such as messages quota. Typical Sentinet policy configuration defines only one XML binding element within the <bindings> tag. In some cases, (for example in WS-Federation security scenarios) there might be two binding configurations included within the <bindings> tag, where one binding defines policies of the actual service endpoint, and the other is referenced by the first binding and defines policies for the WS-Federation Security Token Service endpoint.

Below is an example of the Sentinet policy configuration that represents default interoperable basic http policy:

<bindings>  
  <basicHttpBinding>
      <binding name="BasicHttpBinding "/>
  </basicHttpBinding>
</bindings>

Sentinet supports two types of policies---private and shared. Private policies are automatically assigned to the service endpoints when a service is registered in the Sentinet Repository. Changing the private policy affects only the endpoint to which it is assigned, each private policy is assigned to exactly one endpoint in the Sentinet Repository. Shared policies are predefined policies created by Sentinet users. Shared policies are stored in the Sentinet Repository's hierarchical folder structure. Shared policies can be applied to any number of endpoints and changing a shared policy affects all endpoints it is assigned to. It is typical for SOA/API governed environments to create many shared policies that an organization, department or a project is standardizing on, and use them throughout the managed integration solution(s).

To create a new or modify an existing Shared policy, select Repository folder where the shared policy will be stored, and click the Add->Policy toolbar button (or right-click on selected folder item). Provide a policy-friendly name, optional description and policy configuration.

Policy details — Figure. **Policy** details.

To review or modify a policy assigned to a service endpoint, click the [...] modify button.

Policy modify button — Figure. Policy [**...**] modify button.

The Modify Policy Wizard offers three policy assignment options:

Shared
Private from Shared
Private

Figure. Service endpoint policy assignment options.

By default, the selected policy assignment option matches the currently assigned service endpoint policy type, Shared or Private, and current policy configuration is shown. For services registered in the Sentinet Repository via the services metadata import process, the selected Policy Type option will always be Private unless it is later explicitly changed to Shared. A shared policy can be reassigned as a private policy for a selected endpoint, in which case the service endpoint policy receives its own copy of an existing shared policy. The Modify Policy wizard shows all available shared policies registered in the Sentinet Repository when a Sentinet user selects Shared or Private From Shared policy assignment option.

Figure. Available Shared Policies screen.

The Available Shared policies hierarchy starts at the Repository folder that the currently logged-in Sentinet user has access to.

Endpoint Advanced Settings

Physical service endpoints can be configured with an optional Token Encryption Certificate, that this service will use to decrypt SAML tokens issued by external Security Token Services. This Token Encryption Certificate is not an artifact that propagates itself through the physical service metadata (WSDL), which means that this service property must be known at design-time by the Security Token Services (STS servers) that issue SAML tokens and encrypt them with this certificate. The Sentinet Repository helps to provide STS servers with the knowledge of these certificates so that the STS servers can be configured accordingly.

Note: Sentinet Nodes can issue both SAML and JWT tokens effectively acting as an STS or OAuth service. For these scenarios, configuring physical service endpoints with Token Encryption Certificates automatically provides Sentinet Nodes with knowledge on how to encrypt SAML tokens that Sentinet Nodes will be issuing (see Processing -> Settings -> Identities -> Outbound Identities chapter for more details on how to configure Sentinet virtual services to use internal STS server).

To add a Token Encryption Certificate click Add Identity button and navigate to a file with the certificate public part (for example, certificate's .CER file).

Add identity button to add Token Encryption Certificate — Figure. **+Add** identity button to add Token Encryption Certificate.

If a service endpoint already has its own X.509 Service Identity, then the Token Encryption Certificate by default will be the same as service identity certificate.

Figure. Implicit Token Encryption Certificate identity inherited by default from the Service Identity.

Note

Unlike physical services, virtual services hosted on the Sentinet Nodes are always configured with Token Encryption Certificate, which is always the same as the Sentinet Node’s X.509 certificate identity. The Token Encryption Certificate for a virtual service cannot be changed.

Add and Remove Service Endpoints

Services and APIs, deployed as part of a managed API/SOA solution, may experience changes in service endpoints. These changes must be reflected in the Sentinet Repository to maintain design-time and runtime consistency of the managed API/SOA solution.

Design-time consistency gives Sentinet users the knowledge of the current state and configuration of the services.
Runtime consistency provides the Sentinet Virtual Services with the knowledge of changes in the services they virtualize, resulting in an automated and dynamic support for SOA/API agility.

The sections Service Identity and Endpoint Policy above describe how to manage existing service endpoints that require changes in associated policies or service endpoint identities. This section describes how to add new or remove existing service endpoint(s). SOA Services often experience changes in their deployment and hosting environments. Services can be deployed in new hosting environments and get new service endpoints, or they can be un-deployed and "lose" their endpoints. A typical example is an existing service deployed with a single endpoint, which then receives an additional deployment (gets new service endpoints) to support service redundancy and load-balancing. Another typical example is an existing service deployment receiving additional endpoints to support alternative transports and policies.

To remove an existing service endpoint, select the Endpoints tree element of the currently selected service version and click the Delete Endpoint link button. To add a new service endpoint, click the Add Endpoint link button (or right-click the Endpoints element and select the Add Endpoint popup menu option).

Add Endpoint link button — Figure. **Add Endpoint** link button and [X] (delete) endpoint button when **Endpoints** group element is selected.

Delete Endpoint link button when endpoint is selected — Figure. **Delete Endpoint** link button when endpoint is selected.

When a service endpoint is added this way, all endpoint properties must be entered manually. Sometimes existing service endpoints are duplicated with minor changes (for example, a service gets a new endpoint that is different from the existing one only in its address). In this case, the Sentinet user can select an existing service endpoint and click the Clone Endpoint link to clone the currently selected endpoint.

Clone Endpoint link to clone existing service endpoint — Figure. **Clone Endpoint** link to clone existing service endpoint.

Managing Service Version States

Services managed by Sentinet are subject to design-time and runtime state management (see the Service Life Cycle Management chapter).

Click the Promote button to promote a service from the existing state to the next state.

Service version Promote state button — Figure. Service version **Promote** state button.

Service Version Metadata

Once SOAP services are registered in the Sentinet Repository (virtual or non-virtual), their metadata (WSDL documents) are available for immediate review. Any changes made to services afterwards are automatically reflected in the services' metadata provided by the Sentinet Repository. Sentinet users always have access to the latest and consistent state of the services metadata regardless of the availability and the hosting state of the services themselves. For example, service consumers can access the Sentinet Repository to build service consumer application(s) while services might not be physically deployed and/or available for access. When either service deployment or service policy change, service consumers revisit the Sentinet Repository to get updated service information (including updated metadata); thus, the Sentinet Repository serves as a central design-time governance and management tool. Click the WSDL toolbar button and select Wsdl(s) or Single Wsdl menu option to get access to service WSDL document(s).

Figure. WSDL toolbar button and its menu options.

A new browser window opens with the first part (of multi-part) of the WSDL document (for Wsdl(s) menu option) or entire Wsdl document (for Single Wsdl menu option).

Figure. Service Metadata browser window.

The metadata URL shown in the browser address field can be used by other applications and tools that understand HTTP GET semantic. By default, access to a services' metadata through Sentinet URLs is restricted to authenticated users. A service metadata HTTP GET URL is constructed using a Service Version unique key that can be retrieved at the Service Version Details screen.

Service version HTTP GET metadata URL format: https://[machine]/[Sentinet]/metadata.axd/[ServiceVersionKey]?token=[SecurityToken]

Note

When a metadata URL is used outside of the browser session (for example in Visual Studio IDE or by some other tool), it is valid for a limited period of time. Sentinet uses URL-based security with the security token embedded in the HTTP GET metadata URL. By default, the lifetime of this token is 20 minutes. It can be changed in the web.config file of the Repository Web Services Application:

<system.web>         
  <authentication mode="Forms">             
      <forms cookieless="UseCookies" defaultUrl="Default.aspx" loginUrl="Login.aspx" 
           timeout="20" slidingExpiration="true" protection="All" />             
  </authentication>                      
…

Note

Security can also be completely disabled for HTTP GET metadata URLs. To disable metadata HTTP GET security, add metadata.axd handler to the list of ASP.NET resources with allowed anonymous access. Change web.config file of the Repository Web Services Application:

<!-- Uncomment to disable security for metadata HTTP(S) GET retrievals --> 
<location path="Metadata.axd">     
  <system.web>       
      <authorization>         
          <allow users="*"/>       
      </authorization>     
  </system.web> 
</location>   
…

Note

When HTTP GET metadata security is disabled, service metadata can be retrieved using the simplified URL that does not require token query parameter: https://[machine]/[Sentinet]/metadata.axd/[ServiceVersionKey]

Sentinet console provides three options (dropdown menu options) for metadata document(s) retrieval.

Wsdl(s). This option retrieves metadata in WSDL 1.1 format as multipart documents. This option always guarantees successful metadata retrieval.
Single Wsdl. This option retrieves metadata in WSDL 1.1 format as a single flat file document. This option guarantees successful metadata retrieval only if all service interfaces are defined in the same namespace.
Metadata Set. This option retrieves metadata in the format described by WS-MetadataExchange specification, https://www.w3.org/TR/ws-metadata-exchange. This option always retrieves metadata as a single flat file document and guarantees successful metadata retrieval. Metadata Set format is less common than WSDL 1.1 format and may not be available for some third-party tools that process services metadata.

Selecting option 2 or 3 above, modifies service version's metadata HTTP GET retrieval URL:https://[machine]/[Sentinet]/metadata.axd/[ServiceVersionKey]?format=[wsdl|swsdl|metadata]&token=[SecurityToken], where format query parameter takes values wsdl (default and can be omitted), swsdl (for single WSDL document) and metadata (for Metadata Set).

Reload Metadata

Metadata for any existing physical service can be updated by reloading WSDL document(s). This feature requires a careful usage as it can cause undesirable results especially when physical service is already virtualized through an active virtual service. Most often, Reload feature is used when changes to an existing physical service are not too “drastic” (for example, new operation is added or existing operation is removed).

Reload menu option — Figure. **Reload** menu option.

Message Schemas

Along with service metadata, Sentinet can produce XSD schemas for individual operation messages. To review message schemas, select Request or Response message (Response message is available for two-way, Request-Response operations), and select Schemas tab.

Operation's Request message and Schemas tab — Figure. Operation's Request message and **Schemas** tab.

Sentinet Console will download the message schemas and display them as a list of individual XSD schema links.

Click the hyperlink of the Message schema to display its XSD content. The selected message schema link is highlighted in bold, when its content is shown in the schema content window.

Sample Messages

Select Sample Messages tab to generate sample messages for the operation's Request or Response message. Select message SOAP version (SOAP 1.1, SOAP 1.2 or None) and click Generate Sample Message button. The properties Array Size and Max hierarchy levels control how many array elements to generate, and how deep the hierarchy of elements the sample message should include.

Monitoring

Select the MONITORING tab to view real-time and historical service monitoring data (see the Monitoring chapter for more details on Sentinet's service monitoring capabilities).

Schema First Service Versions

By default, Sentinet promotes versioning of physical SOAP services by enforcing "immutable" service contracts. That means, that a physical SOAP service structure (service interfaces, operations and data schemas) cannot be changed, unless a new service version is registered. In some cases, this enforcement may be undesirable. Moreover, there might be a requirement to register a new service version from a "scratch" (manually) knowing only its data schemas. Sentinet supports these scenarios through its Schema First services feature.

Note

Many ESB products that Sentinet manages (for example Microsoft BizTalk Server) define a “Schema First” approach as the only means to expose ESB messaging. For these (and other similar) scenarios, the Sentinet Console can be used as both a service designer and a WSDL publishing tool.

During the service metadata import, a service can be marked as Create Schema First service version (see Create Schema First service version advanced option in the Add Service wizard).

When a new service version is created using Add Service Version menu option, a user may also select Design from Schemas option, rather than importing metadata from the known metadata documents.

Add Service Version dialog box with Design from Schemas option — Figure. **Add Service Version** dialog box with **Design from Schemas** option.

A service designed as Schema First or registered as Schema First service displays SCHEMAS tab. SCHEMAS tab and screen can be used to add, remove or modify data schemas available for the service version operations.

SCHEMAS tab and screen for the Service version data schemas — Figure. **SCHEMAS** tab and screen for the Service version data schemas.

Data schemas can be uploaded from external file(s) or edited in-place.

Note

SCHEMAS tab shows all data schemas available for the service design. Not all schemas need to be used in the service design. For example, a Sentinet user may upload multiple data schemas, but only some of them may be used for the service design at a given design time point.

When designing a SOAP service from "scratch", the same technique is used as with REST services to add service operations and endpoints. For SOAP services, customize service and interfaces QName (Name and Namespace properties):

Right-click Operations or Endpoints tree element to add new operations or endpoints.

When adding a one-way operation, assign a data schema element for the Request message from the data schemas available for the whole service. When adding a Request-Response operation, assign data schemas for both Request and Response messages.

Click Select message schema element link shown above to select data schema element for the Request or Response object from the list of available schemas and schema elements.

Similarly, existing service versions can be updated with new data schemas, should these change:

Add SOAP Fault definitions by using right-click on operation name:

Right-click on Request or Response messages tree element to add SOAP Headers:

Use the Sentinet service version designer to define and customize all service interfaces, operations, endpoints, Request and Response message schemas, as well as custom SOAP Faults and custom SOAP headers.