SOA Glossary

Service Component Architecture (SCA)
Service Component Architecture (SCA) is a set of specifications that describe a model for building applications using a service-oriented architecture.
1. Services are assembled together to form a composite application that creates a solution that addresses a specific business requirement.
2. Composite applications may contain new services (specifically for the application) and business functions from existing systems and applications (reused in the composite application).


SOA Composite
A SOA composite is an assembly of services, service components, and references designed and deployed together in a single application. Wiring between the service, service component, and reference enables message communication.

1. Services provide the outside world with an entry point to the SOA composite application. The service advertises its capabilities (also known as operations) to external applications with a WSDL (Web Services Description Language) file. The binding of the service describes the protocols that can communicate with the application. Examples include SOAP/HTTP or a JCA adapter.
2. Service components are the building blocks of a SOA composite application. Oracle SOA Suite 11g includes the following components:
   - The BPEL Process component enables design and execution of a business process that integrates a series of business activities and services into an end-to-end process flow.
   - The Business Rules component provides the means of making business decisions based on defined rules.
   - The Human Task component allows you to model a workflow that describes tasks for users or groups to perform as part of an end-to-end business process flow.
   - The Mediator component is used for validation, filtering, transformation, and routing of message data between components.
3. References enable messages to be sent from the SOA composite application to external services in the outside world.

Service Data Object (SDO)

An SDO exposes any data source as a service, which enables retrieval and manipulation of the data in an XML format through service operations. The task of connecting applications to data sources is performed by a data mediator service.
Oracle SOA Suite 11g enables a BPEL Process to access an SDO through an Entity Variable, a special type of BPEL variable associated with a SDO as a service. Oracle ADF-BC components can be deployed simultaneously as Web Service and an SDO.


WSIL (Web Services Inspection Language) Connection
The http://localhost:8001/inspection.wsil URL accesses a Java EE application that dynamically discovers WSDL URL endpoints for Java EE and SOA composite applications deployed to the same run-time server.


Adapters
Adapters provide a service interface that:
• Exposes external application functionality in a form that can be used by SOA composite application components
• Converts request and responses into a form suitable for other (external) systems
• Implements interfaces by using the Java Connector Architecture (JCA) API standards

Oracle Web Service Manager Policy Manager Policy Manager

Oracle WSM  Policy Manager provides the infrastructure for enforcing global security and auditing policies in the service infrastructure. By securing various endpoints and setting and propagating identity, it secures applications. Oracle WSM Policy Manager provides a standard mechanism for signing messages, performing encryption, performing authentication, and providing role-based access control.

The Oracle Metadata Repository

The Oracle SOA Suite 11g runtime environment requires MDS to maintain SOA application configuration and runtime information. It is used to manage deployed services and composite applications.
The MDS can also be used as a central location for storing and referencing shared service artifacts, such as business events, rule sets for Oracle Business Rules, XSLT files for Oracle Mediator, XSD and WSDL documents for Oracle BPEL Process Manager, and other service documents, which can be deployed in a sharable archive format known as the Metadata archive (.mar files).


Business Events and the Event Delivery Network

A business event is a way for one application to notify another application of a significant occurrence to the business. When a business event is published, another application (or service component) can subscribe to it and initiate whatever processing is implied by that event. For example, when product stock levels are updated in an inventory database, an event can serve as a trigger or signal for another process to fulfill orders that have been on hold until products become available.
Business events are typically an asynchronous fire-and-forget (one-way) notification of a business occurrence.
Events are defined by using Event Definition Language (EDL) to specify the name and structure of an event. Definitions for business events are stored in the MDS, and published in the Event Delivery Network (EDN).
The Event Delivery Network is designed to handle asynchronous messaging arising from a business or system event. The EDN is not messaging infrastructure. It provides an application with a declarative publish-subscribe implementation to publish events so that a composite application with a Mediator component can subscribe to events that trigger execution of the composite application.

SOAP-based web service in Java

TimeServer.java

package com.sonal;

import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

