Monday, November 6, 2017

WebService TitBit-8

Subresources and Runtime Resource Resolution

You can use a resource class to process only a part of the URI request. A root resource can then implement subresources that can process the remainder of the URI path.
A resource class method that is annotated with @Path is either a subresource method or a subresource locator:
  • A subresource method is used to handle requests on a subresource of the corresponding resource.
  • A subresource locator is used to locate subresources of the corresponding resource.

Subresource Methods

subresource method handles an HTTP request directly. The method must be annotated with a request method designator such as @GET or @POST, in addition to @Path. The method is invoked for request URIs that match a URI template created by concatenating the URI template of the resource class with the URI template of the method.
The following code snippet shows how a subresource method can be used to extract the last name of an employee when the employee’s email address is provided:
@Path("/employeeinfo")
Public class EmployeeInfo {

    public employeeinfo() {}

    @GET
    @Path("/employees/{firstname}.{lastname}@{domain}.com")
    @Produces("text/xml")
    public String getEmployeeLastName(@PathParam("lastname") String lastName) {
       ...
    }

}
The getEmployeeLastName method returns doe for the following GET request:
GET /employeeinfo/employees/john.doe@example.com

Subresource Locators

subresource locator returns an object that will handle an HTTP request. The method must not be annotated with a request method designator. You must declare a subresource locator within a subresource class, and only subresource locators are used for runtime resource resolution.
The following code snippet shows a subresource locator:
// Root resource class
@Path("/employeeinfo")
public class EmployeeInfo {

    // Subresource locator: obtains the subresource Employee
    // from the path /employeeinfo/employees/{empid}
    @Path("/employees/{empid}")
    public Employee getEmployee(@PathParam("empid") String id) {
        // Find the Employee based on the id path parameter
        Employee emp = ...;
        ...
        return emp;
    }
}

// Subresource class
public class Employee {

    // Subresource method: returns the employee's last name
    @GET
    @Path("/lastname")
    public String getEmployeeLastName() {
        ...
        return lastName
    }
}
In this code snippet, the getEmployee method is the subresource locator that provides the Employee object, which services requests for lastname.

If your HTTP request is GET /employeeinfo/employees/as209/, the getEmployee method returns an Employee object whose id is as209. At runtime, JAX-RS sends a GET /employeeinfo/employees/as209/lastname request to the getEmployeeLastName method . The getEmployeeLastName method retrieves and returns the last name of the employee whose id is as209.

Friday, October 27, 2017

WebService TitBit-7


Status

This text is the proposed revised replacement text for the 2nd last paragraph in part 1, section 2.6 which reads as follows:
If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored). Additional SOAP header blocks MAY be inserted at any point in the SOAP message, and such inserted SOAP header blocks MAY be indistinguishable from one or more just removed (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)
The text builds on the proposed wording for resolving issue 137 by Noah and Henrik and discussion at the W3C f2f meeting in Cannes.
The idea here is to cast relaying as a feature - it builds on section 2.

2.7 Relaying SOAP Messages

As mentioned earlier in this section, SOAP provides a distributed processing model that assumes that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more features and expressed as SOAP extensions or as part of the underlying protocol binding (see section 5 and 6). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.

SOAP Intermediaries

The semantics of one or more SOAP blocks in a SOAP message, or the SOAP message exchange pattern used MAY request that the SOAP message be forwarded to another SOAP node on behalf of the initiator of the inbound SOAP message. In this case, the processing SOAP node acts in the role of a SOAP intermediary.
SOAP defines two different types of intermediaries: forwarding intermediaries and active intermediaries. These two type of intermediary are described below.

Forwarding Intermediaries

Forwarding intermediaries process the message according to the SOAP processing model defined in section 2.6. SOAP header blocks targeted at the SOAP intermediary MUST be removed from the SOAP message prior to forwarding (such SOAP blocks are removed regardless of whether they were processed or ignored).
It is the responsibility of the feature defining the SOAP forwarding to describe the required semantics including rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted blocks. Inserted SOAP header blocks may be indistinguishable from one or more of the header blocks removed above (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)

