Five Frequently Asked Questions About EXTERNAL Web Services in Fusion Applications

The Fusion Applications OER white paper (introduced in my previous post on Fusion Applications Integration) touches upon the EXTERNAL keyword tagged on services.

As described in the paper, these services are used by customers/partners to extend and integrate with Oracle Fusion Applications, whether in on-premise or SaaS mode. This post describes the keyword in detail by addressing five frequently asked questions.

Q1. What does the EXTERNAL keyword imply for integration scenarios and SaaS deployments?

To understand this, let’s look at the Fusion Applications deployment topology below Note: this shows only SOA Composite services, but is also applicable for ADF Services.

The topology splits visibility to web and service resources into two categories – internal and external. This is achieved by fronting all HTTP requests through two different Oracle HTTP Servers (OHS), one for internal traffic routed between Fusion Applications servers, and another for external sources, which has only a small subset of the routing rules to prevent unauthorized access by external systems. This approach facilitates unhindered access within the Fusion Applications domain and acts as a firewall to restrict access to external systems.

In the example shown above, internal clients (i.e. those deployed in the same Fusion Applications domain) would have access to all composite services – A, B, and C and any service endpoints that they provide. In contrast, all other external clients are restricted to accessing only services provided through composites A and B.

Another characteristic of services that are exposed externally is that they also enforce a more stringent Oracle Web Services Manager (OWSM) policy using SSL or WS-Security message protection. By contrast, services NOT marked as EXTERNAL are protected using the OWSM Global Policy Attachments (GPA) feature, which in the case of Fusion Apps do not enforce message protection and rely only on username token or SAML identity propagation.

As you may have guessed by now, services tagged with the EXTERNAL keyword in OER, are the only ones provisioned with routing rules on the External OHS and protected with a stringent message protected OWSM policy. This is what makes them suitable for application integration use cases; even more so in the cloud where deploying custom services to the SaaS WebLogic Server domain may not be possible.

Q2. The service I want is not marked as EXTERNAL. Can I just tag it with the keyword for my integration project?

As explained above, making a service “EXTERNAL” is more than just tagging the keyword in OER. The service also needs to be secured using a message protection enabled local OWSM policy and requires modification of the OHS routing rules to allow service URI access to the external world. For Oracle-shipped services, this is done by the Provisioning framework. For custom services, this can be possible in on-premise and hosted installations, but may not be possible in the SaaS mode.

Most likely, if an Oracle-shipped service has not been marked as EXTERNAL, it is due to specific functional and/or security reasons, which is usually not addressable at the customer site.

Q3. If I can’t change non-EXTERNAL services, why document them in OER?

While it is true that non-EXTERNAL services cannot be consumed by external clients, they can still be consumed by internal clients, such as custom implemented composites that are deployed in the Fusion Applications SOA domain in on-premise or hosted deployments. Moreover, apart from service invocations, many composite services also have capabilities for layered customizations for BPEL processes and Oracle Business Rules. The OER entries for these non-EXTERNAL services therefore serve as API documentation.

Q4. Are EXTERNAL services the same as “Public” services?

The two terms — “EXTERNAL” and “Public” — are frequently used interchangeably, however, they are not synonymous! “EXTERNAL” refers to service visibility in the topology, while “Public” basically amounts to the level of API support provided by Oracle. In fact, there is no attribute called “Public”, instead it is referenced by the Compatibility attribute value of Supported.

While most EXTERNAL services tend to be Public, there are exceptions. For instance, mobile-enabled services accessed by iPad or iPhone apps (external to Fusion Applications) will be tagged as EXTERNAL. However, if the only intended supported client is the pre-certified mobile app, then the service may be marked with a Compatibility value of Not Supported to effectively make it “Private”.

The Fusion Applications OER white paper also lists the various combinations of the Keyword and Compatibility tags and their implications for service use in integration projects.

Q5. How do I find all available EXTERNAL services?

Using the cloud hosted OER instance. Simply search for EXTERNAL and limit the Asset Type to ADF Service or Composite Service to filter the results.

