Web Service and TCP / IP (Java) Sockets + SQL Connections

Question

We are currently in the product life cycle phase when we are thinking about switching to web services. Our system is written in Java, which consists of several client and server applications that talk to each other through TCP Sockets, and also has built-in SQL for searching and updating data (yuk! I know), which uses our own SQL Connection class which then uses java.sql.Connection to connect to the SQL Server database using the Microsoft JDBC driver.

Applications bind to each other using TCP sockets. They request data and send data to each other. Which works great.

Think

So, we are considering converting all data and TCP communications into a web service.

The web service will be developed to work on the secure websites of companies. The idea is that users can connect their customers to the web service from home - when they are not in the company network - or at work when they are.

Client applications will send / receive messages to / from server-side applications using the web service. Client applications will receive and update data in the database using a web service.

Question

I just would like to know what people are going through, to do something with the help of two-way communication (request and push) through a web service (if possible) and what they think about it.

Converting data access to a web service seems straightforward enough - I can anticipate some performance issues when large parts of the data are retrieved in some parts of the system.

I am looking at various reading materials on this subject, as after a while I touched web services (using C # and ASP.NET). You are currently reading "Creating Web Services Using Java ™: Creating the Meaning of XML, SOAP, WSDL, and UDDI." I must admit, I thought that web services were always stateless, but just read that this is not so!

Thanks,

Andez

Answer 1

This helps to think that WebServices is the same as any other web application at the transport level. It uses the HTTP / HTTPS protocols the same way, just to send HTML it sends XML in a predefined format (SOAP). Thus:

• It is request / response oriented
• It can be saved in the same way that a web page can be operational using sessions (provided that you have a web service client that supports the storage of session cookies through requests).
• All requests ultimately boil down to the good old-fashioned servlet endpoints on the server.

Keeping these limitations and features in mind, think about your requirements and how they compare to each other. If you need true two-way communication (push), then web services are not perfect. This is a request / response oriented client / server. To succeed, you will have to interview the client. A possible alternative is that the “server” and “client” act as the “servers” of the web service. This would mean combining a small servlet engine with a client (for example, a berth) so that the “server” can make web service calls to the “client”. Another way is to look at the two-way RMI / IOOP.

Another way would be to maintain a level of communication, as it is today. There is no resourceful benefit for refactoring web services just for the sake of using web services. If they do not bring any benefit, it is simply wasteful. As you already mentioned, the web service comes with a load of extra overhead (verbose protocol, servlet engine, etc.), so you really need to balance the extra costs and development time with a clear advantage. As the saying goes, "if it’s not broken, don’t fix it." As you say, the current solution "works fine", I probably would not change it. It's just me, though.