Biradar ShriKant Oracle SOA Blog: March 2018

Thursday, 15 March 2018

Dehydration Store Tables Extension Details

Some tables of SOA dehydration stores and details are available at below Oracle documentation -

http://docs.oracle.com/cd/E23943_01/core.1111/e10108/bpel.htm#r12c1-t12

Also pasting the contents here for ready reference -

Table Name	Table Description
audit_trail	Stores the audit trail for instances. The audit trail viewed in Oracle BPEL Control is created from an XML document. As an instance is processed, each activity writes events to the audit trail as XML.
audit_details	Stores audit details that can be logged through the API. Activities such as an assign activity log the variables as audit details by default. Audit details are separated from the audit_trail table due to their large size. If the size of a detail is larger than the value specified for this property, it is placed in this table. Otherwise, it is placed in the audit_trail table.
cube_instance	Stores process instance metadata (for example, the instance creation date, current state, title, and process identifier)
cube_scope	Stores the scope data for an instance (for example, all variables declared in the BPEL flow and some internal objects that help route logic throughout the flow).
dlv_message	Stores incoming (invocation) and callback messages upon receipt. This table only stores the metadata for a message (for example, current state, process identifier, and receive date).
dlv_subscription	Stores delivery subscriptions for an instance. Whenever an instance expects a message from a partner (for example, the receive or onMessage activity) a subscription is written out for that specific receive activity.
document_ci_ref	Stores cube instance references to data stored in the xml_document table.
document_dlv_msg_ref	Stores references to dlv_message documents stored in the xml_document table.
wftask	Stores tasks created for an instance. The TaskManager process keeps its current state in this table.
work_item	Stores activities created by an instance. All activities in a BPEL flow have a work_item table. This table includes the metadata for the activity (current state, label, and expiration date (used by wait activities)).
xml_document	Stores all large objects in the system (for example, dlv_message documents). This table stores the data as binary large objects (BLOBs). Separating the document storage from the metadata enables the metadata to change frequently without being impacted by the size of the documents.
Headers_properties	Stores headers and properties information.

Asynchronous vs. Synchronous BPEL process

This article explains the difference between an asynchronous and a synchronous process.

I have tried to explain the difference with the help of a simple example below:

Suppose there are two processes SynchronousBPELProcess and AsynchronousBPELProcess. As the name suggest former one is a synchronous and later one is an asynchronous BPEL process. Also there is a third process which we’ll call as Client. The Client invokes the above processes.

Case 1: Client invokes SynchronousBPELProcess.

Client invokes SynchronousBPELProcess.
SynchronousBPELProcess gets instantiated and starts its operations while Client waits for the response from the SynchronousBPELProcess.
SynchronousBPELProcess completes its operations and sends a response back to Client.
Client continues and completes its processing.

Case 2: Client invokes AsynchronousBPELProcess

Client invokes AsynchronousBPELProcess.
AsynchronousBPELProcess gets instantiated and starts its operations while Client also continues to perform its operations.
AsynchronousBPELProcess completes its operations and callback the Client with the response message.

Here we noticed that if a synchronous process is invoked, the operations of this process has to be completed first and only then the client is able to resume its operations while in the case of asynchronous both the process continues to perform their operations.

Fig1: An image showing bpel diagram of an asynchronous and a synchronous process.

What makes the difference?

Synchronous Process:

The synchronous process defines one two way operation port to receive the request and send the response. Using the invoke activity the client invokes the Synchronous BPEL process on this port and waits to receive the response on the same port. As soon as the client receives the response from the BPEL process it continues with its flow. On the BPEL process side, the Synchronous BPEL process gets instantiated on receiving the client request and sends back the reply using the reply activity on the same port on which the Client is waiting.

Asynchronous Process:

In the asynchronous process two one way operations ports are defined to receive the request and send the response. On the client side, the client uses the invoke activity to invoke the asynchronous BPEL process and continues with its flow. It uses the receive activity to receive the response later in the flow. The asynchronous BPEL process receives the request on one of the ports and sends back the reply from another port (callback port). To send the response the asynchronous BPEL process invokes the client on the callback port using the callback activity.

