All About JMS and Queue Configuration

How to configure JMS on Weblogic Server 12c

JMS Server:

A JMS server acts as a management container for resources which are available in JMS  modules. Some of its responsibilities include the maintenance of  persistence and state of messages and subscribers. A JMS server is  required in order to create a JMS module.

JMS Module:

A JMS module contains JMS resources such as queues/topics. A JMS module is required in order to create a JMS queue.

Subdeployment:

JMS modules are targeted to one or more WLS instances or a cluster.  Resources within a JMS module, such as queues and topics are also targeted to a JMS server or WLS server instances. A subdeployment is a grouping of targets. It is also known as advanced targeting.

Connection Factory:

A connection factory is a resource that enables JMS clients to create connections to JMS destinations.

JMS Queue:

A JMS queue (as opposed to a JMS topic) is a point-to-point destination type. A message is written to a specific queue or received from a specific queue.

The objects used in this example are:

Object Name	Type	JNDI Name
DemoJMSServer	JMS Server
DemoJMSModule	JMS Module
DemoSubDeployment	Subdeployment
DemoConnectionFactory	Connection Factory	jms/DemoConnectionFactory
DemoJMSQueue	JMS Queue	jms/DemoJMSQueue

--------------------------------------------------

   1. JMS Server Configuration Steps:

    1.1. Create a JMS Server: Services > Messaging > JMS Servers

1.2. Select New

1.3  Name: DemoJMSServer

                  Persistent Store: (Click on Create a New Store )- 

Select Type ="JDBC Store" and click next

Provide below details - 

Click next and finish. then select the newly created JDBC Store and click next -

1.4. Target: soa_server1 (or choose an available server)

1.5.  Finish - Click Finish.

The JMS server should now be visible in the list with Health OK.

--------------------------------------------

2. JMS Module Configuration Steps :

2.1.  Services > Messaging > JMS Modules

2.2.  Select New

2.3.  Name: DemoJMSModule  and  Leave the other options to  default

2.4.  Targets: soa_server1 (or choose the same one as the JMS server)

        PressNext

2.5.  Leave “Would you like to add resources to this JMS system

        module” unchecked and  pressFinish.

DemoJMSModule   is created successfully.

--------------------------------------------------

3. Create a SubDeployment : 

A subdeployment is not necessary for the JMS queue to work, but it allows you to easily target subcomponents of the JMS module to a single target or group of targets. We will use the subdeployment in this example to target the following connection factory and JMS queue to the JMS server we created earlier.

3.1. Services > Messaging > JMS Modules

3.2. Select DemoJMSModule

3.3. Click on Subdeployments tab and New

3.4. Subdeployment Name: DemoSubdeployment

3.5. Press Next

3.6. Select Target - Here you can select the target(s) for the subdeployment. You can choose either Servers (i.e. WebLogic managed servers, such as the soa_server1) or JMS Servers such as the JMS Server created earlier. 

As the purpose of our subdeployment in this example is to target a specific JMS server, we will choose the JMS Server option.

Select the DemoJMSServer created earlier

3.7. Press Finish

--------------------------------------

4. Create a Connection Factory

4.1. Services > Messaging > JMS Modules

4.2. Click on DemoJMSModule and press New

4.3. Select Connection Factory and Next

4.4. Name: DemoConnectionFactory

JNDI Name: jms/DemoConnectionFactory

Leave the other values at default

4.5. On the Targets page, select the Advanced Targeting button and select DemoSubdeployment

4.6. Press Finish

The connection factory should be listed on the following page with DemoSubdeployment and DemoJMSServer as the target.

----------------------------------------------

5 Create a JMS Queue

5.1. Services > Messaging > JMS Modules

5.2. Click on  DemoJMSModule and press New

5.3. Select Queue and Next

5.4. Name: DemoJMSQueue

JNDI Name: jms/DemoJMSQueue

Template:None

PressNext

5.5. Subdeployments: DemoSubdeployment

5.6. Finish

The DemoJMSQueue should be listed on the following page with  DemoSubdeployment and DemoJMSServer.

Release Configuration.

The JMS queue is now complete and can be accessed using the JNDI names

jms/DemoConnectionFactory

jms/DemoJMSQueue.

Keep Learning ! Cheers Guys!!

Kavindra Sahu

DataSource, JNDI Creation DB & FTP on Weblogic Server

******************* DataSource Creation on Weblogic Server **************************


1. Login into WebLogic Console. The default URL is http://<HOSTNAME>:<PORT>/console