Active Intermediaries

In addition to the processing performed by forwarding intermediaries, active intermediaries undertake additional processing that may modify the outbound message in ways not described in the inbound message. I.e. they may undertake processing not described by header blocks in the incoming message. The potential set of services provided by an active intermediary includes, but is not limited to: logging, security, content modification and tracing.
The collective effect of such additional processing may affect the correct processing of features expressed in the inbound message by downstream SOAP nodes. For example, as part of generating an outbound message, an active intermediary may have removed and encryped some or all of the blocks found in the inbound message.
It is STRONGLY RECOMMENDED that features provided by active intermediaries be described in a manner that allows such modifications to be detected by the affected SOAP nodes. For example, an active intermediary may describe the processing performed by inserting header blocks into the outbound SOAP message that inform downstream SOAP nodes acting in roles whose correct operation depends on receiving such notification. The semantics of such inserted headers should also call for either the same or other headers to be (re)inserted at subsequent intermediaries as necessary to ensure that the message can be safely processed by nodes yet further downstream. For example, if a message with headers removed for encryption passes through a second intermediary (without the original headers being decrypted and reconstructed), then indication that the encryption has occurred must be retained in the second relayed message.

Thursday, October 26, 2017

WebService TitBit-6

Components of EJB-JAR.xml


 < ejb-jar >
     < assembly-descriptor >
         < method-permission >
             < description > The employee and temp-employee roles may access any
                method of the EmployeeService bean  < / description >
             < role-name > employee < / role-name >
             < role-name > temp-employee < / role-name >
             < method >
                 < ejb-name > EmployeeService < / ejb-name >
                 < method-name > * < / method-name >
             < / method >
         < / method-permission >
         < method-permission >
             < description > The employee role may access the findByPrimaryKey,
                getEmployeeInfo, and the updateEmployeeInfo(String) method of
                the AardvarkPayroll bean  < / description >
             < role-name > employee < / role-name >
             < method >
                 < ejb-name > AardvarkPayroll < / ejb-name >
                 < method-name > findByPrimaryKey < / method-name >
             < / method >
             < method >
                 < ejb-name > AardvarkPayroll < / ejb-name >
                 < method-name > getEmployeeInfo < / method-name >
             < / method >
             < method >
                 < ejb-name > AardvarkPayroll < / ejb-name >
                 < method-name > updateEmployeeInfo < / method-name >
                 < method-params >
                     < method-param > java.lang.String < / method-param >
                 < / method-params >
             < / method >
         < / method-permission >
         < method-permission >
             < description > The admin role may access any method of the
                EmployeeServiceAdmin bean  < / description >
             < role-name > admin < / role-name >
             < method >
                 < ejb-name > EmployeeServiceAdmin < / ejb-name >
                 < method-name > * < / method-name >
             < / method >
         < / method-permission >
         < method-permission >
             < description > Any authenticated user may access any method of the
                EmployeeServiceHelp bean < / description >
             < unchecked/  >
             < method >
                 < ejb-name > EmployeeServiceHelp < / ejb-name >
                 < method-name > * < / method-name >
             < / method >
         < / method-permission >
         < exclude-list >
             < description > No fireTheCTO methods of the EmployeeFiring bean may be
                used in this deployment < / description >
             < method >
                 < ejb-name > EmployeeFiring < / ejb-name >
                 < method-name > fireTheCTO < / method-name >
             < / method >
         < / exclude-list >
     < / assembly-descriptor >
 < / ejb-jar > 

Saturday, October 21, 2017

WebService TitBit - 5

Best Explanation about wsgen / wsimport



Courtsy >>

https://coderanch.com/t/625764/certification/difference-wsimport-wsgen-command

1. Can we say that wsgen and wsimport command generates same classes (same JAX-WS artifacts)? 
2. Can we say that wsgen and wsimport command is used to generate both server and client side code ? 
3. can wsgen command be used to generate a WSDL file ? 

