I have questions about how web services can be used with legacy system.
Let�s say I have a server serving stock data. The server is just POJO, it isn�t web module, doesn�t run on any J2EE container and client will request for data using my proprietary API which run over TCP/IP. My question is that what is the best practice or widely used pattern for exposing my stock service through web services.
I�m not a web service expert so I think the easiest patter may be using web services as an adapter for my API. I�ll use jax-rpc to create web services StockWS.war and deploy it on a web server running on the same machine with my stock server. The web services will, in turn, internally use my proprietary API to request data.
I can see 2 problems in the above approach. 1. The need of web server. Administrator needs to start 2 processes; stock server and the web server containing StockWS.war. It would be great if I can get everything work in one process. Is there any framework or API that my stock server can internally use to intercept soap request over HTTP so that I don�t need a web server and everything is encapsulated in one process?
2. Performance. There will be my API sit between web services runtime layer and my stock server which may cause performance issue. If I can find a framework I�ve mentioned in problem1 then I can get rid of the API layer.
Please ignore my grammar mistakes. Any suggestion is welcome, and if you have experiences integrating web services with your legacy system, feel free to share it here.
Well, if you have the luxury, just do it and find out whether it is in fact a problem.
If it is a problem there are steps that you can take. If you don't need that proprietary API over TCP/IP you can refactor the existing application to a pure Web service using something like Axis or XFire. Axis at least can be then deployed to a servlet container like Tomcat or Jetty (BTW: Both Tomcat and Jetty can be run as an embedded servlet container - I'd say that Jetty is more "light-weight"). In that case you can run in a single process. However if you want to expose this to the outside world you would still want to have a separate industrial strength web server for security and possibly load balancing reasons, which would then delegate all the approved requests to Tomcat/Jetty.
Then the only remaining problem is the performance-loss you may have due to the marshalling/unmarshalling of XML - but that may be negligible in your case.
Thanks for your reply Peer. I haven't known about "embedded servlet container" before. I've googled around, it seems like running web services in web server is the more recommended way than using the embedded engine so I will go with the first approach.
Performance shouldn't be an issue, or if it becomes so you can try to scale up to running the WS layer on a separate machine,
We're serving stock information in near realtime to hundreds (sometimes thousands) of simultaneous connections using a SOAP stack talking to an EJB stack. We do have more than one machine for that of course (the SOAP stack uses something like 40 web servers, the EJB stack at least about a dozen application servers). But while the scale is quite different, the problem domain and solution are comparable.
Of course calling the EJB stack directly is faster by a maybe a few tenths of seconds, but we gain platform independence and increased security (the SOAP layer implements its own security layer on top of the EJB layer which is already secure). And network latency means that that extra delay is well within the bounds of what you can expect the difference in response times to be for an internet connection.