This chapter includes the following topics:
Note:
Oracle SOA Suite does not support multiple bindings for service or reference binding components (for example, specifying both SOAP 1.1 and SOAP 1.2 in the composite.xml
file). Support is only provided for a single web service binding per service or reference. If you specify multiple bindings, remove all but one and redeploy your SOA composite application.
For more information, see the following documentation:
Introduction to Binding Components for conceptual details about binding components
You can attach and detach security policies to and from binding components included in a currently deployed SOA composite application (for example, web services and JCA adapters). Policies apply security to the delivery of messages. Oracle Fusion Middleware uses a policy-based model to manage web services.
Note:
Before attaching policies, see Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use in your environment.
To manage binding component policies:
Access this page through one of the following options:
From the SOA Infrastructure Menu... | From the SOA Folder in the Navigator... |
---|---|
|
|
The Dashboard page for the selected SOA composite application appears. The Services and References section of this page displays the binding components being used in the application.
In the Services and References section, select a service or reference.
Click Policies.
The Policies page enables you to view the globally-attached and directly-attached policies, and to attach or detach security policies to and from a service or reference binding component:
The Globally Attached Policies table displays the globally-attached policy name, the policy set, the category (such as Management, Reliable Messaging, MTOM Attachment, Security, or WS Addressing), the violations since the SOA Infrastructure was last restarted, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.
Policy sets provide a means to attach policies globally to a range of endpoints of the same type. Attaching policies globally using policy sets enables an administrator to ensure that all subjects are secured in situations in which the developer, assembler, or deployer did not explicitly specify the policies to attach. Policies that are attached using a policy set are considered externally attached. For information about creating and managing policy sets, see Securing Web Services and Managing Policies with Oracle Web Services Manager.
The Directly Attached Policies table displays the directly-attached policy name, the policy reference status (enabled or disabled), the category, the violations since the SOA Infrastructure was last restarted, and the authentication, authorization, confidentiality, and integrity failures since the SOA Infrastructure was last restarted.
In the Directly Attached Policies section, click Attach/Detach.
If multiple components are available, you are prompted to select the service or component for which to perform the attachment or detachment.
Note:
If you attach a policy to a service binding component (client) and initiate an instance of the SOA composite application in the Test Web Service page, and the policy attachment fails, an Oracle Web Services Manager (OSWM) policy error is not generated and viewable in Oracle Enterprise Manager Fusion Middleware Control.
If the same business flow instance is initiated externally, a policy error is generated and viewable in Oracle Enterprise Manager Fusion Middleware Control.
For service components (such as a BPEL process) or reference binding components, the policy error is always generated and viewable, regardless of whether the business flow instance was initiated externally or internally through the Test Web Service page.
Select the service or component to which to attach or detach a policy.
This invokes a dialog for attaching or detaching policies.
Policies currently attached appear in the Attached Policies section. Additional policies available for attachment appear in the Available Policies section.
Select policies to attach that are appropriate to your environment.
Click Attach.
When you are finished attaching policies, click Validate.
If an error message appears, make the necessary corrections until you no longer have any validation errors.
The attached policy is displayed in the policies table.
Click OK.
For more information, see the following documentation:
Managing SOA Composite Application Policies for the dialogs that are displayed during policy attachment
Securing Web Services and Managing Policies with Oracle Web Services Manager for definitions of available policies and details about which ones to use for your environment
Your environment may include multiple servers with the same policies. However, each server may have their own specific policy requirements. To satisfy your runtime requirements, you can override the property values for some management and security policies attached to service and reference binding components.
For more information on overriding policy values, see Securing Web Services and Managing Policies with Oracle Web Services Manager.
You can publish service binding components to the UDDI registry from a registered UDDI source.
Note:
You cannot publish a reference binding component to the UDDI registry.
You can only publish web services to the UDDI registry. For example, you cannot publish a JCA adapter.
For more information about publishing web services to the UDDI registry, see Administering Web Services.
Note:
You can publish web services to default Oracle Service Registry businesses from Oracle Enterprise Manager Fusion Middleware Control. To publish to nondefault businesses, use the publish option in Oracle Service Registry.
For more information about Oracle Service Registry, including documentation, visit the following URL:
http://www.oracle.com/technetwork/middleware/registry/overview/index.html
To publish a web service to the UDDI registry:
Access this page through one of the following options:
From the SOA Infrastructure Menu... | From the SOA Folder in the Navigator... |
---|---|
|
|
The Services page displays details about the names and types of the services, the SOA composite applications in which the services are used, the partition in which the composite is deployed, the total number of messages processed, the average processing time, and the number of faults occurring in the services.
In the Service table, select a service to publish to the UDDI registry.
From the Actions list, select Publish To UDDI.
The Publish Service to UDDI dialog appears.
Enter the following information:
Field | Description |
---|---|
Service Name |
Displays the name of the selected service. |
Service Description |
Enter an optional description of the selected service. |
System Definition Location |
Displays the WSDL URL to publish to the UDDI registry. For example: http://myhost.mycompany.com:7001/soa-infra/services/default/HelloWorld/client?WSDL |
UDDI Source |
Select the UDDI publishing source from which to register the service. |
Business Name |
Select a business to publish the service. This is the name of the data structure in the UDDI registry. It is assumed that the business has already been registered in the UDDI registry. |
When complete, the Publish Service to UDDI dialog looks similar to the following:
Click OK.
If a reference binding component of the SOA composite application is integrated with Oracle Service Registry (OSR), you can change the endpoint reference and service key in the General section of this page.
The UDDI ServiceKey field automatically displays the value of binding.ws
property="oracle.soa.uddi.serviceKey"
from the composite.xml
file if you selected to use UDDI for runtime resolution of the endpoint.
You can edit the UDDI ServiceKey field after the SOA composite application has been deployed to either:
Change the value as needed.
Add it to a composite that did not use UDDI for runtime endpoint resolution.
The Endpoint Address field represents the endpoint location as defined with the ws.binding
endpointURI
property in the composite.xml
file. The Endpoint Address field is not filled in after the SOA composite application has been deployed, but can override the endpoint location in the concrete WSDL.
The endpoint location order of precedence is as follows:
Dynamically set the binding oracle.soa.uddi.serviceKey
at runtime in the UDDI ServiceKey field.
Dynamically set the binding property endpointURI
at runtime in the Endpoint Address field.
Use the binding property value for oracle.soa.uddi.serviceKey
in the composite.xml
file (viewable and editable in Oracle Enterprise Manager Fusion Middleware Control).
Use the binding property value for endpointURI
in the composite.xml
file (viewable and editable in Oracle Enterprise Manager Fusion Middleware Control).
Use the location specified in the concrete WSDL.
Figure 32-1 shows both fields.
Figure 32-1 Endpoint Reference and Service Key Properties
To change the endpoint reference and service key for OSR integration:
In the UDDI ServiceKey field, change the service key to use during runtime.
In the Endpoint Address field, enter the endpoint address to use during runtime.
You can edit both fields. The value for one field is selected and used based on what you selected in the UDDI Deployment Options dialog during design time. The changes to these fields are persisted in the composite.xml
file during runtime.
For information about design-time tasks such as how to publish a business service, create a connection to the UDDI registry, and configure a SOA project to invoke a service from the registry, see Developing SOA Applications with Oracle SOA Suite.
For information about how to set the inquiry URL during runtime, see Configuring SOA Infrastructure Properties.
Caching of endpoint WSDL URLs occurs by default during runtime. If an endpoint WSDL URL is resolved using the orauddi protocol, subsequent invocations retrieve the WSDL URLs from cache, and not from OSR. You can increase the amount of time that the endpoint WSDL URL is available in cache for inquiry by the service key with the UddiCacheLifetime property. This property invalidates the cache at specified time intervals. The default value is 86400
seconds. The minimum value is 300
seconds.
To configure endpoint caching of WSDL URLs:
The Oracle Service Registry (OSR) provides a common standard for publishing and discovering information about web services. This section describes how to configure OSR against a separately installed Oracle SOA Suite environment.
You can use Oracle SOA Suite with the following versions of OSR:
OSR 11g
OSR 10.3 (with Oracle WebLogic Server 10.3)
OSR 10.1.3
For more information about OSR, visit the following URL:
http://www.oracle.com/technetwork/middleware/registry/overview/index.html
Note:
This section does not describe how to configure OSR against the embedded Oracle WebLogic Server in Oracle JDeveloper.
OSR 10.3 deploys to the 10.3.0.0 version of Oracle WebLogic Server.
OSR 10.3 does not support the 10.3.1.0 version of Oracle WebLogic Server.
This section provides an overview of how to publish a business service. For specific instructions, see the documentation at the following URL:
http://www.oracle.com/technetwork/middleware/registry/overview/index.html
You can also access the documentation by clicking the Registry Documentation link.
To publish a business service:
To create a connection to the registry:
Note:
When you right-click a web service of a SOA composite application under IDE Connections > Application Server in the Resources window in Oracle JDeveloper, the Publish WSDL To UDDI option is disabled.
To configure a SOA project to invoke a service from the registry:
To dynamically resolve the SOAP endpoint location:
Complete the remaining fields in the Create Web Service dialog, and click OK.
The Create Web Service dialog looks as follows.
Wire the reference with the appropriate service component.
In the SOA Composite Editor, click Source.
The composite.xml
file shows the serviceKey
. The property dynamically resolves the endpoint binding location at runtime.
<property name="oracle.soa.uddi.servicekey" type="xs:string" many="false">uddi: d3611b59-1c79-478e-9ae5-874007eb20c4">
If you want, you can also resolve the SOAP endpoint location by explicitly adding the oracle.soa.uddi.servicekey
property in the Property Inspector. This action dynamically resolves the SOAP endpoint location at runtime for any external reference to a web service.
Highlight the reference binding component in the External References swimlane.
In the Property Inspector, expand the Properties section.
Click the Add icon.
In the Name list, select oracle.soa.uddi.servicekey.
In the Value field, specify the value for oracle.soa.uddi.servicekey from the composite.xml
file.
To dynamically resolve the WSDL endpoint location:
Oracle SOA Suite invokes a service for resolving an endpoint. Examples and descriptions are shown in Table 32-1.
Table 32-1 Resolving Endpoints
Endpoint Resolutions | Description | Example |
---|---|---|
Normalized message UDDI |
The OSR UDDI |
For example, with Oracle Mediator: <copy target="$out.property.oracle.soa.uddi.serviceKey" value="uddi:10a55fa0-99e8-11df-9edf-7d5e3ef09eda"/> |
Normalized message |
The normalized message |
For example, with Oracle Mediator: <copy target="$out.property.endpointURI"
value="http://hostname:8001/soa-infra/services
/partition/Project/endpoint_ep"/> |
|
The OSR UDDI Note: This can be overwritten in Oracle Enterprise Manager Fusion Middleware Control. |
<binding.ws port="http://xmlns.oracle.com/UDDIPublishApplication /Proj/BPELProcess1#wsdl.endpoint(bpelprocess1_client _ep/BPELProcess1_pt)" . . .> <property name="oracle.soa.uddi.serviceKey" type="xs:string" many="false">uddi:31040650-9ce7-11df-9ee1-7d5e3e f09eda</property> </binding.ws> |
|
The Note: This can be overwritten in Oracle Enterprise Manager Fusion Middleware Control. |
<binding.ws
port="http://xmlns.oracle.com/UDDIPublishApplica
tion/Project/BPELProcess1#wsdl.endpoint(bpelproc
ess1_client_ep/BPELProcess1_pt)"
. . . >
<property name="oracle.soa.uddi.endpointURI"
value="http://hostname:8001/soa-infra/services/
Partition/Project/bpelprocess1_client_ep"</property>
</binding.ws> |
|
The endpoint location is specified in the concrete WSDL in the binding component section of |
<binding.ws
port="http://xmlns.oracle.com/UDDIPublishApplication
/Project/BPELProcess1#wsdl.endpoint(bpelprocess1_
client_ep/BPELProcess1_pt)"
location="http://hostname:8001/soa-infra/services
/Partition/Project/bpelprocess1_client_ep?wsdl"
soapVersion="1.1"> |
The failover scenario for resolving endpoints is as follows.
Normalized message UDDI serviceKey
Any error on the endpoint access
Log a severe error
Return an error to the user
Normalized message endpointURI
Any error on the endpoint access
Log a severe error
Return an error to the user
composite.xml
UDDI serviceKey
Error on an OSR connection
Log a severe error
Use the composite.xml
endpointURI
if it is coded
Else, return an error to the user
Error for an invalid serviceKey
in the connection
Log a severe error
Use the composite.xml
endpointURI
if it is coded
Else, return an error to the user
Error on the endpoint access
Log a warning error
Use a second (or third) binding template if it exists.
Else, fail over to the composite.xml
endpointURI
composite.xml
endpointURI
Error on the endpoint access
Log a warning error
Fail over to the composite.xml
concrete WSDL endpoint location
composite.xml
concrete WSDL endpoint location
Error on the endpoint access
Log a severe error
Return an error to the user
You can set the inquiry URL, UDDI service key, and endpoint address during runtime in Oracle Enterprise Manager Fusion Middleware Control.
To configure the inquiry URL, UDDI service key, and endpoint reference for runtime:
The Registry Control provides an option for changing the endpoint location. This is a two-step process. The following steps provide an overview. For more specific details, see the Oracle Service Registry documentation:
http://www.oracle.com/technetwork/middleware/registry/overview/index.html
To update WSDL bindings:
Within the Registry Control, click Search.
In the tModel name field, enter the name and click Find tModel.
In the name column, click the name with the description wsdl:type representing portType.
Ensure that WSDL details are shown correctly.
Click the Edit button.
On the right side, click the Overview doc tab.
Under the Add description button, click the Edit icon.
Enter the new URL.
Click Update and save the changes.
To verify, navigate to the service and ensure that the WSDL URL is pointing to a new location.
Follow these steps to publish WSDLs from multiple SOA partitions using the Registry Control, and access them using a separate serviceKey
and bindings.
To publish WSDLs from multiple SOA partitions:
Log in to Registry Control.
http://host:port/registry/uddi/web
Publish the WSDL from the first partition.
Publish the WSDL from the second partition.
Click Publish > WSDL.
Enter values in the Business key and WSDL location (URI) fields.
Select the Advanced Mode checkbox.
Click Publish.
In the navigation tree in the left pane, select the endpoint, bindings, and port type, and ensure that the "new" mode option is selected.
Click Publish.
The following limitations exist for publishing WSDL services from Oracle Enterprise Manager Fusion Middleware Control.
You cannot publish the same service with the same target namespace from different SOA partitions or from different hosts.
There is no option for entering your own service key.
Instead, use the Registry Console to publish the same WSDL service deployed to different partitions to OSR.
To publish WSDLs to UDDI for multiple partitions: