This article will explore how to integrate ShedLock with MongoDB to ensure that your scheduled tasks are executed exactly once, even when multiple instances of the application are running.

What is ShedLock?

ShedLock is a library that ensures that only one instance of a scheduled task is executed in a distributed environment, even when multiple instances of an application are running. ShedLock achieves this by storing lock information in a database, making it accessible to all instances of your application.

Why use ShedLock?

• It prevents the same scheduled task from being executed multiple times across different application instances.
• It supports various backends like MongoDB, MySQL, Redis, and more.
• It provides a simple API for integrating with Spring’s @Scheduled annotation.

2. Setting Up MongoDB for ShedLock

MongoDB is commonly used with ShedLock as a lock provider. Before you can integrate ShedLock with MongoDB, ensure that MongoDB is up and running, and you have the connection details handy.

MongoDB Dependencies

To get started, add the following dependencies in your pom.xml if you are using Maven:

<dependency>
    <groupId>net.javacrumbs.shedlock</groupId>
    <artifactId>shedlock-spring</artifactId>
    <version>5.16.0</version>
</dependency>
<dependency>
    <groupId>net.javacrumbs.shedlock</groupId>
    <artifactId>shedlock-provider-mongo</artifactId>
    <version>5.16.0</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency>

3. Configuration for ShedLock with MongoDB

You need to configure MongoDB as a lock provider for ShedLock. Here’s how you can set it up in a Spring Boot application.

MongoDB Configuration:

import com.mongodb.client.MongoClient;
import net.javacrumbs.shedlock.core.LockProvider;
import net.javacrumbs.shedlock.provider.mongo.MongoLockProvider;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ShedLockConfig {

    @Bean
    public MongoLockProvider lockProvider(MongoClient mongoClient) {
        return new MongoLockProvider(mongoClient.getDatabase("mydatabase"));
    }
}

Here, MongoLockProvider is used to store the lock information in a In this configuration, replace "mydatabase" with the name of your MongoDB database. This will be used by ShedLock to store lock information.

Scheduler Configuration:

Now, let’s define a scheduled task that will use ShedLock to ensure it runs only once across all instances. You can annotate your task with @SchedulerLock to handle locking logic.

import net.javacrumbs.shedlock.core.SchedulerLock;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Service;

@Service
public class MyScheduledTask {

    @Scheduled(cron = "0 */1 * * * ?")  // Runs every minute
    @SchedulerLock(name = "scheduledTask", lockAtLeastFor = "PT30S", lockAtMostFor = "PT1M")
    public void executeTask() {
        // Your task logic here
        System.out.println("Scheduled Task executed!");
    }
}

In this example:

• @Scheduled specifies the cron expression, which runs the task every minute.
• @SchedulerLock ensures that the lock is acquired before running the task. It includes parameters:
  • lockAtLeastFor: Ensures the lock is held for at least 30 seconds, preventing other instances from acquiring it too soon.
  • lockAtMostFor: Specifies the maximum time the lock can be held to avoid situations where a node fails to release the lock.

Enable Scheduling:

Ensure that scheduling is enabled in your Spring Boot application. You can do this by adding @EnableScheduling to your main application class:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableScheduling;

@SpringBootApplication
@EnableScheduling
public class MyApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

4. How ShedLock Works with MongoDB

Once you’ve set everything up:

• Before a scheduled task runs, ShedLock will attempt to acquire a lock in MongoDB.
• If no lock exists, it will create one and store it in the shedlock collection in MongoDB.
• If the lock exists (i.e., another instance has already acquired it), the task will not be executed by the current instance.
• After the task finishes execution, the lock will be released (or kept for the defined lockAtLeastFor duration).

You can query the shedlock collection in MongoDB to see the locks in real-time:

db.shedlock.find()

5. Best Practices and Considerations

• Handle Clock Skew: In a distributed system, ensure that your system clocks are synchronized to avoid issues with lock expiration.
• Database Cleanup: Ensure that old or expired locks are cleaned up periodically.
• Optimizing Lock Duration: Properly define lockAtMostFor and lockAtLeastFor to strike a balance between preventing task re-execution and ensuring locks are released in case of task failures.

6. Conclusion

Integrating ShedLock with MongoDB ensures that your scheduled tasks run safely and only once across multiple instances of your application. With simple setup and configuration, ShedLock can prevent duplicate task executions, making it a valuable tool for distributed Spring Boot applications.

The post Implementing Distributed Task Scheduling in Spring Boot Using ShedLock and MongoDB appeared first on TechDasher.

Why Auto-Increment?

Auto-increment fields are often used as unique identifiers for records in databases. While MongoDB typically uses ObjectId for unique identifiers, there might be cases where you need a sequential, human-readable ID (e.g., order numbers, invoice IDs). This is where custom auto-increment fields come in handy.

Prerequisites

To follow along, you should have a basic understanding of:

• Spring Boot
• MongoDB
• Java

Step 1: Set Up the MongoDB Connection in Java

First, you’ll need to connect to your MongoDB instance from your Java application. You can use the MongoDB Java Driver to handle the connection.

Add the following dependency to your pom.xml file:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-mongodb</artifactId>
    </dependency>
</dependencies>

Step 1: Set Up the counters Collection

MongoDB doesn’t have a built-in mechanism for auto-incrementing fields, but you can use a counters collection to achieve this. First, let’s define a counters document model:

import org.springframework.data.annotation.Id;
import org.springframework.data.mongodb.core.mapping.Document;
import lombok.Data;

@Data
@Document(collection = "database_counters")
public class DatabaseCounter {
    @Id
    private String id;
    private long counter
}

Here, we’re using a DatabaseCounter collection to store our counters. The id field will represent the counter name, and the counterfield will store the current counter number.

Step 2: Create a Counter Generator Service

Next, create a service that will handle the incrementing logic:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.mongodb.core.MongoOperations;
import org.springframework.data.mongodb.core.query.Criteria;
import org.springframework.data.mongodb.core.query.Query;
import org.springframework.data.mongodb.core.query.Update;
import org.springframework.stereotype.Service;
import org.springframework.data.mongodb.core.FindAndModifyOptions;

@Service
public class CounterGeneratorService {

    @Autowired
    private MongoOperations mongoOperations;

    public long generateCounter(String counterName) {
        DatabaseCounter counter = mongoOperations.findAndModify(
                Query.query(Criteria.where("_id").is(counterName)),
                new Update().inc("counter", 1),
                FindAndModifyOptions.options().returnNew(true).upsert(true),
                DatabaseCounter.class);
        return counter != null ? counter.getCounter() : 1;
    }
}

This service defines a generateCounter method that takes the counter name as an argument, increments the counter value, and returns the new value. The findAndModify method is used to atomically update the counter in a thread-safe way.

Step 3: Integrate the Auto-Increment in Your Model

With the counter generator in place, you can now integrate it into your data models. Suppose you have an Employee model where you want to add an auto-incrementing id field:

import org.springframework.data.annotation.Id;
import org.springframework.data.mongodb.core.mapping.Document;
import org.springframework.data.annotation.Transient;
import lombok.Data;

@Data
@Document(collection = "employees")
public class Employee {
    @Transient
    public static final String COUNTER_NAME = "employee_counter";

    @Id
    private long id;
    private String name;
 
}

Step 4: Test the Implementation

To ensure that your auto-incrementing field works as expected, create a simple controller to add new employees:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/employees")
public class EmployeeController {

    @Autowired
    private EmployeeRepository employeeRepository;

    @Autowired
    private CounterGeneratorService counterGeneratorService;

    @PostMapping
    public Employee createEmployee(@RequestBody Employee employee) {  
        employee.setId(counterGeneratorService.
                generateCounter(Employee.COUNTER_NAME));
        return employeeRepository.save(employee);
    }

    @GetMapping("/{id}")
    public Employee getEmployeeById(@PathVariable long id) {
        return employeeRepository.findById(id).orElse(null);
    }
}

Now, whenever you create a new employee, the id field will be auto-incremented.

Conclusion

While MongoDB doesn’t provide built-in support for auto-incrementing fields like relational databases, it’s relatively straightforward to implement this feature using a counters collection and a counter generator service in Spring Boot. This approach gives you the flexibility to create unique identifiers across your collections, even in a distributed environment.

By following the steps outlined in this post, you can efficiently manage auto-incrementing fields in your MongoDB and Spring Boot applications. Happy coding!

The post How to Implement Auto-Increment Fields in MongoDB with Spring Boot appeared first on TechDasher.

In this REST API tutorial, you will learn

• Restful Architecture
• RestFul Principles and Constraints
• RESTful Key Elements
• Restful Methods
• Why Restful

Restful Architecture

An application or architecture considered RESTful or REST-style has the following characteristics

1. State and functionality are divided into distributed resources – This means that every resource should be accessible via the normal HTTP commands of GET, POST, PUT, or DELETE. So if someone wanted to get a file from a server, they should be able to issue the GET request and get the file. If they want to put a file on the server, they should be able to either issue the POST or PUT request. And finally, if they wanted to delete a file from the server, they can issue the DELETE request.

2. The architecture is client/server, stateless, layered, and supports caching

• Client-server is the typical architecture where the server can be the web server hosting the application, and the client can be as simple as the web browser.
• Stateless means that the state of the application is not maintained in REST. For example, if you delete a resource from a server using the DELETE command, you cannot expect that delete information to be passed to the next request.

In order to ensure that the resource is deleted, you would need to issue the GET request. The GET request would be used to first get all the resources on the server. After which one would need to see if the resource was actually deleted.

RESTFul Principles and Constraints

The REST architecture is based on a few characteristics which are elaborated below. Any RESTful web service has to comply with the below characteristics in order for it to be called RESTful. These characteristics are also known as design principles which need to be followed when working with RESTful based services.

• RESTFul Client-Server
• Stateless
• Cache
• Layered System
• Interface/Uniform Contract

1. RESTFul Client-Server

This is the most fundamental requirement of a REST based architecture. It means that the server will have a RESTful web service which would provide the required functionality to the client. The client send’s a request to the web service on the server. The server would either reject the request or comply and provide an adequate response to the client.

2. Stateless

The concept of stateless means that it’s up to the client to ensure that all the required information is provided to the server. This is required so that server can process the response appropriately. The server should not maintain any sort of information between requests from the client. It’s a very simple independent question-answer sequence. The client asks a question, the server answers it appropriately. The client will ask another question. The server will not remember the previous question-answer scenario and will need to answer the new question independently.

3. Cache

The Cache concept is to help with the problem of stateless which was described in the last point. Since each server client request is independent in nature, sometimes the client might ask the server for the same request again. This is even though it had already asked for it in the past. This request will go to the server, and the server will give a response. This increases the traffic across the network. The cache is a concept implemented on the client to store requests which have already been sent to the server. So if the same request is given by the client, instead of going to the server, it would go to the cache and get the required information. This saves the amount of to and fro network traffic from the client to the server.

4. Layered System

The concept of a layered system is that any additional layer such as a middleware layer can be inserted between the client and the actual server hosting the RESTFul web service (The middleware layer is where all the business logic is created. This can be an extra service created with which the client could interact with before it makes a call to the web service.). But the introduction of this layer needs to be transparent so that it does not disturb the interaction between the client and the server.

5. Interface/Uniform Contract

This is the underlying technique of how RESTful web services should work. RESTful basically works on the HTTP web layer and uses the below key verbs to work with resources on the server

• POST – To create a resource on the server
• GET – To retrieve a resource from the server
• PUT – To change the state of a resource or to update it
• DELETE – To remove or delete a resource from the server

RESTful Key Elements

REST Web services have really come a long way since its inception. In 2002, the Web consortium had released the definition of WSDL and SOAP web services. This formed the standard of how web services are implemented.

In 2004, the web consortium also released the definition of an additional standard called RESTful. Over the past couple of years, this standard has become quite popular. And is being used by many of the popular websites around the world which include Facebook and Twitter.

REST is a way to access resources that lie in a particular environment. For example, you could have a server that could be hosting important documents or pictures, or videos. All of these are an example of resources. If a client, say a web browser needs any of these resources, it has to send a request to the server to access these resources. Now REST services define a way on how these resources can be accessed.

The key elements of a RESTful implementation are as follows:

1. Resources – The first key element is the resource itself. Let’s assume that a web application on a server has records of several employees. Let’s assume the URL of the web application is http://demo.techdasher.com. Now in order to access an employee record resource via REST services, one can issue the command http://demo.techdasher.com/employee/101 – This command tells the webserver to please provide the details of the employee whose employee number is 101.
2. Request Verbs – These describe what you want to do with the resource. A browser issues a GET verb to instruct the endpoint it wants to get data. However, there are many other verbs available including things like POST, PUT, and DELETE. So in the case of the example http://demo.techdasher.com/employee/101 , the web browser is actually issuing a GET Verb because it wants to get the details of the employee record.
3. Request Headers – These are additional instructions sent with the request. These might define the type of response required or the authorization details.
4. Request Body – Data is sent with the request. Data is normally sent in the request when a POST request is made to the REST web services. In a POST call, the client actually tells the REST web services that it wants to add a resource to the server. Hence, the request body would have the details of the resource which is required to be added to the server.
5. Response Body – This is the main body of the response. So in our RESTful API example, if we were to query the web server via the request http://demo.techdasher.com/employee/101 , the web server might return an XML document with all the details of the employee in the Response Body.
6. Response Status codes – These codes are the general codes which are returned along with the response from the web server. An example is the code 200 which is normally returned if there is no error when returning a response to the client.

Restful Methods

The below diagram shows mostly all the verbs (POST, GET, PUT, and DELETE) and a REST API example of what they would mean.

Let’s assume that we have a RESTful web service is defined at the location. http://demo.techdasher.com/employee . When the client makes any request to this web service, it can specify any of the normal HTTP verbs of GET, POST, DELETE and PUT. Below is what would happen If the respective verbs were sent by the client.

1. POST – This would be used to create a new employee using the RESTful web service
2. GET – This would be used to get a list of all employees using the RESTful web service
3. PUT – This would be used to update all employees using the RESTful web service
4. DELETE – This would be used to delete all employees using the RESTful services

Let’s take a look from a perspective of just a single record. Let’s say there was an employee record with the employee number of 101.

The following actions would have their respective meanings.

1. POST – This would not be applicable since we are fetching data of employee 101 which is already created.
2. GET – This would be used to get the details of the employee with Employee no as 101 using the RESTful web service
3. PUT – This would be used to update the details of the employee with Employee no as 101 using the RESTful web service
4. DELETE – This is used to delete the details of the employee with Employee no as 101

Why Restful

Restful mostly came into popularity due to the following reasons:

1. Heterogeneous languages and environments – This is one of the fundamental reasons which is the same as we have seen for SOAP as well.

• It enables web applications that are built on various programming languages to communicate with each other
• With the help of Restful services, these web applications can reside on different environments, some could be on Windows, and others could be on Linux.

But in the end, no matter what the environment is, the end result should always be the same that they should be able to talk to each other. Restful web services offer this flexibility to applications built on various programming languages and platforms to talk to each other.

The below picture gives an example of a web application which has a requirement to talk to other applications such Facebook, Twitter, and Google.

Now if a client application had to work with sites such as Facebook, Twitter, etc. they would probably have to know what is the language Facebook, Google and Twitter are built on, and also on what platform they are built on.

Based on this, we can write the interfacing code for our web application, but this could prove to be a nightmare.

Facebook, Twitter, and Google expose their functionality in the form of Restful web services. This allows any client application to call these web services via REST.

2. The event of Devices – Nowadays, everything needs to work on Mobile devices, whether it be the mobile device, the notebooks, or even car systems.

Can you imagine the amount of effort to try and code applications on these devices to talk with normal web applications? Again Restful API’s can make this job simpler because as mentioned in point no 1, you really don’t need to know what is the underlying layer for the device.

3. Finally is the event of the Cloud – Everything is moving to the cloud. Applications are slowly moving to cloud-based systems such as in Azure or Amazon. Azure and Amazon provide a lot of API’s based on the Restful architecture. Hence, applications now need to be developed in such a way that they are made compatible with the Cloud. So since all Cloud-based architectures work on the REST principle, it makes more sense for web services to be programmed on the REST services based architecture to make the best use of Cloud-based services.

The post Restful Web Services appeared first on TechDasher.

SOAP is an XML-based protocol for accessing web services over HTTP. It has some specifications that could be used across all applications.

SOAP was developed as an intermediate language so that applications built on various programming languages could talk easily to each other and avoid the extreme development effort.

In this tutorial, you will learn –

One of the methods used to combat this complexity is to use XML (Extensible Markup Language) as the intermediate language for exchanging data between applications.

Every programming language can understand the XML markup language. Hence, XML was used as the underlying medium for data exchange.

But there are no standard specifications on use of XML across all programming languages for data exchange. That is where SOAP software comes in.

SOAP was designed to work with XML over HTTP and have some sort of specification which could be used across all applications. We will look into further details on the SOAP protocol in the subsequent chapters.

SOAP Building Blocks

The SOAP specification defines something known as a “SOAP message” which is what is sent to the web service and the client application.

The below diagram of SOAP architecture shows the various building blocks of a SOAP Message.

The SOAP message is nothing but a mere XML document which has the below components.

• An Envelope element that identifies the XML document as a SOAP message – This is the containing part of the SOAP message and is used to encapsulate all the details in the SOAP message. This is the root element in the SOAP message.
• A Header element that contains header information – The header element can contain information such as authentication credentials which can be used by the calling application. It can also contain the definition of complex types which could be used in the SOAP message. By default, the SOAP message can contain parameters that could be of simple types such as strings and numbers, but can also be a complex object types.

A simple SOAP service example of a complex type is shown below.

Suppose we wanted to send a structured data type that had a combination of a “Sample Name” and a “Sample Description,” then we would define the complex type as shown below.

The complex type is defined by the element tag <xsd:complexType>. All of the required elements of the structure along with their respective data types are then defined in the complex type collection.

<xsd:complexType>     
 <xsd:sequence>       
 	<xsd:element name="Name" type="string"/>         
  	<xsd:element name="Description"  type="string"/>
  </xsd:sequence>
</xsd:complexType>

A Body element that contains call and response information – This element is what contains the actual data which needs to be sent between the web service and the calling application. Below is an SOAP web service example of the SOAP body which actually works on the complex type defined in the header section. Here is the response of the Name and Description that is sent to the calling application which calls this web service.

<soap:Body>
   <GetInfo>
		<Name>Web Services</Name> 
		<Description>All about web services</Description> 
   </GetInfo>
</soap:Body>

SOAP Message Structure

One thing to note is that SOAP messages are normally auto-generated by the web service when it is called.

Whenever a client application calls a method in the web service, the web service will automatically generate a SOAP message which will have the necessary details of the data which will be sent from the web service to the client application.

As discussed in the previous topic of this SOAP tutorial, a simple SOAP Message has the following elements –

• The Envelope element
• The header element and
• The body element
• The Fault element (Optional)

Let’s look at an example below of a simple SOAP message and see what element actually does.

1. As seen from the above SOAP message, the first part of the SOAP message is the envelope element which is used to encapsulate the entire SOAP message.
2. The next element is the SOAP body which contains the details of the actual message.
3. Our message contains a web service which has the name of “SampleWebService”.
4. The “SampleWebservice” accepts a parameter of the type ‘int’ and has the name of ID.

Now, the above SOAP message will be passed between the web service and the client application.

You can see how useful the above information is to the client application. The SOAP message tells the client application what is the name of the Web service, and also what parameters it expects and also what is the type of each parameter which is taken by the web service.

SOAP Envelope Element

The first bit of the building block is the SOAP Envelope.

The SOAP Envelope is used to encapsulate all of the necessary details of the SOAP messages, which are exchanged between the web service and the client application.

The SOAP envelope element is used to indicate the beginning and end of a SOAP message. This enables the client application which calls the web service to know when the SOAP message ends.

The following points can be noted on the SOAP envelope element.