/**
 * SEI for a web service that returns the current time as either a string or as
 * the elapsed milliseconds from the Unix epoch, midnight January 1, 1970 GMT.
 * 
 * The annotation @WebService signals that this is the SEI (Service Endpoint
 * Interface). @WebMethod signals that each method is a service operation.
 *
 * The @SOAPBinding annotation impacts the under-the-hood construction of the
 * service contract, the WSDL (Web Services Definition Language) document.
 */
@WebService
@SOAPBinding(style = Style.DOCUMENT)
public interface TimeServer {
 @WebMethod
 String getTimeAsString();

 @WebMethod
 long getTimeAsElapsed();
}

TimeServerImpl.java

package com.sonal;

import java.util.Date;
import javax.jws.WebService;

/**
 * The @WebService property endpointInterface links this SIB (Service
 * Implementation Bean) to the SEI (com.sonal.TimeServer). Note that the method
 * implementations are not annotated as @WebMethods.
 */
@WebService(endpointInterface = "com.sonal.TimeServer")
public class TimeServerImpl implements TimeServer {
 public String getTimeAsString() {
  return new Date().toString();
 }

 public long getTimeAsElapsed() {
  return new Date().getTime();
 }
}

TimeServerPublisher.java

package com.sonal;

import javax.xml.ws.Endpoint;

/**
 * This application publishes the web service whose SIB is
 * com.sonal.TimeServerImpl. For now, the service is published at network address
 * 127.0.0.1., which is localhost, and at port number 9876, as this port is
 * likely available on any desktop machine. The publication path is /ts, an
 * arbitrary name.
 *
 * The Endpoint class has an overloaded publish method. In this two-argument
 * version, the first argument is the publication URL as a string and the second
 * argument is an instance of the service SIB, in this case
 * com.sonal.TimeServerImpl.
 *
 * The application runs indefinitely, awaiting service requests. It needs to be
 * terminated at the command prompt with control-C or the equivalent.
 *
 * Once the application is started, open a browser to the URL
 *
 ** http://127.0.0.1:9876/ts?wsdl
 *
 * to view the service contract, the WSDL document. This is an easy test to
 * determine whether the service has deployed successfully. If the test
 * succeeds, a client then can be executed against the service.
 */

public class TimeServerPublisher {
 public static void main(String[] args) {
  // 1st argument is the publication URL
  // 2nd argument is an SIB instance
  Endpoint.publish("http://127.0.0.1:9876/ts", new TimeServerImpl());
 }
}

WSDL document for the TimeServer service

<?xml version="1.0" encoding="UTF-8"?>
<!-- Published by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.2.4-b01. -->
<!-- Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.2.4-b01. -->
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://sonal.com/" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://sonal.com/" name="TimeServerImplService">
   <types>
      <xsd:schema>
         <xsd:import namespace="http://sonal.com/" schemaLocation="http://127.0.0.1:9876/ts?xsd=1" />
      </xsd:schema>
   </types>
   <message name="getTimeAsString">
      <part name="parameters" element="tns:getTimeAsString" />
   </message>
   <message name="getTimeAsStringResponse">
      <part name="parameters" element="tns:getTimeAsStringResponse" />
   </message>
   <message name="getTimeAsElapsed">
      <part name="parameters" element="tns:getTimeAsElapsed" />
   </message>
   <message name="getTimeAsElapsedResponse">
      <part name="parameters" element="tns:getTimeAsElapsedResponse" />
   </message>
   <portType name="TimeServer">
      <operation name="getTimeAsString">
         <input wsam:Action="http://sonal.com/TimeServer/getTimeAsStringRequest" message="tns:getTimeAsString" />
         <output wsam:Action="http://sonal.com/TimeServer/getTimeAsStringResponse" message="tns:getTimeAsStringResponse" />
      </operation>
      <operation name="getTimeAsElapsed">
         <input wsam:Action="http://sonal.com/TimeServer/getTimeAsElapsedRequest" message="tns:getTimeAsElapsed" />
         <output wsam:Action="http://sonal.com/TimeServer/getTimeAsElapsedResponse" message="tns:getTimeAsElapsedResponse" />
      </operation>
   </portType>
   <binding name="TimeServerImplPortBinding" type="tns:TimeServer">
      <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
      <operation name="getTimeAsString">
         <soap:operation soapAction="" />
         <input>
            <soap:body use="literal" />
         </input>
         <output>
            <soap:body use="literal" />
         </output>
      </operation>
      <operation name="getTimeAsElapsed">
         <soap:operation soapAction="" />
         <input>
            <soap:body use="literal" />
         </input>
         <output>
            <soap:body use="literal" />
         </output>
      </operation>
   </binding>
   <service name="TimeServerImplService">
      <port name="TimeServerImplPort" binding="tns:TimeServerImplPortBinding">
         <soap:address location="http://127.0.0.1:9876/ts" />
      </port>
   </service>