Fig 2: An image showing the wsdl of an asynchronous and a synchronous process.

Fig 3: An image showing a call to asynchronous and synchronous process.

We also find different operation names like initiate, onResult and process in the .bpel file. These are just labels to differentiate between sync and async processes.

* A port is nothing but a method with input and output. So a two way operation port has an input and an output while a one way operation port has only input or output.

What is Service Oriented Architecture?

A Service Oriented Architecture is essentially a collection of services.

These services communicate with each other.
Services are software components that carry out business processes.
Services have well defined interfaces.
A service is the end point of a connection.
Services are the interfaces to the business logic.
Services are connected to each other with loosely coupled connections

Open Group's definition of SOA -

Service-Oriented Architecture (SOA) is an architectural style that supports service orientation.

Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service:

Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports)
Is self-contained
May be composed of other services
Is a “black box” to consumers of the service

Business Process Modeling

BPM is an enterprise integration technology complementing SOA, EAI, ESB. The business process orchestrates complex system interactions and is itself a web service that converses with other such services.

Modeling business processes

A business process describes how the work is done in an organization. It has specific inputs and outputs, uses resources and performs tasks in a specific order. The business processes are repeatable in nature. It specifies the potential execution order of operations from a collection of web services, the data shared between these web services.

Modeling languages used for BPM include Business Process Modeling Notation (BPMN), Business Process Execution Language (BPEL), Unified Modeling Language (UML), Web Services Choreography Description Language (WS-CDL).

Architectural Specializations And Other Roles

Product Architect: The product architect is responsible for the delivery of a software product. He is responsible for the various releases of the product.

Domain Architect: Domain architect focuses on a particular domain e.g. business architecture, data architecture, network architecture.

Solution Architect: The solution architect specifically takes a broad, high-level view of the entire solution.

Enterprise Architect: The enterprise architect is responsible for the cross-system information systems architecture of the whole enterprise, including sales and marketing, client-facing systems, products and services, purchasing and accounts, the supply chain, human resources, etc.

Business Analysts: A business analyst is responsible for capturing and documenting detailed business requirements.

Project Managers: A project manager is responsible for ensuring delivery of the product or system and meeting deadlines.

Design Authorities: A design authority is responsible for the quality of the internal element designs for the system.

Technology Specialists: A technology specialist provides detailed expertise in one specific area. The technology specialist provides depth in the specific area.

Developers: They are responsible for the software code.

Orchestration And Choregraphy

Web services can be used for implementing business processes and collaborations within and across organizations.

Two languages for web service composition available are-
1. Business Process Execution Language (WS-BPEL)
2. Choreography Description Language (WS-CDL)

Orchestration refers to composing web services for business processes. It is used for defining composite services and internal processes. It describes the private process model i.e. describes a specific business process that a web service executes. The orchestration approach assumes a single, central point of control over the entire scope of process execution.

Choreography refers to composing web services for business collaborations. It is used for defining how multiple parties collaborate in peer-to-peer manner as part of some larger business transaction. It describes the public process model i.e. describes the interaction in terms of the public (visible) message exchanges that occur between the web services. The choreography approach assumes execution control is shared, potentially across multiple business process engines or various technologies.

There are two reasons for separating the public and private aspects of the business process.

1. The internal processes and data can be hidden from the clients invoking the web services.

2. The implementation details of the the internal process can be changed without affecting the public business protocol.

Synchronous And Asynchronous Services

A client's interaction with a web service can be synchronous or asynchronous.

Synchronous services - With synchronous services, clients invoke a request on a service and then suspend their processing while they wait for a response. e.g.

Synchronous services are best suited when applications require a more immediate response to a request. Web services that rely on synchronous communication are usually RPC-oriented.

Asynchronous services - With asynchronous services (also dubbed document-style web services), clients initiate a request to a service and then resume their processing without waiting for a response. The service handles the client request and returns a response at some later point, at which time the client retrieves the response and proceeds with its processing.