• Every SOAP message needs to have a root Envelope element. It is absolutely mandatory for SOAP message to have an envelope element.
• Every Envelope element needs to have at least one soap body element.
• If an Envelope element contains a header element, it must contain no more than one, and it must appear as the first child of the Envelope, before the body element.
• The envelope changes when SOAP versions change.
• A v1.1-compliant SOAP processor generates a fault upon receiving a message containing the v1.2 envelope namespace.
• A v1.2-compliant SOAP processor generates a Version Mismatch fault if it receives a message that does not include the v1.2 envelope namespace.

Below is an SOAP API example of version 1.2 of the SOAP envelope element.

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle=" http://www.w3.org/2001/12/soap-encoding">
          <soap:Body>
        <SampleWebService xmlns="http://tempuri.org/">
                  <ID>int</ID>
                </SampleWebService>
          </soap:Body>
</SOAP-ENV:Envelope>

The Fault message

When a request is made to a SOAP web service, the response returned can be of either 2 forms which are a successful response or an error response. When success is generated, the response from the server will always be a SOAP message. But if SOAP faults are generated, they are returned as “HTTP 500” errors.

The SOAP Fault message consists of the following elements.

1. <faultCode>– This is the code that designates the code of the error. The fault code can be either of any below values
   1. SOAP-ENV:VersionMismatch – This is when an invalid namespace for the SOAP Envelope element is encountered.
   2. SOAP-ENV:MustUnderstand – An immediate child element of the Header element, with the mustUnderstand attribute set to “1”, was not understood.
   3. SOAP-ENV:Client – The message was incorrectly formed or contained incorrect information.
   4. SOAP-ENV:Server – There was a problem with the server, so the message could not proceed.
2. <faultString> – This is the text message which gives a detailed description of the error.
3. <faultActor> (Optional)– This is a text string which indicates who caused the fault.
4. <detail>(Optional) – This is the element for application-specific error messages. So the application could have a specific error message for different business logic scenarios.

Example for Fault Message

An example of a fault message is given below. The error is generated if the scenario wherein the client tries to use a method called ID in the class GetInfo.

The below fault message gets generated in the event that the method does not exist in the defined class.

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
      <SOAP-ENV:Body>
         <SOAP-ENV:Fault>
         <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
        <faultstring xsi:type="xsd:string">
            Failed to locate method (GetInfoID) in class (GetInfo)
         </faultstring>
    </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Output:

When you execute the above code, it will show the error like “Failed to locate method (GetInfoID) in class (GetInfo)”

SOAP Communication Model

All communication by SOAP is done via the HTTP protocol. Prior to SOAP, a lot of web services used the standard RPC (Remote Procedure Call) style for communication. This was the simplest type of communication, but it had a lot of limitations.

Now in this SOAP API tutorial, let’s consider the below diagram to see how this communication works. In this example, let’s assume the server hosts a web service which provided 2 methods as

• GetStudent – This would get all Student details
• SetSTudent – This would set the value of the details like student’s course, year, batch, etc. accordingly.

In the normal RPC style communication, the client would just call the methods in its request and send the required parameters to the server, and the server would then send the desired response.

The above communication model has the below serious limitations

1. Not Language Independent – The server hosting the methods would be in a particular programming language and normally the calls to the server would be in that programming language only.
2. Not the standard protocol – When a call is made to the remote procedure, the call is not carried out via the standard protocol. This was an issue since mostly all communication over the web had to be done via the HTTP protocol.
3. Firewalls – Since RPC calls do not go via the normal protocol, separate ports need to be open on the server to allow the client to communicate with the server. Normally all firewalls would block this sort of traffic, and a lot of configuration was generally required to ensure that this sort of communication between the client and the server would work.

To overcome all of the limitations cited above, SOAP would then use the below communication model

1. The client would format the information regarding the procedure call and any arguments into a SOAP message and sends it to the server as part of an HTTP request. This process of encapsulating the data into a SOAP message was known as Marshalling.
2. The server would then unwrap the message sent by the client, see what the client requested for and then send the appropriate response back to the client as a SOAP message. The practice of unwrapping a request sent by the client is known as Demarshalling.

Advantages of SOAP

SOAP is the protocol used for data interchange between applications. Below are some of the reasons as to why SOAP is used.

• When developing SOAP based Web services, you need to have some of language which can be used for web services to talk with client applications. SOAP is the perfect medium which was developed in order to achieve this purpose. This protocol is also recommended by the W3C consortium which is the governing body for all web standards.
• SOAP is a light-weight protocol that is used for data interchange between applications. Note the keyword ‘light.’ Since SOAP programming is based on the XML language, which itself is a light weight data interchange language, hence SOAP as a protocol that also falls in the same category.
• SOAP is designed to be platform independent and is also designed to be operating system independent. So the SOAP protocol can work any programming language based applications on both Windows and Linux platforms.
• It works on the HTTP protocol –SOAP works on the HTTP protocol, which is the default protocol used by all web applications. Hence, there is no sort of customization which is required to run the web services built on the SOAP protocol to work on the World Wide Web.

The post Soap Web Services appeared first on TechDasher.

In this Web Service tutorial, you will learn Web services basics-

• How do Web Services work?
• Why do you need a Web Service?
• Type of Web Service
• Web Services Advantages
• Web Service Architecture
• Web Service Characteristics

How do Web Services work?

