I have a wls server where there are several web applications deployed. One of these web applications contain a restful web service which can take a long time to execute. Therefore I want it to have a custom WorkManager that can handle threads which otherwhise are considered stuck. As I understand you can set a work manager for a specific ejb by using xpath to point at its dispatch policy, like this
'/weblogic-ejb-jar/weblogic-enterprise-bean/[ejb-name="anEJB"]/dispatch-policy'
Is there a way to do this for restful web services, i.e. set the workmanager for a specific web service (or web application) and not all of the applications which are deployed on the same wls? The examples I have found only does this globally.
The WLS version I am using is 10.3.6
Related
We are developing an application which periodically syncs the LDAP servers of different clients with our database. This application needs to be accessed via a web portal. A web user will create, modify or delete scheduled tasks on this application. So, we have developed this application as a web service.
Now, we have to scale this application and also ensure high availability.
The application is an Axis2 based web service running on Tomcat. We have thought of httpd + mod_jk + tomcat combination for load balancing. The problem is that if a request for modification/deletion comes, then it should land on the same tomcat server on which the task was created initially. But, since, the request can come from different web users accessing web portal from different ip addresses, we can not have same session id (sticky session).
Any solutions? Different architecture? Anything.
We have also thought of using Quartz scheduler api. The site says it supports load balancing and clustering. Does anyone has experience of working on such scenario with Quartz?
If you are using Quartz for your scheduling, that can be backed by a database (see JDBCJobStore). Then you could access any Tomcat server and the scheduling would be centralized. I would recommend using a key in the database that you return back to the Axis service, so that the user can reference the same data between calls.
Alternatively it is not difficult to use the database as a job scheduler, then have your tasks run on Tomcat (any location), and put the results into the database. If the results of the job (such as its status) are small, this would work fine.
I have a stand alone Java application that needs to get information (string data) from a Java EE application, running on a Glassfish 3.1 Application server. I have created a web service for my Java app, but I'm wondering how I could achieve communication with the Java EE glass fish app (using servlet?).
I hope to have a method on my app that can be called from, for example, a client running on glassfish (and vice-versa). This method would have something like a String array as parameter, so that I would be able to pass the data between the apps.
Note: I am unable to deploy my app on Glassfish, since we are trying to achieve separation till we are sure the application I am developing will not cause Glassfish to crash ( we currently have other critical apps running on Glassfish). Also note that this is all taking place on the same machine.
You should develop a web service and deploy it on Glassfish within your existing application. You can do this via a Servlet based web service, or a Session Bean web service, whichever is more appropriate for you.
You will then create a web service client against that web service for your Java app, and integrate it appropriately with calls to the servers via the web service.
Of course, this should all be done against development servers, not your production servers. Glassfish can be deployed pretty much anywhere: your machine, another machine, a VM, in "the cloud". Not having a development server available for, well, development is unacceptable. There is no way you can determine if your app will "crash Glassfish" unless you can test it.
To quote the esteemed Donald Knuth: "I have only proved it correct, not tried it."
Get a test server, develop against it. Move forward.
Have you looked at the URL class.
try this url Java URL example
This may help
I have an app that take long time to deploy/redeploy because this use EJB3, JPA2, JSF, Icefaces
The app is deployed on glassfish 3 on ec2 in amazon web services. Each i redeploy the app, while is redeploying the app, the service isn't available.
How can i redeploy an existing application and still the service available, until the redeploy finish?
thanks in advance
Depending on your architecture, you will always lose the service for a few seconds whilst you redeploy.
The proper way to architect this would be to have a software load balancer sitting in front of 2 or more glassfish server instances which are set in a cluster. The load balancer will automatically route all requests to the server holding the older available service. Once the new service is up and running, it will route requests there again. Using mod_jk inside apache works well as the load balancer.
We have a Java 1.4 web service running on AIX 5. We want to have the web service methods execute under the context of the caller, not the hosting web server. How would we go about this?
You should be able to perform JAAS authentication (just like a normal J2EE web application), which will establish the principals associated with the subject. The container automatically ensures that the current worker thread is associated with the identified subject. The subject and its principals are also propagated down to the service/business tier as is the case with a normal servlet.
It might also be worthwhile to determine the web service security features of the underlying application server, as it might offer more features than the basic/digest/form authentication functionality that is present in JAAS. For example, WebLogic Server allows for certificate based authentication of web service clients (with some configuration involved), and that might be true of the application server that you're using as well. Usually, the container security features will ride on top of JAAS and the related security features in J2EE 1.4, thereby ensuring that the J2EE security features used in the other sections of the application will continue to perform as expected.
As the title suggests, this is in relation to Java EE and Glassfish in particular.
From what i've learned the application client is executed in some application client that has the ability to talk to glassfish. But there seems to be limitations to this regarding annotations.
Can someone give me an example of the difference in connecting to a glassfish application server from the two different application types?
What is the benefit of the application client approach, and what approach is the most commonly used when developing application clients for Java EE?
The code (work you need to do) associated with connecting to the app server in either case is not really all that hard... but it is covered in different docs.
These are the instructions on how to access an EJB from a stand-alone java application.
These are the instructions for using an app client to access an EJB from a Java EE 6 Application Client with GlassFish v3: http://docs.sun.com/app/docs/doc/820-7695/beakt?l=en&a=view
Accessing an EJB from an application client gives you access to more of Java EE services 'automagically' than if you were working with the EJB 'directly'. You can cobble together access to some of these services in the stand-alone case, but the burden shifts onto the application developer/deployer to make that access work.
Creating a stand-alone application that accesses an EJB will seem easy, in the short term, and many folks will invest in that strategy. If they deploy their client application onto a large number of machines, the burden associated with a cobbled together service access strategy can become a burden.
Deploying an application client that uses the application client container is not free either. The advantage is the fact that you have the support of your app server vendor to overcome deployment issues.
If you are using GlassFish (v2.1,v2.1.1 or v3), you can also take advantage of Java Web Start support, which simplifies client application deployment a lot.
An application client is actually run in a container and has full access to Java EE resources defined on your server in the same way that a Servlet or EJB does. This would typically be used for some type of admin client, not a user application. Here is one explanation.
In addition to the Java EE Application Client, there is also the concept of a Thin Client, which allows access to some Java EE resources as well, but not as easily as the App Client. It usually involves using JNDI lookup with absolute names as JNDI references are not available. A typical case for this would be a standalone producer/consumer of JMS messages. It is basically a lighter weight option of the full App Client.
If you are simply creating a user application, you will most likely want to either use a Thin Client model, or a plain old application that simply consumes services from your Java EE app via servlet or web service calls.