2. Click Data Sources under services,

Click New and select Generic Data Source

3. Input a Name, Scope as Global, JNDI Name for your code to lookup, and Database Type (Oracle, My SQL, etc.,)

4.  Accept the default and click Next

5.

6.

7. Click on test configuration- Then click on next

8. Then click on next, select target, then click on finish.

This way data source has been created.

****************    JNDI Configurations for Database ***************** 



1. JNDI Configurations for DB

----------------------------------------------
1.a. Log into  Console -  http://<HOSTNAME>:<PORT>/console
1.b Lock and Edit

Create  outbound Connection poll in DBAdapter
----------------------------------------------

1.c    Goto Deployments --> DBAdapter --> Configuration --> Outbound Connection Pools ---> New



1.d   Select javax.resource.cci.ConnectionFactory --> Next -> Privde JNDI Name below --> Finish



     JNDI Name: eis/DB/TestDB


1.e  Expand javax.resource.cci.ConnectionFactory--> Click on eis/DB/TESTDB


Enter below details  in Outbound Connection Properties


     PlatformClass: org.eclipse.persistence.platform.database.Oracle10Platform --> Enter to Save



     XADataSourceName: jdbc/TestDB--> Enter to Save

1.f Save and Activate changes


Again take lock & Edit then -
1.g   Goto Deployments --> Select DBAdapter and update DBAdapter.

After successful update , it will show like below.

JNDI           - eis/DB/TESTDB
DataSource -  jdbc/TestDB

JNDI is confifured successfully.
-----------------------------------------

======================================================================

****************    JNDI Configurations for FTP ***************** 

2. JNDI Configurations for FTP

----------------------------------------------

2.a. Log into  Weblogic Console -  http://<HOSTNAME>:<PORT>/console

2.b Lock and Edit

Create FTP outboundpool connection.

 -------------------------------

2.c    Goto Deployments --> FTPAdapter --> Configuration --> Outbound Connection Pools ---> New

Select javax.resource.cci.ConnectionFactory --> Next -> Privde JNDI Name below --> Finish

     JNDI: eis/sftp/testftp

2.d Click on eis/sftp/testftp

Enter below details  in Outbound Connection Properties

     username: username Enter to Save

     password:Password Enter to Save

     Host: ftp.abcftp.com

     UseSftp : true Enter to Save

2.e Save and Activate changes 

First Take lock & Edit then 

2.f   Goto Deployments --> and select FTP Adapter and update FTP Adapter.

Release Configuration.

Keep Learning ! Cheers Guys!!

Kavindra Sahu

Web Services

Web services are web based applications.It is a collection of standards or protocols for exchanging information between two devices or application.
The Web Service is a standard software system used for communication between two devices (client and server) over the network. Web services provide a common platform for various applications written in different languages to communicate with each other over the network.

Web services are the types of internet software that uses standardized messaging protocol over the distributed environment. It integrates the web-based application using the REST, SOAP, WSDL, and UDDI over the network.


There are mainly two types of web services.
1. SOAP web services.
2. RESTful web services.

These are some of the important advantages of web services:

Interoperability: With the help of web services, an application can communicate with other application developed in any language.
Reusability: We can expose the web service so that other applications can use it.
Modularity: With the help of web service, we can create a service for a specific task such as tax calculation.

A Standard protocol for every application program: Web services use standard protocol so that all the client applications written in different languages can understand it. This Standard protocol helps in achieving cross-platform.

Cheaper cost for communication: Web services uses SOAP over HTTP so that anybody can use existing internet for using web services.


Following is a list of main features of web services:

It is available over the Internet or private (intranet) networks.
It uses a standardized XML messaging system.
It is not tied to any one operating system or programming language.
It is self-describing via a common XML grammar.
It is discoverable via a simple find mechanism.



------------------------------------------------- SOAP Web Services -----------------------------------------------


SOAP stands for Simple Object Access Protocol. It is a XML-based protocol for accessing web services.
SOAP is a W3C recommendation for communication between two applications.
SOAP is XML based protocol. It is platform independent and language independent. By using SOAP, you will be able to interact with other programming language applications.


Advantages of Soap Web Services:
WS Security: SOAP defines its own security known as WS Security.
Language and Platform independent: SOAP web services can be written in any programming language and executed in any platform.