A document-oriented approach is used for asynchronous class of services. Services which process documents tend to use an asynchronous architecture. A document-oriented Web service receives a document as a service request. The document content determines the processing workflow for the Web service. There can be a number of processing steps required to fulfill the request.

There are two ways to obtain the response -

The client that invoked the service periodically checks the status of the request using the ID that was provided at the time the request was submitted. (This is also known as polling.)

Or, The web service can then respond, at some later time, by making a call back to the client with the response.Therefore, a client of a web service that contains a callback operation is special in that the client itself must provide an endpoint. We call this the callback endpoint and define an endpoint as a unique address identified by a URI to which SOAP request messages can be sent.

Web service callbacks refer to scenarios that involve the web service provider sending a SOAP message back to its clients. The Web Services Description Language (WSDL) specifications define such operations as being of the type “solicit/response.” Clients of web services that support callback operations must have a web service endpoint themselves, which the web service can use for sending callback requests at any point in time, or, in other words, asynchronously.

The first approach is non-intrusive and an independent polling module can be developed that is responsible for getting the results.

The second approach requires an implementation of event-listener.

Best practices suggest that you should support both polling and callbacks when implementing an asynchronous web service. Supporting both approaches will make your service accessible to the widest audience of clients.

10 principles of SOA

Explicit Boundaries - Everything needed by the service to provide its functionality should be passed to it when it's invoked. All access to service should be via its publicly exposed interface. Service invocations should be modeled as stateless. A service invocation isn't a remote procedure call.

Shared Contract and Schema, not Class - Data is exchanged as XML documents validatable against one or more schemas.

Policy-driven - The provider's functionality, syntax, and semantics must fit the consumer's requirements. The technical capabilities and needs must match.

Autonomous - It must be possible to change a service's runtime environment, without affecting its consumers. Services can be changed and deployed , versioned, and managed independently of each other. A service provider can't rely on the ability of its consumers to adapt to a new version of the service quickly; some of them might not be able, or willing , to adapt to a new version of the service interface all.

Wire Formats, not Programming Language APIs - Services are exposed using a specific wire format that has to be supported. A service must be accessible from any platform that supports the exchange of messages adhering to the service interface as long as the interaction conforms to the policy defined for the service.

Document-oriented - To interact with services, data is passed as documents. It should be self-descriptive. It should be explicitly modeled. e.g. a customer ID might be included along with the customer's address information (although the customer ID would be enough). This redundancy is explicitly accepted since it serves to isolate the service interface from the underlying data model of both service consumer and service provider. When a document-oriented pattern is applied, service invocations become meaningful exchanges of business messages instead of context-free RPC calls. When messages are sent in a Distributed Objects or RPC infrastructure, client and server can rely on a set of proxy classes (stubs and skeletons) generated from the interface description document.

Loosely coupled - There are multiple dimensions in which a system can be loosely or tightly coupled. Dimensions include -

Time - When participants are loosely coupled in time, they don't have to be up and running at the same time to communicate. This requires some way of buffering/queuing in between them. When one participant sends a message to the other one, it doesn't rely on an immediate answer to continue processing.

Location - If participants query for the address of other participants they intend to communicate with, the location can change without having to reprogram, reconfigure, or even restart the communication partners. This implies some sort of lookup process using a directory or address that stores service endpoint addresses.

Type - A participant can either rely on all or parts of a document structure to do its work.

Version - Service providers should be implemented to accept as many different versions as possible, and thus be liberal in what they accept, while service consumers should do their best to conform to exact grammars and document types.

Cardinality - There may be a 1:1 relationship between service consumers and service providers especially in cases where a request/response interaction takes place or an explicit message queue is used.

Lookup - A participant that intends to invoke a service can either rely on a name of a service provider to communicate with, or it can do a lookup operation first using a description of a set of capabilities instead. This implies a registry and/or repository that can match the consumer's needs to a provider's capabilities.

Standards-compliant - Standards exist for technical aspects such as data formats, metadata, transport, and transfer protocols, as well as for business-level artifacts such as document types. Reliance should be on standards instead of proprietary APIs.

