Web Services

• Web services are application components
• Web services communicate using open protocols
• Web services are self-contained and self-describing
• Web services can be discovered using UDDI
• Web services can be used by other applications
• HTTP and XML is the basis for Web services

·         Web services can be published, found, and used on the Web.

·         Web services use XML to code and to decode data, and SOAP to transport it (using open protocols)

·          

WSDL

• WSDL stands for Web Services Description Language
• WSDL is an XML-based language for describing Web services.
• WSDL is a W3C recommendation

SOAP?

• SOAP stands for Simple Object Access Protocol
• SOAP is a communication protocol
• SOAP is for communication between applications
• SOAP is a format for sending messages
• SOAP communicates via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP is a W3C recommendation

Why SOAP?

It is important for application development to allow Internet communication between programs.

Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic.

A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this.

SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

Syntax Rules

Here are some important syntax rules:

• A SOAP message MUST be encoded using XML
• A SOAP message MUST use the SOAP Envelope namespace
• A SOAP message MUST use the SOAP Encoding namespace
• A SOAP message must NOT contain a DTD reference
• A SOAP message must NOT contain XML Processing Instructions

UDDI

• UDDI stands for Universal Description, Discovery and Integration
• UDDI is a directory service where companies can search for Web services.
• UDDI is described in WSDL
• UDDI communicates via SOAP

1. What is differences between RESTful web services and SOAP web services ?
Ans:Though both RESTful web service and SOAP web service can operate cross platform they are architecturally different to each other, here is some of differences between REST and SOAP:
1) REST is more simple and easy to use than SOAP. REST language is based on use of nouns and verbs (better readability)
2) REST uses HTTP protocol for producing or consuming web services while SOAP uses XML.

• The SOAP WS is transport protocol neutral. Supports multiple protocols like HTTP(S),  Messaging, TCP, UDP SMTP, etc.
• The REST is transport protocol specific. Supports only HTTP or HTTPS protocols.

3) REST is lightweight as compared to SOAP and preferred choice in mobile devices and PDA's. REST does not need XML parsing, no message header (to and from), hence less bandwidth
4) REST supports different format like text, JSON and XML while SOAP only support XML.

• The SOAP WS permits only XML data format.You define operations, which tunnels through the POST. The focus is on accessing the named operations and exposing the application logic as a service.
• The REST permits multiple data formats like XML, JSON data, text, HTML, etc. Any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE Web operations. The focus is on accessing the named resources and exposing the data as a service. REST has AJAX support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create, Read, Update, and Delete) operations.

         GET - represent()
         POST - acceptRepresention()
         PUT - storeRepresention()
         DELETE - removeRepresention() 
5) SOAP based reads cannot be cached. REST based reads can be cached. Performs and scales better. 
6) Different error handling:          
    REST: requires HTTP error handling          
    SOAP: can have user defined error
7) REST only supports synchronous  message because of its reliance of HTTP and HTTPS
8) SOAP WS supports both SSL security and WS-security, which adds some enterprise security features like maintaining security right up to the point where it is needed, maintaining identities through intermediaries and not just point to point SSL only, securing different parts of the message with different security algorithms, etc. 
The REST supports only point-to-point SSL security. The SSL encrypts the whole message, whether all of it is sensitive or not.
9) The SOAP has comprehensive support for both ACID based  transaction management  for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources. 
The REST supports transactions, but it  is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.
10) The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries. REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.

http://www.javatechinfo.com/2013/06/web-services-interview-questions-and.html

c3p0 connection pool

c3p0 is very tunable, and offers a somewhat bewildering array of configuration parameters. 

initialPoolSize C3P0 default: 3

minPoolSize Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 1

maxPoolSize Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 100

idleTestPeriod Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 0

If this is a number greater than 0, c3p0 will test all idle, pooled but unchecked-out connections, every this number of seconds.

timeout Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 0

The seconds a Connection can remain pooled but unused before being discarded. Zero means idle connections never expire.

maxStatements Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 0

The size of c3p0's PreparedStatement cache. Zero means statement caching is turned off.

unreturnedConnectionTimeout=3600 default(0) I’ve set this to 1 hour. If a Connection is used for longer than an hour, then C3P0 will assume it’s been orphaned and will reclaim the Connection to the pool – closing it in the process.

propertyCycle Must be set in c3p0.properties, C3P0 default: 300

Maximum time in seconds before user configuration constraints are enforced. c3p0 enforces configuration constraints continually, and ignores this parameter. It is included for JDBC3 completeness.

acquireIncrement Must be set in hibernate.cfg.xml (or hibernate.properties), Hibernate default: 1

Determines how many connections at a time c3p0 will try to acquire when the pool is exhausted.