The above diagram shows a very simplistic view of how a web service would actually work. The client would invoke a series of web service calls via requests to a server that would host the actual web service.

These requests are made through what is known as remote procedure calls. Remote Procedure Calls(RPC) are calls made to methods that are hosted by the relevant web service.

As an example, Amazon provides a web service that provides prices for products sold online via amazon.com. The front end or presentation layer can be in .Net or Java but either programming language would have the ability to communicate with the web service.

The main component of a web service design is the data that is transferred between the client and the server, and that is XML. XML (Extensible markup language) is a counterpart to HTML and is easy to understand an intermediate language that is understood by many programming languages.

So when applications talk to each other, they actually talk in XML. This provides a common platform for applications developed in various programming languages to talk to each other.

Web services use something known as SOAP (Simple Object Access Protocol) for sending the XML data between applications. The data is sent over normal HTTP. The data which is sent from the web service to the application is called a SOAP message. The SOAP message is nothing but an XML document. Since the document is written in XML, the client application calling the web service can be written in any programming language.

Why do you need a Web Service?

Modern-day business applications use a variety of programming platforms to develop web-based applications. Some applications may be developed in Java, others in .Net, while some others in Angular JS, Node.js, etc.

Most often than not, these heterogeneous applications need some sort of communication to happen between them. Since they are built using different development languages, it becomes really difficult to ensure accurate communication between applications.

Here is where web services come in. Web services provide a common platform that allows multiple applications built on various programming languages to have the ability to communicate with each other.

Type of Web Service

There are mainly two types of web services.

1. SOAP web services.
2. RESTful web services.

In order for a web service to be fully functional, there are certain components that need to be in place. These components need to be present irrespective of whatever development language is used for programming the web service.

Let’s look at these components in more detail.

SOAP (Simple Object Access Protocol)

SOAP is known as a transport-independent messaging protocol. SOAP is based on transferring XML data as SOAP Messages. Each message has something which is known as an XML document. Only the structure of the XML document follows a specific pattern, but not the content. The best part of Web services and SOAP is that it’s all sent via HTTP, which is the standard web protocol.

Here is what a SOAP message consists of

• Each SOAP document needs to have a root element known as the <Envelope> element. The root element is the first element in an XML document.
• The “envelope” is in turn divided into 2 parts. The first is the header, and the next is the body.
• The header contains the routing data which is basically the information that tells the XML document to which client it needs to be sent.
• The body will contain the actual message.

WSDL (Web services description language)

A web service cannot be used if it cannot be found. The client invoking the web service should know where the web service actually resides.

Secondly, the client application needs to know what the web service actually does, so that it can invoke the right web service. This is done with the help of the WSDL, known as the Web services description language. The WSDL file is again an XML-based file that basically tells the client application what the web service does. By using the WSDL document, the client application would be able to understand where the web service is located and how it can be utilized.

Web Service Example

A Web services example of a WSDL file is given below.

<definitions>	
   <message name="SampleRequest">
      <part name="SampleID" type="xsd:string"/>
   </message>
     
   <message name="SampleResponse">
      <part name="SampleName" type="xsd:string"/>
   </message>

   <portType name="Sample_PortType">
      <operation name="Sample">
         <input message="tns:SampleRequest"/>
         <output message="tns:SampleResponse"/>
      </operation>
   </portType>

   <binding name="Sample_Binding" type="tns:Sample_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Sample">
         <soap:operation soapAction="Sample"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Sampleservice"
               use="encoded"/>
         </input>
         
		 <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Sampleservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

The important aspects to note about the above WSDL declaration examples of web services are as follows:

1. <message> – The message parameter in the WSDL definition is used to define the different data elements for each operation performed by the web service. So in the web services examples above, we have 2 messages which can be exchanged between the web service and the client application, one is the “SampleRequest”, and the other is the “SampleResponse” operation. The SampleRequest contains an element called “SampleID” which is of the type string. Similarly, the SampleResponse operation contains an element called “SampleName” which is also a type string.
2. <portType> – This actually describes the operation which can be performed by the web service, which in our case is called Sample. This operation can take 2 messages; one is an input message, and the other is the output message.
3. <binding> – This element contains the protocol which is used. So in our case, we are defining it to use HTTP (http://schemas.xmlsoap.org/soap/http). We also specify other details for the body of the operation, like the namespace and whether the message should be encoded.

Universal Description, Discovery, and Integration (UDDI)

UDDI is a standard for describing, publishing, and discovering the web services that are provided by a particular service provider. It provides a specification that helps in hosting the information on web services.

Now we discussed the previous topic about WSDL and how it contains information on what the Web service actually does. But how can a client application locate a WSDL file to understand the various operations offered by a web service? So UDDI is the answer to this and provides a repository on which WSDL files can be hosted. So the client application will have complete access to the UDDI, which acts as a database containing all the WSDL files.

Just as a telephone directory has the name, address, and telephone number of a particular person, the same way the UDDI registry will have the relevant information for the web service. So that a client application knows, where it can be found.

Web Services Advantages

We already understand why web services came about in the first place, which was to provide a platform that could allow different applications to talk to each other.

But let’s look at the list of web services advantages for why it is important to use web services.

1. Exposing Business Functionality on the network – A web service is a unit of managed code that provides some sort of functionality to client applications or end-users. This functionality can be invoked over the HTTP protocol which means that it can also be invoked over the internet. Nowadays all applications are on the internet which makes the purpose of Web services more useful. That means the web service can be anywhere on the internet and provide the necessary functionality as required.
2. Interoperability amongst applications – Web services allow various applications to talk to each other and share data and services among themselves. All types of applications can talk to each other. So instead of writing specific code which can only be understood by specific applications, you can now write generic code that can be understood by all applications
3. A Standardized Protocol which everybody understands – Web services use standardized industry protocol for communication. All four layers (Service Transport, XML Messaging, Service Description, and Service Discovery layers) use well-defined protocols in the web services protocol stack.
4. Reduction in cost of communication – Web services use SOAP over HTTP protocol, so you can use your existing low-cost internet for implementing web services.

Web Services Architecture

Every framework needs some sort of architecture to make sure the entire framework works as desired, similarly, in web services. The Web Services Architecture consists of three distinct roles as given below :

1. Provider – The provider creates the web service and makes it available to client applications who want to use it.
2. Requestor – A requestor is nothing but the client application that needs to contact a web service. The client application can be a .Net, Java, or any other language-based application which looks for some sort of functionality via a web service.
3. Broker – The broker is nothing but the application which provides access to the UDDI. The UDDI, as discussed in the earlier topic enables the client application to locate the web service.

Web service Characteristics

Web services have the following special behavioral characteristics:

1. They are XML-Based – Web Services uses XML to represent the data at the representation and data transportation layers. Using XML eliminates any networking, operating system, or platform sort of dependency since XML is the common language understood by all.
2. Loosely Coupled – Loosely coupled means that the client and the web service are not bound to each other, which means that even if the web service changes over time, it should not change the way the client calls the web service. Adopting a loosely coupled architecture tends to make software systems more manageable and allows simpler integration between different systems.
3. Synchronous or Asynchronous functionality – Synchronicity refers to the binding of the client to the execution of the service. In synchronous operations, the client will actually wait for the web service to complete an operation. An example of this is probably a scenario wherein a database read and write operation are being performed. If data is read from one database and subsequently written to another, then the operations have to be done in a sequential manner. Asynchronous operations allow a client to invoke a service and then execute other functions in parallel. This is one of the common and probably the most preferred techniques for ensuring that other services are not stopped when a particular operation is being carried out.
4. Ability to support Remote Procedure Calls (RPCs) – Web services enable clients to invoke procedures, functions, and methods on remote objects using an XML-based protocol. Remote procedures expose input and output parameters that a web service must support.
5. Supports Document Exchange – One of the key benefits of XML is its generic way of representing not only data but also complex documents. These documents can be as simple as representing a current address, or they can be as complex as representing an entire book.

The post Web Services appeared first on TechDasher.

The post Android Application – Kolam appeared first on TechDasher.

Here I’ve  integrate google reCAPTCHA in subscription form for collecting subscriber name and email.

Register your website and get API key.

• Click the below link, Sign in using google account 

https://www.google.com/recaptcha/admin

• Click create button (+) on right top of the window. It will redirect to register a new site.

• Enter the following details
  • Label
  • reCAPTCHA type (reCAPTCHA v2 -> “I’m not a robot”)
  • Domains
  • Accept reCAPTCHA Terms of Service
  • Finally click Submit button.

• After registered successfully you will get two API key
  
  • site key: Use this in the HTML code your site serves to users.
    
  • secret key: Use this for communication between your site and reCAPTCHA.

Adding Site Key

Add the following JavaScript library file inside the head tag

<script src='https://www.google.com/recaptcha/api.js'></script>

Add site key inside the form tag

<form> 
<div class="g-recaptcha" data-sitekey="__SITE_KEY__"></div> 
</form>

Server Validation

In server side PHP fetch google reCAPTCHA response token from user request, send a request to the API with secret key and response token for Validation. API sends a JSON response valid or not.

<?PHP 
if ($_POST['g-recaptcha-response']) {
    $recaptcha_secret = "____SECRET_KEY_PASTE_HERE____";
    $request_url = "https://www.google.com/recaptcha/api/siteverify?secret=" . $recaptcha_secret . "&response=" . $_POST['g-recaptcha-response'];
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_URL, $request_url);
    $response = curl_exec($ch);
    curl_close($ch); 
    $response = json_decode($response, true); 
    if ($response["success"] === true) {
        echo '<strong>Captcha Verified!</strong> Success...';
        } else {
        echo '<strong>Captcha mismatched!</strong> Please try again...';
    }
}
?>

Source Code

