Let's say that you have a presentation tier in JSF, and that your business tier is accessed using web services. How would you call your web services from JSF?
I was considering to have my backing beans to call the web services, but I just though I could use Ajax with JSF in order to connect to the web services. What would you choose and why? Any other choice you could recommend?
EDIT: I'm using Spring in the business tier, maybe that info may help with the suggestions.
Thanks.
I'd wrap the web service call in a service class, that is accessed via the managed bean. Thus the front-end will not know how exactly the data comes to it - via web services, or via any other means.
Let's say that you have a presentation tier in JSF, and that your business tier is accessed using web services. How would you call your web services from JSF?
The "classic" approach would be to inject a JAX-WS proxy factory class (generated from the WSDL) in a ManagedBean:
public class ItemController {
#WebServiceRef(wsdlLocation = "http://localhost:8080/CatalogService/Catalog?wsdl")
private CatalogService service;
public DataModel getItems() {
if (model==null || index != firstItem){
model=getNextItems();
}
return this.model;
}
public DataModel getNextItems() {
Catalog port = service.getCatalogPort();
model = new ListDataModel(port.getItems( firstItem,batchSize));
return model;
}
}
Sample taken from Sample Application using JAX-WS, JSF, EJB 3.0, and Java.
I would implement EJBs and expose them as web service (for language independet remote access) within the application I would access the EJBs by lookup and direct call them (for better performance). Unfortunatly you did not tell what platform you're using, so I can't be sure whether my suggestions would be feasible.
Related
I am working with Java 1.7, XDoclet 1.2.3, WildFly 8.2.1.Final, Dynamic Web Module 2.5, EJB 2.1 in Eclipse Luna.
I have an Enterprise Application project named
P001_EAR.
I have a Dynamic Web Project named P001_WAR.
I have a EJB Project named P001_EJB.
I have a EJB Client Project named P001_EJBClient.
I have a Utility Project named P001_SRC.
The P001_SRC contains the data layer, domain objects, business interface, helper classes.
The P001_EJB has Stateless Session EJBs which implements the business interface. It has a reference of P001_SRC.
The P001_EJBClient contains the remote and home interfaces of EJBs. It has a reference of P001_SRC.
The P001_WAR contains web stuff listeners, filters, servlets, JSPs, HTMLs. It has a reference of P001_SRC.
This is a typical scenario:
JSP call Servlet, Servlet call Business Delegate, Business Delegate call EJB (using ServiceLocator), EJB perform business operation.
Question is where to put Business Delegate?
I was thinking of putting them in P001_SRC but Business Delegate needs a reference to P001_EJBClient to perform their actions and that means a circular dependency.
How you would solve this issue?
Also the issue is to where to put the Service Locator? Would it go in the same project as Business Delegate?
Thanks
In a classic J2EE design pattern, the each client module of the EJB would have its own Business Delegate, which knows about the actual EJB. In your scenario, it would be in the WAR (as it's the client of the EJB). Similarly, your Service Locator would reside along with your Business Delegate and provide data about where your EJB is.
But seriously, is this some kind of exercise or school/interview question? Or are we traveling back in time? :-)
If this is for a new application, I would seriously consider moving away from EJB 2.x in favor of EJB 3.x, as it simplifies a lot. You can't even say that you "can't move", as you are already using an application server that supports EJB 3.x.
I am quite new to Spring and have a question related to Spring Service naming convention.
I have written a service, and used an annotation to define and name it.
#Service(value="CustomerService")
This service is implemented within a library that is used by a web app. Everything works fine and I can autowire my service into my client components.
Now I would also like to expose this service using http invoker. This works ok. I have define a /CustomerService http service which accesses CustomerService bean.
The issue I have is that one of my components, a client side component, that I used in my web app (CustomerDetailsValidator) can also be used in this new application.
In my CustomerDetailsValidator I have something like this:
#Autowired
#Qualifier(name="CustomerService").
But if I want to reuse my CustomerDetailsValidator and use it in my new app, this time I need to wire it to the httpservice instead.
Which means that the #Autowired and #Qualifier code is useless.
My question is what is the best practice in this case?
Should I still use #Service?
I guess I cannot use Qualifier anymore.
My feeling is that I should define everything in xml in each application context.
The web app using the library directly would just use the CustomerService bean as a singleton.
While my new client app would link the customer service id to the http service.
Is that a good approach? Do we have patterns for this?
Thanks and regards
Gilles
I am learning Spring using this tutorial. I am unable to get my head around the following excerpt from it:
Spring enables developers to develop enterprise-class applications using POJOs. The benefit of using only POJOs is that you do not need an EJB container product such as an application server but you have the option of using only a robust servlet container such as Tomcat or some commercial product.
In the good old days when application servers only supported EJB 2 it was a nightmare to develop services using EJBs. Each service (e.g. a stateless session bean) required a bunch of interfaces and strange additional methods to work properly (home interface, remote interface, deployment descriptors etc).
In order to run EJBs you need an application server such as Jboss or Glassfish. In order to run servlets you simply need a servlet container such as Tomcat or Jetty which is way more lightweight than an application server.
Spring offers a way of creating simple services as plain POJOs (that can be exposed via servlets). Therefore, to be able to develop services as a POJO was simply a dream come true. Services did not need all the constraining dependencies to the EJB-interfaces and they could be deployed in a lightweight servlet container.
Then came EJB3 which greatly improved life for the Java EE developer. EJBs no longer needed the dependencies for home- and remote-interfaces (at least not via inheritence). A modern EJB 3 service is very similar to a POJO-based service. The main difference is that EJBs still require an application server to be deployed.
Spring Guru Rod Johnson released the book J2EE Development without EJBs which greatly explains how to replace your old J2EE components (such as EJBs) with more lightweight Spring Pojos - good reading!
Read below link which may help you understand meaning of benefit of using POJO :
http://www.javaexperience.com/difference-between-pojo-javabean-ejb/
I'd like to play with Torquebox and have Rails (or e.g. Sinatra) as a frontend, but have all my services and business layer in EJB with CDI and JPA and all that stuff.
1) Can I have it all deployed as one application and use local calls for EJBs
2) If I have Rails, I can use models (no ActiveRecord) just to exchange data with frontend. How can I call EJB services with such models? I mean having:
def create
user = User.new(params)
userRepository = inject(Java::com.example.UserRepository)
userRepository.create(user) // this is java call
end
How can I pass User (jruby model to EJB call)? Or should I do
user = Java::com.example.User(params)
instead of plain ruby models.
Basically I'd like to have front in Ruby and the rest of machine in Java EE stack.
The TorqueBox integration tests have an app that does something similar, see:
https://github.com/torquebox/torquebox/tree/2x-dev/integration-tests/apps/rails3/twitter
It loads an ApplicationScoped bean from lib/ejb.jar, the source of which can be found at:
https://github.com/goldmann/confitura-2011-torquebox-demo/tree/master/cdi
Hopefully that will get you pointed in the right direction.
I'm trying to expose a web service method via JAX-WS annotations. Many examples I've seen reference the EndPoint.publish() method to quickly stand up the service in a standalone app (ex from Java Web Services: Up and Running, 1st Edition):
public class TimeServerPublisher {
public static void main(String[ ] args) {
// 1st argument is the publication URL
// 2nd argument is an SIB instance
Endpoint.publish("http://127.0.0.1:9876/ts", new TimeServerImpl());
}
}
One thing that I'm missing is how to accomplish essentially the same thing but in an existing app. Would I make a servlet to handle this? What is the proper way to publish this service in an existing WAR file?
In a container you don't have to publish like this. The container will do the publish. If you plan to use it in JBoss server try JBossWS otherwise for Tomcat or any other server Axis2 may be the better choice.
Read more from the following links.
http://jbossws.jboss.org/mediawiki/index.php?title=JBossWS
http://ws.apache.org/axis2/
This depends on what WS stack you are using.
If you are using Java 6 then that includes the JAX-WS reference implementation, then you can consult the documentation about JAX-WS RI WAR contents.
As #Jerrish and #andri coments, there are different aproaches and solutions, depending on your concerns.
The idea behind is that you don't need to set the configuration (port, etc) when will be published your web service. The best approach could be to set this via configuration files (XML, properties, etc) or using #Annotations.
For example, if you're accustomed to use frameworks like Guice or Spring, you know that is possible/recommended to start the context of your application publishing or initializing some objects, factories, datasources, etc and publishing webservices is another task that can be done in this time, because will be available when you will start your application, isn't?.
By the way, I've good experiences with CXF and another solution could be Spring Web Services another powerful solution for creating web services.