testConnectionOnCheckout Must be set in c3p0.properties, C3P0 default: false

Don't use it, this feature is very expensive. If set to true, an operation will be performed at every connection checkout to verify that the connection is valid. A better choice is to verify connections periodically using c3p0.idleConnectionTestPeriod.

autoCommitOnClose Must be set in c3p0.properties, C3P0 default: false

The JDBC spec is unfortunately silent on what should happen to unresolved, pending transactions on Connection close. C3P0's default policy is to rollback any uncommitted, pending work. (I think this is absolutely, undeniably the right policy, but there is no consensus among JDBC driver vendors.) Setting autoCommitOnClose to true causes uncommitted pending work to be committed, rather than rolled back on Connection close. [Note: Since the spec is absurdly unclear on this question, application authors who wish to avoid bugs and inconsistent behavior should ensure that all transactions are explicitly either committed or rolled-back before close is called.]

forceIgnoreUnresolvedTransactions Must be set in c3p0.properties, C3P0 default: false

Strongly disrecommended. Setting this to true may lead to subtle and bizarre bugs. This is a terrible setting, leave it alone unless absolutely necessary. It is here to work around broken databases / JDBC drivers that do not properly support transactions, but that allow Connections' autoCommit flags to be set to false regardless. If you are using a database that supports transactions "partially" (this is oxymoronic, as the whole point of transactions is to perform operations reliably and completely, but nevertheless, such databases exist), if you feel comfortable ignoring the fact that Connections with autoCommit == false may be in the middle of transactions and may hold locks and other resources, you may turn off c3p0's wise default behavior, which is to protect itself, as well as the usability and consistency of the database, by either rolling back (default) or committing (see c3p0.autoCommitOnClose above) unresolved transactions. This should only be set to true when you are sure you are using a database that allows Connections' autoCommit flag to go to false, but that it offers no other meaningful support of transactions. Otherwise setting this to true is just a bad idea.

numHelperThreads Must be set in c3p0.properties, C3P0 default: 3

c3p0 is very asynchronous. Slow JDBC operations are generally performed by helper threads that don't hold contended locks. Spreading these operations over multiple threads can significantly improve performance by allowing multiple operations to be performed simultaneously.

factoryClassLocation Must be set in c3p0.properties, C3P0 default: null



Go to start of metadata

Configuration for c3p0 connection pool

<bean id="notificationDataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">

    <property name="driverClass"><value>#{notification.db.driver}</value></property>

    <property name="jdbcUrl"><value>#{notification.db.url}</value></property>

    <property name="user"><value>#{notification.db.username}</value></property>

    <property name="password"><value>#{encrypted.notification.db.password}</value></property>

    <property name="initialPoolSize"><value>#{notification.c3po.initial.poolsize}</value></property>

    <property name="minPoolSize"><value>#{notification.c3po.min.poolsize}</value></property>

    <property name="maxPoolSize"><value>#{notification.c3po.max.poolsize}</value></property>

    <property name="acquireIncrement"><value>#{notification.c3po.acquireIncrement}</value></property>

    <property name="maxStatementsPerConnection"><value>#{c3po.maxStatementsPerConnection}</value></property>

    <property name="numHelperThreads"><value>#{notification.c3po.numHelperThreads}</value></property>

    <property name="automaticTestTable"><value>c3p0_test_table</value></property>

    <property name="maxConnectionAge"><value>#{c3po.maxConnectionAge}</value></property>

    <property name="maxIdleTime"><value>#{c3po.maxIdleTime}</value></property>

    <property name="maxIdleTimeExcessConnections"><value>#{c3po.maxIdleTimeExcessConnections}</value></property>

    <property name="idleConnectionTestPeriod"><value>#{c3po.idleConnectionTestPeriod}</value></property>

    <property name="testConnectionOnCheckin"><value>#{c3po.testConnectionOnCheckin}</value></property>

    <property name="testConnectionOnCheckout"><value>#{c3po.testConnectionOnCheckout}</value></property>

    <property name="acquireRetryAttempts"><value>#{c3po.acquireRetryAttempts}</value></property>

    <property name="acquireRetryDelay"><value>#{c3po.acquireRetryDelay}</value></property>

    <property name="unreturnedConnectionTimeout"><value>#{c3po.unreturned.connection.timeout}</value></property>

    <property name="DebugUnreturnedConnectionStackTraces"><value>#{c3po.debug.unreturned.connection.stacktrace}</value></property>

</bean>

Go to start of metadata

Useful in c3Po connection pool debugging

debugUnreturnedConnectionStackTraces

Default: false
If true, and if unreturnedConnectionTimeout is set to a positive value, then the pool will capture the stack trace (via an Exception)