Correct me if I am wrong. 
wsgen and wsimport generates JAX-WS artifacts from SBI and WSDL respectively. 
If those JAX-WS artifacts do not exist, when the service is published using Endpoint.publish or web service container (Tomcat), those artifacts are dynamically generated. 
If those artifacts exist (generated by wsgen), the Endpoint.publish does not generate those artifacts. 

1. Yes. wsgen and wsimport generate request and response wrapper bean classes and the JAXB classes (XXX.class and XXXResponse.class). 

However, wsgen generates the JAXB classes and put them in a jaxws folder. But wsimport does not put those classes in any folder instead in the current directory. 
2. The JAX-WS artifacts generated can be used by both server and client side. 
3. I think wsgen can be used to generate WSDL. Here is an example at http://www.mkyong.com/webservices/jax-ws/jax-ws-wsgen-tool-example/

Thursday, October 19, 2017

WebService TitBits - 4

A service groups a set of related ports together:
< wsdl : definitions .... >
    < wsdl :  service name="nmtoken " > *
        < wsdl : port .... / > * 
    < / wsdl : service >
< / wsdl : definitions >
The name attribute provides a unique name among all services defined within in the enclosing WSDL document.
Ports within a service have the following relationship:
  • None of the ports communicate with each other (e.g. the output of one port is not the input of another).
  • If a service has several ports that share a port type, but employ different bindings or addresses, the ports are alternatives. Each port provides semantically equivalent behavior (within the transport and message format limitations imposed by each binding). This allows a consumer of a WSDL document to choose particular port(s) to communicate with based on some criteria (protocol, distance, etc.).
  • By examining it's ports, we can determine a service's port types. This allows a consumer of a WSDL document to determine if it wishes to communicate to a particular service based whether or not it supports several port types. This is useful if there is some implied relationship between the operations of the port types, and that the entire set of port types must be present in order to accomplish a particular task.

WebService TitBit - 3

Difference between Source.Mode.Message and Source.Mode.Payload .

Both are enum vars representing mode of  response .
Message

Operates directly with the entire message. For example, if a SOAP binding is used, then the entire SOAP envelope is accessed.

Payload

Operates on the payload of a message only. For example, if a SOAP binding is used, then the SOAP body is accessed.

For more details  >>

https://docs.oracle.com/cd/E17904_01/web.1111/e13734/provider.htm#WSADV559

which encoding style are acceptable by ws-basic profile  1.1 ?
 RPC-literal and Document literal 

for more details  >>

https://www.ibm.com/support/knowledgecenter/SSFTBX_8.5.7/com.ibm.wbpm.wid.integ.doc/access/topics/rwsdlstyle.html

# Types of XML signature  :

1) Eneveloping  Sign


.....

Signature will contain the object 

2) Eneveloped Sign 

.......
Signature will be eneveloped inside object 


3) Detached  

Signature will be  outside the document containing or referring data URL

Data to be signed is accessible through the Ref URI .

for more info check out >> https://www.ibm.com/support/knowledgecenter/en/SS3JSW_5.2.0/com.ibm.help.svcs_adpts_m_z.doc/XML_Dig_Sig_svc.html

Wednesday, October 11, 2017

WebService TitBit - 2

SAAJ.jar API that was available  externally before  ... has been integrated with JDK 1.6 . 
However higher releases are still available  outside .

Difference between Endpoint and EndpointReference 
Endpoint is the URL where your service can be accessed.
EndPointReference is a reference to itself.
check out here >> https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.0.0/com.ibm.websphere.nd.doc/info/ae/ae/twbs_wsa_eprs_jaxws.html
EPR is mostly used  locally by a WebService.

Why WS-Addressing is needed ?

It is a transport neutral way to address WebService  For more info  check out  on web .

How to generate Faults  in SOAP ?
There are two types of SOAP faults  .
1) modeled - Exception are mapped to WSDL:fault tag
2) Unmodeled - Run time exceptions SOAPFaultException and RuntimeException messages are returned

Tuesday, October 3, 2017

WebService TitBit- 1