Disadvantages of Soap Web Services
Slow: SOAP uses XML format that must be parsed to be read. It defines many standards that must be followed while developing the SOAP applications. So it is slow and consumes more bandwidth and resource.
WSDL dependent: SOAP uses WSDL and doesn't have any other mechanism to discover the service.


------------------------------------------------ RESTful Web Services ---------------------------------------------

RESTful Web Services:

• REST stands for REpresentational State Transfer.
• REST is an architectural style not a protocol.

It is developed by Roy Thomas Fielding who also developed HTTP. The main goal of RESTful web services is to make web services more effective. RESTful web services try to define services using the different concepts that are already present in HTTP. REST is an architectural approach, not a protocol.
It does not define the standard message exchange format. We can build REST services with both XML and JSON. JSON is more popular format with REST. The key abstraction is a resource in REST. A resource can be anything. It can be accessed through a Uniform Resource Identifier (URI).
For example:
The resource has representations like XML, HTML, and JSON. The current state is captured by representational resource. When we request a resource, we provide the representation of the resource.
The important methods of HTTP are:
GET: It reads a resource.
PUT: It updates an existing resource.
POST: It creates a new resource.
DELETE: It deletes the resource.

POST /users: It creates a user.

GET /users/{id}: It retrieve the detail of one user.

GET /users: It retrieve the detail of all users.

DELETE /users: It delete all users.

DELETE /users/{id}: It delete a user.

GET /users/{id}/posts/post_id: It retrieve the detail of a specific post.

POST / users/{id}/ posts: It creates a post for a user.

GET /users/{id}/post: Retrieve all posts for a user


HTTP also defines the following standard status code:

404: RESOURCE NOT FOUND
200: SUCCESS
201: CREATED
401: UNAUTHORIZED
500: SERVER ERROR


RESTful Service Constraints :
There must be a service producer and service consumer.
The service is stateless.
The service result must be cacheable.
The interface is uniform and exposing resources.
The service should assume a layered architecture.

Advantages of RESTful web services:
RESTful web services are platform-independent.
It can be written in any programming language and can be executed on any platform.
It provides different data format like JSON, text, HTML, and XML.
It is fast in comparison to SOAP because there is no strict specification like SOAP.
These are reusable.
These are language neutral.



----------------------------------------------------------------------------------------------------------------

There are two popular formats for request and response XML and JSON.

XML Format: XML is the popular form as request and response in web services. Consider the following XML code:

<getDetail>
<id>EmployeeDetail</id>
</getDetail>

The code shows that user has requested to access the EmployeeDetail.



The other data exchange format is JSON. JSON is supported by wide variety of platform.
[ 
    "employee": 
   { 
        "id": 20097420
        "name":       "Kavindra",   
        "salary":      15000,   
   } 
]


To make a web service platform-independent, we make the request and response platform-independent.


Now a question arises, how does the Application know the format of Request and Response?

The answer to this question is "Service Definition." Every web service offers a service definition. Service definition specifies the following:

* Request/ Response format: Defines the request format made by consumer and response format made by web service.
* Request Structure: Defines the structure of the request made by the application.
* Response Structure: Defines the structure of response returned by the web service.
* Endpoint: Defines where the services are available.



Key Terminology of Web Services :
* Request and Response
* Message Exchange Format: XML and JSON
* Service Provider or Server
* Service Consumer or Client
* Service Definition
* Transport: HTTP and MQ


Request and Response: Request is the input to a web service, and the response is the output from a web service.

Message Exchange Format: It is the format of the request and response. There are two popular message exchange formats: XML and JSON.

Service Provider or Server: Service provider is one which hosts the web service.

Service Consumer or Client: Service consumer is one who is using the web service.

Service Definition: Service definition is the contract between the service provider and service consumer. Service definition defines the format of request and response, request structure, response structure, and endpoint.

Transport: Transport defines how a service is called. There is two popular way of calling a service: HTTP and Message Queue (MQ). By tying the URL of service, we can call the service over the internet. MQ communicates over the queue.



Keep Learning ! Cheers Guys!!

Kavindra Sahu

Web Services Components

Web Services Components

There are two components of web services:

* Web Service Description Language (WSDL)
* Universal Description Discovery and Integration (UDDI)

Web Service Description Language (WSDL):
WSDL acronym for Web Service Description Language. WSDL is an XML based interface description language. It is used for describing the functionality offered by a web service. Sometimes it is also known as the WSDL file. The extension of the WSDL file is .wsdl. It provides the machine-readable description of how the service can be called, what parameter it expects, and what data structure it returns.