</definitions>

The portType section, near the top, groups the operations that the web service delivers, in this case the operations getTimeAsString and getTimeAsElapsed, which are the two Java methods declared in the SEI and implemented in the SIB. The WSDL portType is like a Java interface in that the portType presents the service operations abstractly but provides no implementation detail.
The other WSDL section of interest is the last, the service section, and in particular the service location, in this case the URL http://localhost:9876/ts. The URL is called the service endpoint and it informs clients about where the service can be accessed.

TimeClient.java

package com.sonal;

import javax.xml.namespace.QName;
import javax.xml.ws.Service;
import java.net.URL;

class TimeClient {
 public static void main(String args[]) throws Exception {
  URL url = new URL("http://localhost:9876/ts?wsdl");
  // Qualified name of the service:
  // 1st arg is the service URI
  // 2nd is the service name published in the WSDL
  QName qname = new QName("http://sonal.com/", "TimeServerImplService");
  // Create, in effect, a factory for the service.
  Service service = Service.create(url, qname);
  // Extract the endpoint interface, the service "port".
  TimeServer port = service.getPort(TimeServer.class);
  System.out.println(port.getTimeAsString());
  System.out.println(port.getTimeAsElapsed());
 }
}

Web services using Eclipse

Apache CXF
1. JAX-WS annotation based web service: http://javahonk.com/jax-ws-web-service-eclipse/
2. Generate client class from wsdl: http://javahonk.com/create-jax-wx-web-service-client/

SOAP Web Service and Web Service Client in Eclipse
http://www.simplecodestuffs.com/create-and-deploy-web-service-and-web-service-client-in-eclipse/

Creating a JAX-WS web service, but no container
http://www.simplecodestuffs.com/jax-ws-web-services-using-eclipse/
http://examples.javacodegeeks.com/enterprise-java/jws/jax-ws-hello-world-example-document-style/
http://www.java2blog.com/2013/03/jaxws-web-service-eclipse-tutorial.html
http://java.globinch.com/enterprise-java/web-services/jax-ws/java-jax-ws-tutorial-develop-web-services-clients-consumers/

Create RESTful web services in java(JAX-RS) using jersey
https://afsinka.wordpress.com/2015/12/27/restful-web-service-example-with-jersey-2-and-tomcat-8/
http://javapapers.com/web-service/restful-services-crud-with-java-jax-rs-jersey/
http://www.java2blog.com/2013/04/create-restful-web-servicesjax-rs-using.html

Web Services Description Language (WSDL)

• Types define the data types used in messages. These types are often drawn from the XML Schema Language.
• Messages describe the part(s) of the input, output, and fault messages exchanged with the calling program.
• Operations provide a name for the action performed on messages.
• PortTypes group message(s) with operation(s).

Those WSDL documents for services deployed outside the WebLogic Server will include the concrete elements of the WSDL, which provide additional information about how and where to access the service:
• The binding describes how a given portType operation will be transmitted, such as HTTP or SOAP (that is, the protocol) and information about where the service is located.
• The port specifies a combination of a network address and a binding, which constitute an endpoint.
• A service groups ports together. A service reveals to a calling program where to access the web service, and through which port. It also describes how the communication messages are defined.