Vendor-independent - It's unavoidable to decide on specific products, both commercial and free/open source software. None of these decisions must have implications on an architectural level. A participant can be built using any technology that supports the appropriate standards and not be restricted by any vendor roadmap.

Metadata-driven - All of the metadata artifacts in the overall SOA need to be stored in a way that enables them to be discovered, retrieved, and interpreted at both design time and runtime.

What is Web Service?

we will see the introduction of web service tutorial and some jargons of web services.

Web services are used everywhere nowadays. When human interacts with any web page, it involves request and response via HTML. When you interact with the webpage, browser sends a request and then renders response and shows in form of HTML. Similarly, web services also involve request and response but in the form of XML or JSON or plain text. It generally used for other applications or programs to consume and make use of information.

For example:
You are creating a website which shows weather information of important cities in the world. You can actually consume already exposed web services and get the data for the cities. You will get the response in form of XML or JSON, you can parse it and show it on your website.

Let’s go to more formal definition now:

Web service is a way of communication that allows interoperability between different applications on different platforms, for example, a Java based application on Windows can communicate with a .Net based one on Linux. The communication can be done through a set of XML messages over HTTP protocol.Web services are browsers and operating system independent service, which means it can run on any browser without the need of making any changes. Web Services take Web-applications to the Next Level.

The World Wide Web Consortium (W3C) has defined the web services. According to W3C, “Web Services are the message-based design frequently found on the Web and in enterprise software. The Web of Services is based on technologies such as HTTP, XML, SOAP, WSDL, SPARQL, and others.”
Let’s say, you are a Java developer and you can publish your functions on internet or LAN through java web service so any other developer(let’s say .Net developer) can access your function.

You can go through web services interview questions for interview questions on web services.

Why you need to learn web services:

Reuse already developed(old) functionality into new software:

Let’s understand with the very simple example.Let’s say you are developing a finance software for a company on java and you have old .net software which manages salary of employees.So rather than developing new software for employee part, you can use old software and for other parts like infrastructure, you can develop your own functionalities.

Usability :

Web Services allow the business logic of many different systems to be exposed over the Web. This gives your applications the freedom to chose the Web Services that they need. Instead of re-inventing the wheel for each client, you need only include additional application-specific business logic on the client-side. This allows you to develop services and/or client-side code using the languages and tools that you want.

Interoperability :

This is the most important benefit of Web Services. Web Services typically work outside of private networks, offering developers a non-proprietary route to their solutions.Web Services also let developers use their preferred programming languages. In addition, thanks to the use of standards-based communications methods, Web Services are virtually platform-independent.

Loosely Coupled:

Each service exists independently of the other services that make up the application. Individual pieces of the application to be modified without impacting unrelated areas.

Ease of Integration:

Data is isolated between applications creating ’silos’. Web Services act as glue between these and enable easier communications within and across organizations.

Deployability :

Web Services are deployed over standard Internet technologies. This makes it possible to deploy Web Services even over the firewall to servers running on the Internet on the other side of the globe. Also thanks to the use of proven community standards, underlying security (such as SSL) is already built-in.

Some jargons used in Web services:

Simple Object Access Protocol(SOAP):

SOAP is a protocol specification for exchanging structured information in the implementation of Web services in computer networks. It relies on XML as its message format.

Web Service Description Language(WSDL):

WSDL stands for Web Service Description Language. It is an XML file that describes
the technical details of how to implement a web service, more specifically the URI,
port, method names, arguments, and data types. Since WSDL is XML, it is both
human-readable and machine-consumable, which aids in the ability to call and bind to
services dynamically.

Elements of WSDL are:

Description:
It is the root element of a WSDL 2.0 file. It usually contains a set of namespace declarations which are used throughout the WSDL file.

Types:
The WSDL types element describes the data types used by your web service.Data types are usually specified by XML schema.It can be described in any language as long as your web services API supports it.