Difference between SOAP 1.1 and 1.2 

SOAP 1.1 technically allows XML elements
to occur after the SOAP body. In SOAP 1.2, by contrast, the SOAP body is the last XML
element in the SOAP envelope.

The 1.1 version binds SOAP
to HTTP transport, whereas the 1.2 version also supports SOAP over SMTP.

Thursday, September 14, 2017

Common terms in Web services

JAXB - API for XML Binding
JAXP - API for XML Processing
JAXM - API for XML Messaging
JAXR - API for XML Registries
JAX RPC - API for XML Remote Procedure Call
JAX TX - API for XML Transactions
JAAS- Java Authentication and Authorization Services 
JAF - Java Beans Activation Framework
JNDI- Java Native and Directory Interface
UDDI - Universal Description and Discovery Integration
WSDL - Web Service Description Language 
SOAP - Simple Object Access  Protocol
JSON - Java Script Object Notation
SAAJ- SOAP with Attachments for Java.


JAX WS ( API ) ( Metro = implementation ) ( requires WSDL ) 
JAX RS ( API ) ( Jersey = implementation ) 

Web service concept was developed to  remove short comings of  EJB .
An EJB can be also be deployed as  Web Service .

Since Java 1.6, there's a built-in HTTP server included with the JDK.
The HttpServer provides a simple high-level Http server API, which can be used to build embedded HTTP servers.
Endpoint.publish  accepts requests from a webservice  at a port at the same HTTP server .
for more into check out 

Thursday, August 24, 2017

Long Data types in DB

The use of LONG values is subject to these restrictions:
  • A table can contain only one LONG column.
  • You cannot create an object type with a LONG attribute.
  • LONG columns cannot appear in WHERE clauses or in integrity constraints (except that they can appear in NULL and NOT NULL constraints).
  • LONG columns cannot be indexed.
  • LONG data cannot be specified in regular expressions.
  • A stored function cannot return a LONG value.
  • You can declare a variable or argument of a PL/SQL program unit using the LONG data type. However, you cannot then call the program unit from SQL.
  • Within a single SQL statement, all LONG columns, updated tables, and locked tables must be located on the same database.
  • LONG and LONG RAW columns cannot be used in distributed SQL statements and cannot be replicated.
  • If a table has both LONG and LOB columns, then you cannot bind more than 4000 bytes of data to both the LONG and LOB columns in the same SQL statement. However, you can bind more than 4000 bytes of data to either the LONG or the LOB column.
In addition, LONG columns cannot appear in these parts of SQL statements:
  • GROUP BY clauses, ORDER BY clauses, or CONNECT BY clauses or with the DISTINCT operator in SELECT statements
  • The UNIQUE operator of a SELECT statement
  • The column list of a CREATE CLUSTER statement
  • The CLUSTER clause of a CREATE MATERIALIZED VIEW statement
  • SQL built-in functions, expressions, or conditions
  • SELECT lists of queries containing GROUP BY clauses
  • SELECT lists of subqueries or queries combined by the UNION, INTERSECT, or MINUS set operators
  • SELECT lists of CREATE TABLE ... AS SELECT statements
  • ALTER TABLE ... MOVE statements
  • SELECT lists in subqueries in INSERT statements



Tuesday, August 22, 2017

Difference between trustStore and keyStore

TrustManager determines whether remote connection should be trusted or not

·         trustStore is for client  to validate the  authenticity of  web server .
·         It holds public key provided by the web server . 
·         trustStore is used by TrustManager in Java
·         -Djavax.net.ssl.trustStore to specify path for trustStore in Java.




keystore decides which  authentication credentials should be sent to the remote host for authentication during SSL handshake

·         It hold the private key used by Web server to encrypt the messages send to Clients.
·         keyStore is used by keyManager in java.
·         -Djavax.net.ssl.keyStore is path to specify keystore in Java



Tuesday, July 11, 2017

how to download source of app hosted on Google cloud

Fire below cmd 

appcfg.sh -A janews-151415 -V 1 download_app "C:/Temp"