Section 1 includes an import statement and a reference to file po.xsd.
Section 2 describes message requestMessage. The description includes the name of the part, and the name of the element that describes the message structure of that part. Message element PurchaseOrder is fully described in the imported po.xsd document.
Finally, section 3 describes port type execute_ptt, which groups a specific operation (execute) with message requestMessage.

The number and order of messages in the portType definition of a WSDL is important. Because we see only a single message listed in the example above, we know that operation execute is a one-way operation. If we saw a second message like in the example below, we could assume that the operation returned a response upon completion.

UCM: dinDate, dCreateDate, dReleaseDate, and dOutDate

• The dInDate field shows the date and time on the check-in form.  (The Release Date field on the check-in form uses this value).


• The dCreateDate field is the date and time the document is actually checked into the system.


• The dReleaseDate field shows the date and time the document makes it to the Released state (after being converted, indexed, out of workflow, etc.).  This gets modified during a metadata update.


• The dOutDate field shows the date the document will expire (The Expiration Date on the check-in form uses this value).

NOTE: The counters logic was rewritten in 11g and the RevClasses table was part of the solution. Addition information about dDocCreatedDate can be found in the documentation: (Section 5.1.13 Configuring the dDocCreatedDate Attribute)

Generating a Java thread dump

On Windows
https://access.redhat.com/solutions/19170

On Linux
https://access.redhat.com/solutions/18178

UCM: Standard Services

checkSecurity
• Takes none or one parameter. If a parameter is given, it will be the name of a ResultSet. The method checks if the logged in user has the appropriate security as specified in the access level of the service to perform the specified action. It checks the security against a specific security group and account (if accounts are enabled) as specified by a revision. This method is used for validating security for actions on a particular content item, e.g. check in, check out, delete, etc.

createResultSetSQL
• Takes no parameters. Given a dataSource, whereClause (as set in local data), the method looks up the data source in the DataSources table and executes the query with the additional where clause. The method will append additional security clauses to any query referencing the Workflow and Revisions table. The environment value MaxQueryRows determines the cut off point for the number of rows returned. The results of the query are placed in the data with the name as specified by the resultName (as set in local data).

doSubService
• Takes one parameter. Given the name of a sub service, will execute it.

loadDefaultInfo
• Takes no parameters. The method will first execute the loadDefaultInfo filter. It then loads environment information, types, formats and accounts. Used for creating check-in and update pages.

loadMetaOptionsLists
• Takes no parameters. The method will first execute the filter loadMetaOptionsLists. It then proceeds to load all options list as referred to in the DocMetaDefinition table.

loadSharedTable
• Takes two parameters. The first parameter is the name of the table to look up in the server's cached tables. The second is the name the table will be given when added to the data. Use this method instead of executing a query, when the data is already cached in the server. This method is primarily used to make a server-cached table available for a template.

loadSharedTableRow
• Takes two parameters. The first parameter is the name of the table to look up in the server's cached tables. The second parameter is an argument specifying a column in the database and a lookup key into the request data. The value for the key in the request data is used to find the row in the cached table. The values of the row are mapped to the local data using the names of the columns as keys. One usage for this function is to retrieve cached information about a specific user.

mapResultSet
• Takes at least three parameters. The first parameter is the name of a select query; the parameters that follow must appear in pairs. The first member of the pair is the column name; the second member is the key that is used to put the row value into local data. The method will execute the specified query and map the specified columns of the first row of the ResultSet to the local data. Use this method in replacement of a Type 5 action, if the service only requires a part of the first row of a ResultSet to be stored.

refreshCache
• Given a list of subjects, this method will do a refresh on each specified subject.

renameValues
• Takes multiple parameters that must appear in pairs. The pairs are made up of two keys. The first key is used to look up a value in the data. The second key is used to store the found value in the local data. If the value is not found, an exception is thrown and the service will abort with an error message.

setConditionVars
• Given a list of condition variables, this method will set them all to true. These values can only be tested in HTML template pages. They are not put into local data.

setLocalValues
• Takes multiple parameters that must appear in name/value pairs. The name/value pairs are placed into the local data.