Binding:
The WSDL binding element describes how your web service is bound to a protocol. In other words, how your web service is accessible. To be accessible, the web service must be reachable using some network protocol. This is called “binding” the web service to the protocol.

Interface:
The WSDL interface element describes the operations supported by your web service.It is similar to methods in programming language.The client can only call one operation per request.

Service:
It describes the endpoint of your web service. In other words, the address where the web service can be reached.

Endpoint:
The endpoint element describes the address of the web service. The endpoint binding attribute describes what binding element this endpoint uses.i.e. protocol with which you will access web service. The address attribute describes the URI at which you can access the service.

Message:
The message element describes the data being exchanged between the Web service providers and consumers.

Sample WSDL file:

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://webservices.javapostsforlearning.arpit.org" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://webservices.javapostsforlearning.arpit.org" xmlns:intf="http://webservices.javapostsforlearning.arpit.org" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<wsdl:types>
<schema elementFormDefault="qualified" targetNamespace="http://webservices.javapostsforlearning.arpit.org" xmlns="http://www.w3.org/2001/XMLSchema">
<element name="sayHelloWorld">
<complexType>
<sequence>
<element name="name" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="sayHelloWorldResponse">
<complexType>
<sequence>
<element name="sayHelloWorldReturn" type="xsd:string"/>
</sequence>
</complexType>
</element>
</schema>
</wsdl:types>
<wsdl:message name="sayHelloWorldRequest">
<wsdl:part element="impl:sayHelloWorld" name="parameters"/>
</wsdl:message>
<wsdl:message name="sayHelloWorldResponse">
<wsdl:part element="impl:sayHelloWorldResponse" name="parameters"/>
</wsdl:message>
<wsdl:portType name="HelloWorld">
<wsdl:operation name="sayHelloWorld">
<wsdl:input message="impl:sayHelloWorldRequest" name="sayHelloWorldRequest"/>
<wsdl:output message="impl:sayHelloWorldResponse" name="sayHelloWorldResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="HelloWorldSoapBinding" type="impl:HelloWorld">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="sayHelloWorld">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="sayHelloWorldRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="sayHelloWorldResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="HelloWorldService">
<wsdl:port binding="impl:HelloWorldSoapBinding" name="HelloWorld">
<wsdlsoap:address location="http://localhost:8080/SimpleSOAPExample/services/HelloWorld"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Universal Description, Discovery and Integration(UDDI):

UDDI stands for Universal Description, Discovery, and Integration.It is a directory service. Web services can register with a UDDI and make themselves available through it for discovery

Web service design approaches:

Contract last or Bottom-up approach:

When using contract last approach, you first write your Java code then you create web service contract(WSDL).There are various kinds of tools which can generate WSDL on the basis of Java code.

Contract first or Top Down Approach:

It is reverse of contract first.Here you first define web service contract.You define all the elements of WSDL first then after that you create your java logic.

Types of web services:

There are mainly two types of web services.

REST
SOAP

You can read about differences and usage of REST and SOAP web services.

That’s all about the web services tutorial.

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of my employer or customer.

All sample code is provided for illustrative purposes only. These examples have not been thoroughly tested under all conditions. The writer therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

All programs contained here in are provided to you "AS IS" without any warranties of any kind. The implied warranties of non-infringement, merchant ability and fitness for a particular purpose are expressly disclaimed.

Thursday, 15 March 2018

1. What are web services?

2. What are features of web services?

3. What are different types of web services?

4. What is SOAP?

5. What are important components for SOAP?

6. What is WSDL?

7. What is UDDI?

8. What is JAX-WS?

9. What are some important annotations for JAX-WS?

10. What do you mean by end point in terms of SOAP?

11. How can you access WSDL for web service?

12. What is wsimport?

13.What is sun-jaxws.xml file?

14. What are Restful web services?

15.What are HTTP methods that can be used with Restful web services?

16. What is JAX-RS?

17. What are some important annotations which you use to create Restful web services?

18. What are ways to test SOAP web services?

19. How to choose between REST and SOAP web services?

20. What are differences between SOAP and REST web services?