Service   -- It is a set of system functions.
Port   --    It is an endpoint that defines a combination of binding and network addresses.
Binding   -- It specifies the interface and defines the SOAP binding style. It also defines the operations.
PortType  -- An abstract set of services supported by one or more endpoints.
Operation -- Abstract detail of an action supported by the service. It defines the SOAP actions and the way of encoding the message.
Message   -- An abstract, typed definition of data to communicate. W3C has removed the message in WSDL 2.0, in which XML Schema types for defining bodies of inputs, outputs, and faults are referred directly.
Types   -- It is a container for data type definition. The XML Schema language (XSD) is used for this purpose.




Universal Description, Discovery, and Integration (UDDI):

UDDI acronym for Universal Description, Discovery, and Integration. It is an XML-based registry for businesses word wide to list themselves on the internet.

A service provider registers its business with the UDDI registry.
A service provider registers each service separately with the UDDI registry.
The consumer looks up the business and service in the UDDI registry.
The consumer binds the service with the service provider and uses the service.


The UDDI business registry system has three directories are as follows:
White Pages: The white pages contain basic information such as company name, address, phone number, and other business identifiers such as tax numbers.

Yellow Pages: The yellow pages contain detailed business data organized by relevant business classification. The version of the yellow page classifies business according to the newer NAICS (North American Industry Classification System).

Green Pages: The green pages contain information about the company's crucial business process, such as operating platform, supported programs, and other high-level business protocols.

Difference between SOAP and RESTful Web Services

Difference between SOAP and RESTful Web Services 

SOAP Protocol	RESTful Web Services
SOAP is a protocol.	REST is an architectural approach.
SOAP acronym for Simple Object Access Protocol.	REST acronym for REpresentational State Transfer.
In SOAP, the data exchange format is always XML.	There is no strict data exchange format. We can use JSON, XML, etc.
XML is the most popular data exchange format in SOAP web services.	JSON is the most popular data exchange format in RESTful web services.
SOAP uses Web Service Definition Language (WSDL).	REST does not have any standard definition language.
SOAP does not pose any restrictions on transport. We can use either HTTP or MQ.	RESTful services use the most popular HTTP protocol.
SOAP web services are typical to implement.	RESTful services are easier to implement than SOAP.
SOAP web services use the JAX-WS API.	RESTful web services use the JAX-RS API.
SOAP protocol defines too many standards.	RESTful services do not emphasis on too many standards.
SOAP cannot use RESTful services because it is a protocol.	RESTful service can use SOAP web services because it is an architectural approach that can use any protocol like HTTP and SOAP.
SOAP reads cannot be cached.	REST reads can be cached.

 

Keep Learning ! Cheers Guys!!

Kavindra Sahu

DataSource , Transactions , Compensation Activity

                                            XA AND NON XA DATA SOURCE

An XA transaction is a "global transaction" that may span multiple resources.

A non-XA transaction always involves just one resource.

An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction.

Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions). 

Example of non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database.

XA gets involved when you want to work with multiple resources. 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like WebSphere or WebLogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources.

Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are committed across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.

The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.

In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction.

------------------------------------------------------------------------------------------------

                                                         Transactions

* Services can be of two types:

1. Non-Transactional Services

2. Transactional Service

* Non-Transactional services are the services that does not modify data.

  E.g. File Adapter, FTP Adapter

* Transactional service can be defined as any service that performs DML operations, where each operation are subject to ACID(Atomicity, Consistency, Isolation, Durability) principles.

* Transactional services are implemented as a java web services or adapter services which are invoked from SOA using BPEL or Mediator

* Transactional boundaries depend on context, configurations and environment of the services that are implemented and invoked.

* Transactional semantics differs for the services that are invoked synchronously compared with services invoked asynchronously.

 Transaction Boundaries

* Transaction boundaries depends on the type of interaction

              1. Starts when a service is invoked(operation begins) and Ends when a service ends(operation completes)

              2. Propagates across synchronous services which can:

* Joining an existing transaction (By default it will Join in Global Tx)

* End the existing transaction(Can be achieved by Dehydration)

Propagate the transaction to another synchronous services

1.     Terminate when invoking an asynchronous service, which:

        Ends or suspends the existing transaction

        Starts new independent transaction

     Transactional Service Implementation

* Services with transactional behavior can be implemented using

   1. Web services(i.e. JWS, Spring Web services, ADF-BC) that execute SQL transactions

   2. Database Adapter

   3. Service Data Objects

