Calling webservice from PLSQL

Sometimes for software architectural issue we are in need to call webservice API. Suppose, we are using database for all type of backend processing, in that scenario its very impractical to call Webservice using another application or language. We can easily overcome this scenario by calling webservice from plsql code. For this purpose, we can use the below code:


Its a package containing the Stored Procedure to call a soap service form PL Sql:

Package Spec:

create or replace PACKAGE PKG_ABS_ALERT_WS AS 

  /* TODO enter package declarations (types, exceptions, methods etc) here */ 

 PROCEDURE SP_CALL_SMS_SERVICE(

  P_MOBILE_NUM IN VARCHAR2,

  P_MESSAGE IN VARCHAR2

  );

END PKG_ABS_ALERT_WS;

Package Body:

create or replace PACKAGE BODY PKG_ABS_ALERT_WS AS
  PROCEDURE SP_CALL_SMS_SERVICE(
  P_MOBILE_NUM IN VARCHAR2,
  P_MESSAGE IN VARCHAR2
  ) AS

  vg_funciton_fnc VARCHAR2(256);
  vg_ws_address   VARCHAR2(255);
  l_namespace VARCHAR2(255);
  l_return    VARCHAR2(32767);
  ol_req  soap_api.t_request;
  ol_resp soap_api.t_response;

  BEGIN  
    DBMS_OUTPUT.PUT_LINE('P_MOBILE_NUM: '||P_MOBILE_NUM||'  P_MESSAGE:'||P_MESSAGE );   
     vg_funciton_fnc:= 'ns1:sendSMS';
     vg_ws_address:= 'http://:8080/NotificationService/SMSService?wsdl';
     l_namespace  := 'xmlns:ns1="http://sms.notification.dbbl.com/"';

       --we initilize a new request 
           ol_req := soap_api.new_request(vg_funciton_fnc,l_namespace);
        
       -- we started to add parameters
          
              
          soap_api.add_parameter(ol_req,
                                 'channelName','ABS'
                                 );
                             
          soap_api.add_parameter(ol_req,
                                 'mobileNo',P_MOBILE_NUM
                                  );                               
          soap_api.add_parameter(ol_req,
                                 'messageText',P_MESSAGE
                                 );
          soap_api.add_parameter(ol_req,
                                 'refId',
                                 alrt_seq.nextval);
                                 
        
                       
          -- we call the web service
          ol_resp := soap_api.invoke(ol_req, vg_ws_address, vg_funciton_fnc);
          
          -- we get back the results
          l_return := soap_api.get_return_value(ol_resp,
                                           'return', -- result tag name
                                           'xmlns:m="' || --can be change as "xmlns:n1"
                                           vg_ws_address || '"');
                                           
         DBMS_OUTPUT.PUT_LINE('Output: '||l_return);                          
     
  END SP_CALL_SMS_SERVICE;

END PKG_ABS_ALERT_WS;

CORS : Cross-Origin Resource Sharing

The future of the web is cross-domain, not same-origin. As CORS continues the spirit of the open web by bringing API access to all.

The same-origin policy is an important security concept implemented by web browsers to prevent Javascript code from making requests against a different origin (e.g., different domain) than the one from which it was served.

Cross-Origin Resource Sharing (CORS) is a specification that enables truly open access across domain-boundaries. The spec defines a set of headers that allow the browser and server to communicate about which requests are (and are not) allowed. CORS is a technique for relaxing the same-origin policy, allowing Javascript on a web page to consume a REST API served from a different origin.

Simple implementation:

In the simplest scenario, cross-origin communications starts with a client making a GET, POST, or HEAD request against a resource on the server. In this scenario, the content type of a POST request is limited to application/x-www-form-urlencoded, multipart/form-data, or text/plain. The request includes an Origin header that indicates the origin of the client code.

The server will consider the request's Origin and either allow or disallow the request. If the server allows the request, then it will respond with the requested resource and an Access-Control-Allow-Origin header in the response. This header will indicate to the client which client origins will be allowed to access the resource. Assuming that the Access-Control-Allow-Origin header matches the request's Origin, the browser will allow the request.

On the other hand, if Access-Control-Allow-Origin is missing in the response or if it doesn't match the request's Origin, the browser will disallow the request.

For simple CORS requests, the server only needs to add the following header to its response:

Access-Control-Allow-Origin: *

It differs to implement CORS for specific platforms. Suppose for tomcat a minimal CORS configuration as:


<filter>
  <filter-name>CorsFilter</filter-name>
  <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
</filter>
<filter-mapping>
  <filter-name>CorsFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>




N.B: Bear in mind that CORS is not about providing server-side security. The Origin request header is produced by the browser and the server has no direct means to verify it.

Microservices

The industry standard approach for deploying Java EE applications is packing all components into single EAR/WAR archive and deploying the archive on an application server. Although this approach has several advantages, particularly from the ease-of-development perspective, it leads to monolithic architecture, makes applications difficult to maintain, and - particularly important - makes such applications more difficult and sometimes impossible to scale to meet today’s real world demands, especially in PaaS (cloud) environments.

Microservice architecture addresses these shortcomings by decomposing an application into a set of microservices. Each microservice has well-defined functionalities and an interface to communicate with other microservices (such as REST, WSDL, or if needed even RMI). Most often, microservices are stateless.

Instead of packing all microservices into a single archive (EAR/WAR), each microservice is developed and deployed independently of each other. This brings several advantages, such as:

• With microservices, applications are more flexible;
• Every microservice can be developed independently of other microservices, which simplifies lifecycle and change management, makes it easier to use different technologies or upgrade to newer versions;
• Makes it easier to adopt new technologies for parts of an application;
• Makes it much more efficient to scale applications in PaaS[Platform As a Service i.e Cloud] and Docker-like environments.

Microservice approach also has its drawbacks, particularly in the added complexity, related to development and particularly to the deployment. To deploy microservices on stand-alone containers requires several steps, such as configuring the containers, defining the dependencies, deploying the microservices, etc.

Resource Link

REST & SOAP

REpresentational State Transfer (REST).

REST provides you with abilities that are similar (such as making a stateless request and receiving an XML response) to typical web services but with less overhead on the server than standard SOAP calls. This means that if you have a heavy load on the server, throughput can be faster. In addition, because REST behaves like a regular web request except that you are returning XML strings, implementing REST can be easier for non-SOAP-experienced developers.

Of course, all of this does have a cost. REST requires clients to do more work in receiving the XML because they have to parse it themselves. In contrast, SOAP has Web Services Description Language (WSDL) and XML Schema Definition (XSD) for strong typing to generate the client code.

My only gripe with RESTful services is that everyone seems to implement them slightly differently. There seems to be a textbook definition of how to use them; the URI has a hierarchy describing what it is you are looking for. The user can then use that hierarchy while sending over different types of requests (for example, GET, DELETE). Those requests will determine what the code does. For example, you could send over /address/123 Main St with the DELETE request, and it would tell the server to delete the address 123 Main St. Then an XML response would be returned. In this example, the response would probably be some sort of confirmation. However, not many RESTful components seem to use this method of calling.

 The request should be a totally stateless request, and the URL you are sending over does not care about what was previously sent or any session. The URL is sent to the server, a request is made, and an XML response is returned. 

Making webservice client using command

Before executing the command, we need to go to the Java Home location. IN windows command window, java path can be found by the command path. After that we will have to execute the command as below format:

wsimport  <Service URL in WSDL> -d <destination folder location> -keep


Example of command as : 
wsimport http://10.54.170.81:8080/CoreServices/TxnService?wsdl -d d:\test -keep

This command will make the webservice client at specified location.