So the case is the following:
I have an application that communicates with a JAX-RPC web service (Hosted in an .ear package on a JBoss server). We had a requirement of moving all the operations in this web service to a new one with a new name, keeping in mind that we should keep our backward compatibility with clients with the old web service stub. The idea is that I shouldn't keep the logic of the operations in both web services, and instead, try to forward the requests for older clients from the old web service to the new one. I found a solution, but I don't know what are its downsides: I kept the skeleton of the operations in the old web service, and in my ejbCreate(), I created an instance of the bean of the new web service, and now all I do is invoking the operations of the new web service using this bean instance (passing the same arguments as received from the client without running any logic). Is my solution valid? Are there any better alternatives?
why not to use ws-addressing? did you read about it ? (honestly I never used it, but I know it can be used to proxy requests)
Old thread, but here is a better answer for fellow googlers:
Check out membrane-soa reverse proxy: http://www.membrane-soa.org/reverse-soap-proxy.htm
To solve the exact problem in question check this doc: http://www.membrane-soa.org/service-proxy-doc/4.0/soap-quickstart.htm
Related
I have one webserver with 2 instances of tomcat running. On each tomcat instance I have multiple web apps or web services.
What is the best way to call a function (or trigger some event with parameters) from a webapp of the first tomcat server on a webapp running on the second tomcat server. If it's for example a call using a url with parameters then this call should be secure and not accessible from outside the server.
I've read something about getting the servlet context but is this possible on different tomcat instances? Im thinking that this is only possible with webapps running in the same instance.
I dont want to use CORBA, RMI or SOAP because this is a bit oversized for my problem ... that is what Im thinking :)
Code examples are welcome. Thank you!
The ServletContext is only valid within the same container and can't be shared between two JVMs. The simplest method to do what you're asking is to just use some variety of RPC between the two containers, and RMI doesn't seem like particular overkill. The other usual approach would be a simple HTTP Web service (note the lowercase "s") that invokes your logic in the receiving container.
Spring's HTTPInvoker is great for this. You can use a Java interface, and your code on each instance doesn't need to know the call is remote - it just calls Java methods.
For security, you can use the Sun HTTP server on a different port (instead of using a servlet within Tomcat) and listen only on localhost.
Have a look here
http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/remoting.html#remoting-httpinvoker
Use Simple REST services , not that much secured .
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
I am working to create a web app. Simultaneously I am also developing a REST web service that will use the same codebase...What I want to know is, can I make the same codebase on a server function as base for both the web app and the web service. (In the web app a user can log in and perform operations while the web service is like an API).
Or do I need to keep 2 distinct code bases for the web app and the web service?
Also, I want the same web app to act as both producer and consumer of the web services...Is this possible?
Yes you can. Technical a REST API is the same thing as the server side of a web application.
But if your REST API is accessed by third parties you might want to have a different versioning strategy then for your web app, so for anything of serious size I would probably separate those.
Sorry can't speak about the producer/consumer part of the question. Don't understand that part of the question.
You can do it that way, but it means that you'll have to deploy the two together. That might not always be desirable.
The alternative is to refactor the common classes into a third project, removing them from the app and the service. Package those into a JAR that you add to both the REST service and the app, just as you would any other 3rd party JAR. If you do it that way, you can deploy the two independently. The cost is maintaining the common classes.
Yes you can do both things from one codebase.. app and web service also, the complete game will be around URLs i.e. app URL and Web service URL..
And Yes it's possible, same web app to act as both producer and consumer.
I've got a j2ee web application using j2ee security, so the identity of the user is propagated from WebSEAL to the application, running in WAS7. I'm now trying to make a SOAP webservices call and propogate the user identity in that webservices call. To do this, I grab the LTPA (WSCredential) and LPTA2 (SingleSignOnToken) using the WSSubject calls and attach them to the webservices call using.
bp.getRequestContext().put(Constants.REQUEST_TRANSPORT_PROPERTIES,sendTransportHeaders);
where bp is my BindingProvider. This all should work. But when I make a webservices call, I get back this exception.
Cause =java.io.IOException: Unable to deserialize the Subjects in this Context
I looked at the fields within the LTPA token and all seems right (same realm between the token and the j2ee security realm webservice I'm calling, the token is forwardable, etc), and I cannot find much about this error online, except for (what seems to be an unrelated) case when trying to pass it into the EJB and one case where the realms don't match.
Any ideas? Thanks.
Can you state clearly as to what you are trying to do here?
You should be able to pass the LTPA tokens across transparently with just configuration instead of trying to write some code to achieve the same.
The Web Applications making the Web Service calls to another WebSphere server.
have a quick read at this.
http://www.ibm.com/developerworks/websphere/techjournal/0607_desprets/0607_desprets.html
Things in WAS7 should be very similar to WAS V6.
HTH
Manglu
#jeffsix: are you trying to make a webservice call from application running in one websphere server to another application in another websphere server? Make sure LTPA keys are same on both server.
I am migrating a Java RMI application to Java Web Service (school assignment) and I've encountered an issue...
Currently my Java Server creates an instance of the Remote Object, this object has a constructor and takes a parameter (int ID) which tells it which database to load in memory - works like a charm ...
Now, migrating this to Web Services is causing my a problem - first I needed to add a default constructor because it wouldn't deploy without it, and then while doing some reading all these discussions about "stateless web services" kept coming up ...
For example, if I "start" my webservice with parameter(0) it would load from Databse 0 and all requests from Clients would be done using that data... I want this to only happen when I start the WebService and NOT everytime the client connects... Loading from the DB is expensive and takes time, so I want to do it once so that clients when they connect just deal with the data in memory ...
This is how it works with my Java RMI .... but can this also work with Web Services?
Any advice would be much appreciated.
Thanks,
Perhaps you should consider splitting your presentation from the backing service. Consider the WebService simply a presentation layer and the database processing the service being presented. The web service should really just be referencing the database via a handle to a single instance rather than actually being that instance. This means that the "state" is then held in the database instance not the web service.
One way to consider this (although I would not suggest that you implement it this way) is to consider the Web Service as the RMI client of the database rather than the RMI server service.
Hope this helps.
Kind regards,
Malcolm