Difference between JAX-RPC and SOAP

They are completely different protocols, you need to find out the protocol used by the web service you wish to consume and program to that. Web services is really just a concept XML-RPC, SOAP and REST are actual technologies the implement this concept. These implementations are not interoperable (without some translation layer).

All these protocols enable basically the same sort of thing, calling into remote some application over the web. However the details of how they do this differ, they are not just different names for the same protocol.

SOAP supports document-level transfer, whereas xml-rpc is more about values transfer, although it can transfer structures such as structs, lists, etc.

XML-RPC goes over http/https only, where as SOAP goes over ftp, smtp, http, https...etc

XML-RPC doesn't support named parameters, it depends on the position of the parameters where as SOAP supports named parameters and position of the parameters doesn't matter!


example XML-RPC



examples.getStateName


40




Example SOAP:



IBM

SQL queries

Query to find out all the employee records who are having the salary of the third highest salary:

SELECT *

FROM EMPLOYEES A

WHERE 2 = ( SELECT COUNT(*) FROM (SELECT DISTINCT SALARY FROM EMPLOYEES) B WHERE A.SALARY <B.SALARY).


A nice tutorial on Oracle SQL/PLSQL is here.

What is difference between J2EE 1.3 and J2EE 1.4?

J2EE 1.4 is an enhancement version of J2EE 1.3. It is the most complete Web services platform ever.

J2EE 1.4 includes:

Java API for XML-Based RPC (JAX-RPC 1.1)

SOAP with Attachments API for Java (SAAJ),

Web Services for J2EE(JSR 921)

J2EE Management Model(1.0)

J2EE Deployment API(1.1)

Java Management Extensions (JMX),

Java Authorization Contract for Containers(JavaACC)

Java API for XML Registries (JAXR)

Servlet 2.4

JSP 2.0

EJB 2.1

JMS 1.1

J2EE Connector 1.5

The J2EE 1.4 features complete Web services support through the new JAX-RPC 1.1 API, which supports service endpoints based on Servlets and enterprise beans. JAX-RPC 1.1 provides interoperability with Web services based on the WSDL and SOAP protocols.

The J2EE 1.4 platform also supports the Web Services for J2EE specification (JSR 921), which defines deployment requirements for Web services and utilizes the JAX-RPC programming model.

In addition to numerous Web services APIs, J2EE 1.4 platform also features support for the WS-I Basic Profile 1.0. This means that in addition to platform independence and complete Web services support, J2EE 1.4 offers platform Web services interoperability.

The J2EE 1.4 platform also introduces the J2EE Management 1.0 API, which defines the information model for J2EE management, including the standard Management EJB (MEJB). The J2EE Management 1.0 API uses the Java Management Extensions API (JMX).

The J2EE 1.4 platform also introduces the J2EE Deployment 1.1 API, which provides a standard API for deployment of J2EE applications.

The J2EE 1.4 platform includes security enhancements via the introduction of the Java Authorization Contract for Containers (JavaACC). The JavaACC API improves security by standardizing how authentication mechanisms are integrated into J2EE containers.

The J2EE platform now makes it easier to develop web front ends with enhancements to Java Servlet and JavaServer Pages (JSP) technologies. Servlets now support request listeners and enhanced filters. JSP technology has simplified the page and extension development models with the introduction of a simple expression language, tag files, and a simpler tag extension API, among other features. This makes it easier than ever for developers to build JSP-enabled pages, especially those who are familiar with scripting languages.

Other enhancements to the J2EE platform include the J2EE Connector Architecture, which provides incoming resource adapter and Java Message Service (JMS) plug ability. New features in Enterprise JavaBeans (EJB) technology include Web service endpoints, a timer service, and enhancements to EJB QL and message-driven beans.

The J2EE 1.4 platform also includes enhancements to deployment descriptors. They are now defined using XML Schema which can also be used by developers to validate their XML structures.

Note: The above information comes from SUN released notes.

Useful links

Guidelines : Designing Web Services with the J2EE(TM) 1.4 Platform : JAX-RPC, SOAP, and XML Technologies

http://java.sun.com/blueprints/guidelines/designing_webservices/html/

If you are deploying Axis2 in a WAR/EAR under Websphere 6.1 with Web services feature pack or Websphere 7.0, please read the following tech notes:

• T​h​e​ ​A​p​a​c​h​e​ ​A​x​i​s​2​ ​s​e​r​v​l​e​t​ ​i​s​ ​n​o​t​ ​a​c​c​e​s​s​i​b​l​e​ ​a​f​t​e​r​ ​d​e​p​l​o​y​i​n​g​ ​t​h​e​ ​A​p​a​c​h​e​ ​A​x​i​s​2​ ​e​n​g​i​n​e
• D​e​p​l​o​y​i​n​g​ ​a​n​ ​a​p​p​l​i​c​a​t​i​o​n​ ​t​h​a​t​ ​c​o​n​t​a​i​n​s​ ​t​h​e​ ​A​p​a​c​h​e​ ​A​x​i​s​2​ ​r​u​n​t​i​m​e​ ​m​i​g​h​t​ ​c​r​e​a​t​e​ ​a​ ​c​l​a​s​s​ ​c​a​s​t​ ​e​x​c​e​p​t​i​o​n

http://davanum.wordpress.com/2009/03/12/technotes-about-axis2-and-websphere-co-existence/

Understanding Axis2 Deployment Architecture

http://www.developer.com/services/article.php/10928_3557741_1/Understanding-Axis2-Deployment-Architecture.htm

Embedding Apache Axis2 into Existing Applications

http://www.developer.com/open/article.php/10930_3777111_1/Embedding-Apache-Axis2-into-Existing-Applications.htm

Web services authentication

http://www.javaranch.com/journal/200709/web-services-authentication-axis2.html

HTTP Authentication using AXIS2 :

http://amilachinthaka.blogspot.com/2010/01/axis2-authentication.html

Method types defined by W3.org

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Character encoding gotchas - what I needed to do to handle orders from China

A nice article by blogger at : http://wwwilpower.blogspot.in/2011/03/character-encoding-gotchas-what-i.html 

Tutorials on Java

Covers Oauth, exception handling stategies.. etc in a simple language http://tutorials.jenkov.com/oauth2/authorization.html

Good Hints for developers : 

http://rdafbn.blogspot.gr/2012/08/these-are-just-some-tips-and-tricks-i.html

J2ee Interview questions and related links.

J2EE Interview Questions And Answers Set - 10

http://www.placementpapers.net/helpingroot/j2ee/J2EE-Interview-Questions-And-Answer-Set-10

Difference between DataSource vs DriverManager

A DataSource object is the representation of a data source in the Java programming language. In basic terms, a data source is a facility for storing data. It can be as sophisticated as a complex database for a large corporation or as simple as a file with rows and columns. A data source can reside on a remote server, or it can be on a local desktop machine. Applications access a data source using a connection, and a DataSource object can be thought of as a factory for connections to the particular data source that the DataSource instance represents. The DataSource interface provides two methods for establishing a connection with a data source.

Using a DataSource object is the preferred alternative to using the DriverManager for establishing a connection to a data source. They are similar to the extent that the DriverManager class andDataSource interface both have methods for creating a connection, methods for getting and setting a timeout limit for making a connection, and methods for getting and setting a stream for logging.

Their differences are more significant than their similarities, however. Unlike the DriverManager, a DataSource object has properties that identify and describe the data source it represents. Also, aDataSource object works with a Java^TM Naming and Directory Interface^TM (JNDI) naming service and is created, deployed, and managed separately from the applications that use it. A driver vendor will provide a class that is a basic implementation of the DataSource interface as part of its JDBC 2.0 or 3.0 driver product. What a system administrator does to register a DataSource object with a JNDI naming service and what an application does to get a connection to a data source using a DataSource object registered with a JNDI naming service are described later in this chapter.

Being registered with a JNDI naming service gives a DataSource object two major advantages over the DriverManager. First, an application does not need to hardcode driver information, as it does with the DriverManager. A programmer can choose a logical name for the data source and register the logical name with a JNDI naming service. The application uses the logical name, and the JNDI naming service will supply the DataSource object associated with the logical name. The DataSource object can then be used to create a connection to the data source it represents.

The second major advantage is that the DataSource facility allows developers to implement a DataSource class to take advantage of features like connection pooling and distributed transactions. Connection pooling can increase performance dramatically by reusing connections rather than creating a new physical connection each time a connection is requested. The ability to use distributed transactions enables an application to do the heavy duty database work of large enterprises.

Although an application may use either the DriverManager or a DataSource object to get a connection, using a DataSource object offers significant advantages and is the recommended way to establish a connection.

Source and Credits: http://java.sun.com/j2se/1.4.2/docs/guide/jdbc/getstart/datasource.html