IMPORTANT NOTE: This is a simple text search and will result in services that have the word EXTERNAL in any metadata, including descriptions. Therefore, you may get false positives. To confirm the service accessibility, always check the Keyword value on the Taxonomy tab of the service detail page as shown in the screenshot at the top of this post.

Hopefully this post has addressed most of the questions about the EXTERNAL keyword usage. If you still have some, feel free to sound off in the comments.

Using Cloud OER to Find Fusion Applications On-Premise Service Concrete WSDL URL

In my previous post on Fusion Applications Integration, the Fusion Applications OER white paper explains Oracle Enterprise Repository (OER) usage in the applications context, assuming a dedicated OER for your Fusion Applications instance (whether cloud/SaaS or on-premise). Having a dedicated OER instance is recommended as it can provide customized service metadata and can be used for overall SOA governance in addition to simple service discovery.

One of the common queries I get is how on-premise customers without a dedicated OER can find a concrete service WSDL URL for their specific environment using the cloud hosted OER instance.

To answer this, let’s understand the two attributes on the OER service details screen.

In the Cloud OER instance, the Abstract WSDL URL link points to the Oracle-shipped non-customized service definition, which can be used by partners/ISVs for developing tenant-agnostic apps (more on that in future posts).

The concrete WSDL URL can be found in the Service WSDL URL link (highlighted in the screenshot above). In an on-premise deployment, this link points to the runtime WebLogic Server where the service has been deployed. Since the cloud OER instance is not linked with on-premise customer-specific runtime environments, the link does not work (as expected). However, you can still derive the on-premise environment-specific concrete Service WSDL URL via a simple substitution.

Replace

rep://FUSIONAPPS_HCM/

with

https://host:port/ for the specific Fusion Applications environment.

The Fusion Apps repository team is working on making usability improvements to document this in-place, along with adding additional service metadata that you are sure to find very handy when consuming the services. Stay tuned!

The World of SOA: Laundries, Legos, and Home Construction

As an architect explaining SOA concepts to developers of traditional enterprise applications, I encountered various analogies comparing the concepts of SOA to Lego^TM blocks, which are actually considered by some experts as being misleading and superficial. Therefore, recent analogies by Antony Reynolds and Richard Veryard comparing services to a laundry, brought back memories of yet another analogy I used a couple of years ago – comparing business process driven SOA to home construction.

Let’s pretend you want to build a house from the ground up. You hire a general contractor, who is responsible for the overall execution of the project. The contractor locates a provider of concrete and makes a phone call to ask for estimates and the schedule for pouring the foundation slab. Next, the contractor will call and coordinate the lumber delivery, following which the framers can come out to do their job. In parallel, the contractor gets estimates from electricians and has to decide on the one that not only has the best rates, but also someone who is certified as per city code and who can meet the schedule. And finally, the roofers, plumbers and painters are arranged to complete the job.

Let’s put this in the perspective of SOA technologies.

SOA Orchestration Explained

The general contractor is a BPEL Process, whose purpose is to orchestrate all the Services from disparate heterogeneous systems. The services in this example are the different actors – the concrete provider, foundation company, lumber company, framers, electricians, roofers, plumbers and painters. The contractor found the providers by searching the Yellow Pages (UDDI) and found the phone listing (WSDL); communicated by voice (XML) over the phone (standards based Web Service) in English (Standardized Semantics). He got quote and availability information, without having to really understand much about the inner workings of the concrete business (Service Abstraction), and as long as the provider abides by the contract, the contractor does not care who the actual electrician is (Service Virtualization).

I found that this metaphor helped many a legacy developer understand the complex SOA technologies better than the overly simplistic Lego^TM blocks analogy. However, as recommended in the other blogs too, it is best to not push the metaphor too far. Once the SOA basics have been understood, its purpose is served; and no other simplistic metaphor can then explain every one of the prolific WS-<insert your favorite noun here> specifications.

UPDATE 07/30/2008: Richard points out a sequel to his laundry post: Services Not All Like Laundry. And just when we thought we had it all sorted out 🙂