We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez
It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.
Related
I have a Client Server Application which is Java based with Spring for the server.
Now I have to replace the Java client with a web client.
I have three different achitectur concepts for implementing the webserver and linking it to the appliation server. But I'm not sure which I should use. I'm not really firm with web applications, but I think this is not a pure decision by the web client.
Can someone please give me some pros and cons for the different concepts or please tell me if my concepts have mistakes.
These are the concepts:
Useage of an embedded web server in my application server.
Pro: I must not implement any session handling between the web server and the application server. The webserver can use the data storages of the application server for requests. Cons: The customer must decide if an application server is allowed to start their own web server. And I'm not sure if it is a good style to mix the web ui logic with the business logic of the application server
Embedd the business logic with the web ui in a war for a stand alone web server.
Pro: Basic Security stuf like https handling will be done by the web server. Maybe more accepteable for the customer regarding the deployment. I must not implement any session handling between the web server and the application server. The webserver can use the data storages of the application server for requests.
Cons: The application server has a lot of memory and cpu useage. The is maybe a problem for the web server.
Embedd the web ui in a web server and link it to the application server via socket connection. Pro: strict separation between ui and business logic. The application server must not be changed, because the socket connection between web server and application server can use the existing socket connection for the fat client. Cons: The handling of user sessions must be handled two time. First the web session and second the session to the application server. Furthermore the web server must set up his own storeages for data and must keep them in sync with the storeages in the application server.
My first thougt was to take the first concept because I have every thing in one application.
But my second thougt to use the third concept because of the strict separation and the benefits of a real web server. But here my problem is the handling of two sessions for each user. Or are there better concepts?
Thank you for giving me input!
Your 3rd approach is better. Keeping application server separate will better serve different clients like Java clients, web clients etc.
It will separate 2 different concerns. If there is a UI related issue , then you can bring down the UI server and fix it. But your other Java clients will work fine. Moreover it will be better from development perspective as well.
I have multiple Java web applications deployed on the same server (Wildfly).
They all should use a single WebSocket implementation to send messages (object, not plain text) to the user.
Edit: WebApp1-3 are the applications with the business logic. The only purpose of WebApp4 is to update a Primefaces panel in the browser based on the messages generated by the other WebApps. Sorry for the missleading illustration.
WebApp1
WebApp2 --> ??? --> WebApp4 (WebSocket-Server) --> JS/Browser
WebApp3
Which is the best way/pattern/implementation to make WebApp4 available to the other applications? (RMI, JMS, WebSocket, WebService, ....?)
My advice, for a general way of exposing services, is to expose REST services since they are simpler than SOAP web service and easily allow interoperability (if in the future a PHP or a RUBY webapp needs to consume your services it's much easier with a REST interface than with one base on RMI or JMS). The content of the REST service may vary, I suggest you to look at XML or JSON as a way of transmitting information over http REST services.
If all webapps are in the same server, you should forward requests from one to another. From the point of view of webapps 1-3, they would not need to be aware of whether their incoming requests were coming from webapp 4 or from outside (to which it appears that they are not connected). Of course, you are free to alter requests before forwarding them - or to drop them altogether, for example if authentication fails.
To do this in tomcat: https://stackoverflow.com/a/8951090/15472
When forwarding requests, the external client is completely unaware of the existence of webapps 1-3 -- as far as the client is concerned, it has sent a request to webapp 4, and it will think it is receiving a response from that same server.
You may need to configure your web server to allow these kinds of calls, but I am unfamiliar with WildFly.
I have my server side plugin, i have to send some value from my server to another server hosted on 2 different locations.
1. Server Side plugin - Hosted on some server i dont know where it is.
2. Web Application - is my application and hosted location i know.
How to exchange data from that server to my application.
We have the privilege to deploy the plugins in some folder but i dont know where it is hosted. But i can use approach to send data.
Please let me know!!!
Regards,
Chandan
There are many solutions to exchange data between different servers:
Shared database
Shared filesystem
exposure of restful web services
exposure of soap web services
rmi
socket connection
shared application that operates as a bridge between the two servers
Each solution has pro and cons. Some needs polling (shared database and filesystem for example), some others not. Some needs just an exposure of a port (web services, socket, web services) other needs additional requirements (for example a shared database needs a database and that database must be visible to both applications).
Generally if you need very fast communication with high traffic load the best solution is a socket (as for client server in databases for example).
Otherwyse choose a solution more human readable and simpler to code.
I have a diagram editor application (client), which is written in javascript. I need to take the model of the diagrams (can be transformed to text), and synchronise it with my GAE Java application which will be my backend. The application will then store this model on cloud, or send it to other clients. (as a result many people work on same diagrams)
This is a totally new field to me, and even though I completed some of the tutorials google provides, and gone through documentation, I am not sure how the connection will be done (tutorials used JSP).
What is the most straight- forward approach into connecting a Java
application (GAE) with a JS client ?
p.s: I have read about ajax, but I dont know if its the right solution for this, or if there is a better one.
What is the most straight- forward approach into connecting a Java
application (GAE) with a JS client ?
Through an API built on HTTP. Your JAVA web app can expose certain endpoints. You can then use Javascript to make http requests, (through AJAX) to your java web api). This is currently the defacto way of communicating from front end with javascript to any backend service.
There will be some trickiness to supporting real time collaboration between clients.
Additionally, there has been increasing support for websockets, which allows you to open a persistant connection between your client and your server, i don't know if java on GAE supports it though...
currently i have an web app build with Strus2 and Spring (IoC, Transactions), and i want to split this into 2 apps; one client which will contain only the web part and one core services that will be accessed via webservices and/or rmi.
I have a dilemma in what technology should i use for "glue", because i like the fact that webservices can be accessed by any clients (php,.net,...,mobile), but as i understand java rmi is faster then webservices.
I was thinking to expose the functionality via webservices and rmi in the same time... but i do not know how to do that.
Also in my current app i have a ajax action that is executed each second from the client to the server, and in this new configuration i think that there will be some performance penalties due to this.
How should i "attack" this situation ?
Thanks,
but as i understand java rmi is faster then webservices.
Why do you think this? Do you have a citation to bolster this claim?
Both RMI and webservices are using TCP/IP; both incur similar network latency. The former uses Java or CORBA serialization to send messages over the wire; the latter uses either HTTP (for REST) or XML over HTTP (for SOAP or RPC-XML).
The relative speed is far more dependent on what those services are doing and how you code them.
I would prefer a web service because simple and open win. You are restricted to RMI/CORBA clients if you use RMI.
Nice. You are running Spring and you already have all you need. Just throw in a few jars (spring webservices and related jars) and you should be good to go.
Please refer :
http://static.springsource.org/spring/docs/2.5.4/reference/ejb.html
http://static.springsource.org/spring/docs/2.5.4/reference/remoting.html