A method in one EJB will call a Web service in another EJB. Do they need to be packaged in the same EAR, or can I deploy the Web service provider separately (in a WAR)? Will dependency injection (accomplished through #WebServiceRef annotation) work if the two EJBs are deployed separately?
Thanks!
Do they need to be packaged in the same EAR, or can I deploy the Web service provider separately (in a WAR)?
That depends on how you intend to deploy the EJBs. If you are deploying them in the same EAR file, and therefore, in the same container, I would consider the #WebServiceRef annotation to be pointless and a drag on performance. You might as well inject the other EJB instead of injecting a JAX-WS proxy in it's place.
If you want to separate these out and deploy one of the EJBs (the one providing the webservice) in a WAR file, then it is possible to do so in a Java EE 6 container.
Will dependency injection (accomplished through #WebServiceRef annotation) work if the two EJBs are deployed separately?
Yes, dependency injection will work as long as you have deployed the client in a managed environment (this includes application client containers, web containers and EJB containers). As far as the client EJB is concerned, the container will provide a proxy for the web-service at runtime. All calls will be delegated to the proxy, that will make the required HTTP requests to the actual web-service, and return the appropriate objects after processing the response.
Related
I have developed RESTful web services in two ways:
used a class that extends javax.ws.rs.core.Application without defining a web.xml file, using Glassfish.
haven't used javax.ws.rs.core.Application but included a web.xml and a Jersey implementation, using Tomcat.
Is there a preferred way of building RESTful web services with JAX-RS?
Using the javax.ws.rs.core.Application class is the preferred way and also the only portable way of configuring resources and providers in a JAX-RS web service,
so if possible that would be the recommended way to set it up.
But that works well only in JAX-RS aware servlet containers or application servers, for JAX-RS non aware servers you need other ways for deployment and that most of the times means some proprietary servlet class of the JAX-RS implementation you are using.
To get more details on the subject, see for example the Jersey documentation, Deploying a RESTful Web Service (for Jersey v1.x) and Application Deployment and Runtime Environments (for Jersey v2.x).
I am proxing huge amount of web services using JBOSS FUSE ESB.
using content based router for deciding the real web services. But, If there is a new services deployed in backend. I am forced to change the proxy details (WSDL) and expose the interface.
which leads to client regenerate the client code again.
Is there any other solution which will allow me to optimize this problem in design level.
Some general thoughts on this but I would need more detail to give some solid advise.
You are proxing the services thus you are not abstracting the services away. You are exposing the services rather directly to the outside via the service on FuseESB.
Typically you would use a ESB to abstract provider and consumers away from each other. This means that you wont expose/proxy the service directly. For example you would create generic operations and data structures. This will allow you to then map the generic interface to the web service implementation that you are providing.
Another approach would be to version the different WSDL's and thus have different versions of the services out there. This will allow you to have client consume the older WSDL's and then migrate them over bit by bit.
I have a working JBPM project that i want to expose as a web service so from my server i can call that web-service. So please let me know is there a any way to expose a JBPM project into a web service.
By default, you can use the jbpm-console service to expose the processes you have deployed there as a REST service. You can also expose your project yourself as a web service using for example the camel integration component (and using camel to set up a WS endpoint) or by writing a custom wrapper yourself.
I currently develop a Web application that can be accessed over HTTP by an Android application or a Web browser. Both user agents basically provide the same functionalities. The Android app calls RESTful Web Services built with JAX-RS/Jersey, while Web pages are Facelets backed by JSF managed beans. I thus consider that there are two types of possible entry points to the Web app. The Web services do all the necessary work (accessing the resources, performing the database operations within DAOs, etc.) and most importantly, they must act on their own. Therefore, they constitute an independent layer.
In order to reuse the code, is it a good practice to call a Web service from a managed bean? Are their life cycle compatible?
The idea is to inject the Resource object into the managed bean (with CDI, but not necessarily) and to call its methods programmatically. The Web service would act as a business delegate (?) to the underlying services.
I widely googled the question but I didn't get a clear answer. I saw some pieces of code where the managed bean invokes a Web service with its URL, but since all my components are located in a single server app, I don't see what prevents me from linking them directly.
Subsidiary question on error handling: I am also annoyed with the idea of catching WebApplicationExceptions from the Web service into my managed bean for returning error messages back to the view (with FacesMessage). My father always told me that I should never catch runtime exceptions...So, is there a good way to handle them correctly?
In this case, you would be better off having the business logic out from the Web Service into "some central shared code". Then, then web services and the managed beans would call into the shared code.
I've put the term "some central shared code" in quotes, as what you use depends on your runtime environment. If you're using a JavaEE container like Glassfish or JBoss, this sounds like a perfect use of EJB and stateless session beans (which are designed to ensure the resources are managed well). You could also use Spring Beans as the shared code and centralize the logic that way.
It all depends on what you find more comfortable from a development and production sense. But both support injection, so both the Web Service and JSF Managed Beans could have the services injected as any other resource.
I'm investigating integrating a 3rd party web application with PeopleSoft via web services. I'm not that familiar with PeopleSoft. After some initial investigation, it appears that in order to expose any PeopleSoft functionality as web services, you have to do some considerable configuration in the Integration Broker component of the PeopleTools module. It seems that you can either define internal PeopleSoft services with "service operations" and related "handlers" or you can create a PeopleSoft service for an existing "Component Interface." Then, you have to expose that PeopleSoft service as a web service.
Are there any standard, default, out-of-the-box web services available for a PeopleSoft system, or do you always need to go through the steps of defining them in the Integration Broker?
After looking at a system like Salesforce, which has a standard web services API, it seems like there might be something similar for PeopleSoft, but I'm not finding it. Am I on the right track in thinking that the Integration Broker is the only way to go, or am I just not aware of some standard web services API that exposes basic PeopleSoft functionaity as web services?
Integration Broker (IB) is what you need to expose business logic from peoplesoft and consume it with your 3rd party tool, or to consume a webservice from your tool in peoplesoft.
There are some out of the box messages, but most of them are made to have different PIA (PeopleSoft Internet Architecture) communicate.
Be aware, IB components were almost complemently remixed in peopletools version 8.47. So it's important to give your tool's version when talking about IB.
Never heard about a standalone API for implementing web services, outside of the IB framework. IB will use dedicated class to handle sending and reception of your messages. You mention it as the handler. And if a component interface need to be used it will be done throughout this class.
Integration broker is used to setup the basic configurations that will be used in exposing and using web services. this includes making nodes and its routing available for other system to use.
http://docs.oracle.com/cd/B14099_19/integrate.1012/b14060/int_broker.htm
There are many web services available in peoplesoft. you can alsi expose any componemnt as a web services by executing very simple steps.
http://docs.oracle.com/cd/E15645_01/pt850pbr0/eng/psbooks/tibr/chapter.htm?File=tibr/htm/tibr14.htm
Custom web services can also be build.