BPEL Transaction

BPEL processes are:

* Transient, when they don’t have any dehydration points i.e. execute start to end without dehydration

* Durable, when one or more dehydration points occur during execution

BPEL Transactions are:

* Begin at the start of the process. The first activity(Receive / Pick) marks the start of the bpel process.

* Ends at the end of the transient(Synchronous) process, when it send the reply to its client, or when the dehydration point occurs in a durable(asynchronous) process.

* If the a fault occurs before these end conditions, the transaction is rolled back to the start and unhandled faults are returned to caller.

BPEL Transactional Behavior

JTA (Java Transaction API) is used with the request and when:

* If exists, the local transaction joins the global JTA transaction when transaction property is set.

* If does not exist then new transaction is started.

A transaction is completed when it encounters a break point activity(causing dehydration) or reaching end of flow.

BPEL Transaction and Delivery properties

Transaction boundaries between different BPEL services are controlled by 2 properties i.e. Delivery Property and Transaction property

Delivery property can have 3 values. 

1)- async.persit  

2)- async.cache 

3)- sync

Transaction property can have 2 values. 

1)- Required 

2)- Requires New

<component name=”TransactionBpel” version=”2.0″>

<implementation.bpel src=”BPELASynchCall.bpel”/>

<property name=”bpel.config.transaction” type=”xs:string” many=”false”>required</property>

<property name=”bpel.config.oneWayDeliveryPolicy” type=”xs:string” many=”false”>async.persist</property>

</component>

case1: If BPEL Process is Async or one-way process then, Delivery property is used

async.persit: Delivery messages are persisted in the database in table dlv_message. With this setting, reliability is obtained with some performance impact on the database.

When the client initiates a process instance, an invocation request is placed in an internal queue. Inside Oracle BPEL Server, a message-driven bean (MDB), WorkerBean, monitors the queue for invocation requests. When a message is dequeued, Oracle BPEL Server allocates a thread to process the message.

async.cache : Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, this setting should be considered.

Message are not dehydrated into dlv_message table. Rest all is same as async.persist.

sync : Directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance.

case2: If BPEL Process is Sync process then, transaction boundary between client and bpel process is controlled by “Transaction” property

Required : This makes the BPEL process execute as part of the calling transaction. If no calling transaction exists, it will create a new one.

RequiresNew: This is the default value and makes the BPEL process execute as a separate transaction. Any existing transaction will be suspended.

Adapters

Transactional adapters that supports Two Phase commit:

DB Adapter

JMS Adapter

AQ Adapter

Oracle Apps Adapter

Non transactional adapters

File Adapter

FTP Adapter

--------------------------------------------------------------------------------------------------------

                                                          Compensation Activity

Problem: Transactions do not work with asynchronous services.

* ACID principles and XA transactions cannot be applied across asynchronous invocations

* Transactions can be managed for synchronous services, provided all invocations are synchronous.

Solution: Compensation handling, which enables an asynchronous invocation to execute:

* An operation that performs a transaction

* An operation that perform reverse of previously completed transaction.

Keep Learning ! Cheers Guys!!

Kavindra Sahu

Oracle SOA Suite 12c version-(12.2.4) Installation

Oracle SOA Suite 12c version. (12.2.4) Installation

In this post, I will show you step by step installation of Oracle SOA 12c on window.

Step 1: Download Oracle SOA 12c installer. Keep both jar files in one common folder

Step 2: JDK 1.8.211 Installation is required for Oracle SOA Suite 12c version. (12.2.4).Download jdk and install.

Step 3:  Set environment Variable.

Step 3: Go to java bin folder where you have installed latest JDK.Oracle SOA 12c is an executable jar file so we need to run it from command prompt.

Run below command in command prompt.

Java –jar Oracle_SOA_12c_exceutable_Jar_File_Location

Here you need to provide first executable jar file path.

Open the cmd with Admin access and run the below command.

C:\Program Files\Java\jdk1.8.0_221\bin>java -jar D:\Softwares\V983385-01_1of2\fmw_12.2.1.4.0_soa_quickstart.jar

You see window of quick start installation, click on next.

You need to specify Oracle home directory. 

In this step installer check system certification and Java Version. Both prerequisite should meet.

Click Next.

You see installation summary page, you can save the response file if you want to.

Click on “Install” to start the actual installation process.

You see the installation progress.

Step 4

Click on next and select all Features on next screen 

 select No

Keep Learning ! Cheers Guys!!

Kavindra Sahu