<?PHP 
if ($_POST['g-recaptcha-response']) {
    $recaptcha_secret = "____SECRET_KEY_PASTE_HERE____";
    $request_url = "https://www.google.com/recaptcha/api/siteverify?secret=" . $recaptcha_secret . "&response=" . $_POST['g-recaptcha-response'];
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_URL, $request_url);
    $response = curl_exec($ch);
    curl_close($ch); 
    $response = json_decode($response, true); 
    $response = json_decode($response, true);
    if ($response["success"] === true) {
        echo '<strong>Captcha Verified!</strong> Success...';
        } else {
        echo '<strong>Captcha mismatched!</strong> Please try again...';
    }
}
?>
<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <script src='https://www.google.com/recaptcha/api.js'></script>
<style>
body{background:#88E7EF; }
form{margin: 0 auto;width: 300px;}
p{ padding:10px 10px 0px 0px; margin:0px; font-size:14px; font-family:arial; }
form input{ padding:5px; margin:0px 0px 10px; width:80%;}
form button{ padding:5px; width:50%; margin:10px 0px;}
</style>
</head>
<body>
    <form method="post">
        <p>Name</p>
        <input type="text" name="name" autocomplete="off" id="name" />
        <p>Email</p>
        <input type="email" name="email" autocomplete="off" id="email" />
        <div class="g-recaptcha" data-sitekey="____SITE_KEY_PASTE_HERE____"></div>
        <button type="submit" id="form-submit" name="form-submit" value="Submit">Submit</button>
    </form>
</body>
</html> 

Output Screen

The post How to integrate Google reCAPTCHA in PHP Form appeared first on TechDasher.

HTML Code

<div id="aOrginCon">
    <label class="aOrType lt"><input type="radio" name="wcs-orgin" value="left-top" />
        <div></div>
    </label>
    <label class="aOrType ct"><input type="radio" name="wcs-orgin" value="center-top" />
        <div></div>
    </label>
    <label class="aOrType rt"><input type="radio" name="wcs-orgin" value="right-top" />
        <div></div>
    </label> 
    <label class="aOrType lc"><input type="radio" name="wcs-orgin" value="left-center" />
        <div></div>
    </label>
    <label class="aOrType cc"><input type="radio" name="wcs-orgin" value="center-center" />
        <div></div>
    </label>
    <label class="aOrType rc"><input type="radio" name="wcs-orgin" value="right-center" />
        <div></div>
    </label> 
    <label class="aOrType lb"><input type="radio" name="wcs-orgin" value="left-bottom" />
        <div></div>
    </label>
    <label class="aOrType cb"><input type="radio" name="wcs-orgin" value="center-bottom" />
        <div></div>
    </label>
    <label class="aOrType rb"><input type="radio" name="wcs-orgin" value="right-bottom" />
        <div></div>
    </label>
</div>

See the Pen HTML CSS Select Position by Raj (@cserajee) on CodePen.

CSS Code

#aOrginCon {
    margin: 50px auto;
    width: 50px;
    height: 50px;
    border: solid 1px #666;
    position: relative;
}

.aOrType {
    position: absolute;
}

.aOrType input {
    display: none;
}

.aOrType input+div {
    border: solid 1px #000;
    margin: 0px;
    padding: 5px;
    cursor: pointer;
}

.aOrType input:checked+div {
    background: #000;
}

.aOrType.lt {
    left: -6px;
    top: -6px;
}

.aOrType.ct {
    left: 19px;
    top: -6px;
}

.aOrType.rt {
    right: -6px;
    top: -6px;
}


.aOrType.lc {
    left: -6px;
    top: 18px;
}

.aOrType.cc {
    left: 19px;
    top: 18px;
}

.aOrType.rc {
    right: -6px;
    top: 18px;
}


.aOrType.lb {
    left: -6px;
    top: 44px;
}

.aOrType.cb {
    left: 19px;
    top: 44px;
}

.aOrType.rb {
    right: -6px;
    top: 44px;
}

The post Corners Position Picker Using HTML CSS appeared first on TechDasher.

click here to download source code

1. Creating Database & Table

Create a database in MySQL. For example, I’ve create database “account” for more details for creating database click here

CREATE Database account

Create a table “account_tb”

CREATE TABLE account_tb(
acc_id INT(20) NOT NULL AUTO_INCREMENT, 
acc_name VARCHAR(155) NOT NULL, 
acc_email  VARCHAR(155) NOT NULL, 
acc_password   VARCHAR(155) NOT NULL,  
created_dt DATETIME NOT NULL, 
status INT(1) NOT NULL DEFAULT "1", 
primary key ( acc_id )) 

Insert default data for login the application

INSERT INTO account_tb (
acc_id, acc_name, acc_email, acc_password, status) VALUES
(1, 'Admin', 'admin@admin.com', '21232f297a57a5a743894a0e4a801fc3', 1)

2. Config and Run

Extract the downloaded zip file in “html directory in wamp” (or) “htdocs directory in Xampp”.

Open app/config.php, change hostname, database name, username and password. run the application.

Click here to download source code

3. Output Screen

The post Simple Sign in and Account Management Module using PHP appeared first on TechDasher.

Install following using RPM

1. WHM  » Software » Install an RPM
2. Select  “ImageMagick“, click  install.
3. Select  “ImageMagick-devel“, click  install.
4. Select  “pcre-devel“, click  install.

Install following using Module Installers

1. WHM  » Software » Module Installers
2. Click PHP Pecl “Manage“
3. Search “imagick“, click Go.
4. Finally  click  install.
5. Restart  apache.
   

The post How to install ImageMagick (imagick) in WHM appeared first on TechDasher.