Can anyone point me in the direction of documentation for exposing a DAO as an external web service? Currently, in my application we follow a DAO -> Service -> UI layered architecture. Everything is internal to the app, our DAOs access the DB through Spring JDBC and the services are visible only to the web application.
We now have a need for downstream systems within my company to access the DAOs we've created. I need to know what the effort would be to expose our DAOs and what, if any, other technologies I would need to perform this task.
Also, would I expose the DAOs themselves or the services?
I guess I don't fully understand the problem. You'll have to create service operations that do CRUD operations for you DAOs, along with operations for any special data processing your DAOs perform. You already expose the DAOs via service to your current UI. Can you not simply use that service as a template for your externally facing service?
If I were you, I'll just wrap the DAOs in a webservice. So, first define the wsdl, then generate the java code that goes with that wsdl. Then, in the webservice implementation, just hand-copy the entity beans into this webservice beans. Guess you could use bean copy utils if that is too tedious.
Not sure if you can use the entity beans directly in java2wsdl style webservice development, but that seems like a bad idea because you don't have an abstraction layer between entity beans and webservice interface in that case.
Related
I have a Spring Boot web application with presentation, business logic, data access logical tiers. Is it conceptually correct to describe external interface calls (REST, WS) to be in the Data Access Layer? I.e. also where database access resides. Conceptually, it would make sense to me.
Also, should interaction with external services be called DAOs or "clients"? I think e.g. Spring Boot tutorials call RestTemplates to be REST "clients", so one possibility would be to have a DAO, which then uses the RestTemplate "client" to actually make the REST call. Would this make sense?
Is it conceptually correct to describe external interface calls (REST,
WS) to be in the Data Access Layer
Data Access Object is used to abstract and encapsulate access to the data source. Data source could be a persistent store, external service, repository and etc.
one possibility would be to have a DAO, which then uses the RestTemplate "client" to actually make the REST call
DAO implements the access mechanism required to work with the data source. It is responsibility of DAO to provide abstract API for application, but implementation can be any. Using RestTemplate to make REST calls in DAO is perfectly fine.
Article "Core J2EE Patterns - Data Access Object" might be useful for reading
I want to develop an enterprise level application using spring MVC in presentation layer and spring in Business Logic Layer and hibernate in data access layer.
But i want to keep the presentation layer in a web server, multiple business logic layer in multiple server and data access layer in another physical server that means i want to establish a n tier solution using spring mvc.
I am able to separate the layer in my architecture. But the problem is my solution is just work on a single server. I cant do a architecture for multiple physical server.
Suppose that, from controller i use #Autowired annotation to inject the object of business logic layer. But how can i establish a system where controller talks to business logic layer over the network and business logic layer talks to data access layer over network as well.
If anyone can describe the solution in details then it would be very helpful for me.
Thanks...
You should be able to divide your code quite easily. Let's call your data access layer a "Data Provider" service and business logic layer "Business Service".
Now, you have to decide what kind of network protocol are you going to use.
These days REST is the most popular one and also it is very easy to setup your REST endpoints with Spring MVC (use #RestController on the server and RestTemplate on the client). You can also use RMI if you want to really couple your services (Data Provider and Business Service) using the same Java code (interfaces, DTOs etc.)
I've participated in several projects of Spring-based web-application - and have written a quantity myself. Usually we have (roughly speaking) following folders to divide our classes by categories like dao, models, web (for controllers if we use Spring MVC or backing beans for JSF for example) and also service - here we keep what we think is business-logic (even when sometimes classes here simply forward methods to dao).
Now I am faced with development of EJB application - I've learnt that I will have some web and model classes anyway. Also I may use dedicated dao layer or may put data access into facades (I prefer dedicated folder though it increases verbosity).
But I do not understand clearly whether facades are exactly the place to put business-logic in it, or I should add services folder for it and use facades more like dao (eliminating dao itself).
I also would be glad for short and comprehensive compilation of hints on EJB application architecture.
I would go with a similar setup with EJB as you have done with Spring. You have your web package (MVC stuff), then your service layer which contains most business logic and then DAO layer which contains basic CRUD operations and some database queries.
In this scenario you can test the possibly complex business logic in the session beans with fast unit tests that don't need database and you can mock the DAO access here. Then you can have relatively simple tests for your DAO layer, so the number of tests requiring database (ie. that are consirably slower) is smaller.
Normally I would call facade a set of session beans that offer simple methods for operating the system via for example Web services. These beans would use the normal service layer beans. With just a web layer and no integration layers I don't see a reason to create an extra facade layer.
I am using Java EE for running my backend system and I have a question regarding how to layer it appropriately in terms of creating a web service.
I am pretty much organizing my application after the principles of DDD which means I have a domain layer, repository layer and a service layer. So the service layer are annotated with #Stateless and they are my EJBs.
Now, I could go crazy and annotate this service class with more annotations for the JAX-RS framework...but I don't know if this is correct for several reasons:
Wouldn't this mix the layering a bit?
How could I then version my webservice? Let say that I create a webservice today, and tomorrow I find out that it is really bad, however during the night someone have created an application that uses it and if I trash it the applications could no longer be used. What I want is a webservice that can be found on www.myurl.com/api/v1/customers
and the new webservice on www.myurl.com/api/v2/a_new_customers_webservice
That is what I want in some sort.
There may be other cons too?
So what would the solution be? Am I correct if I say that I create another set of classes that I annotate with JAX-RS annotations and then the methods could internally use the methods from the EJBs in the service layer?
If there is going to be another webservice version I can create another set of classes that uses other URLs and logic. Or am I all wrong? How would you organize this?
The underlying question is how to organize code for reuse. As you pointed out, you can:
annotate your EJB services with JAX-RS to make them web service;
create EJB web services (i.e. with JAX-RS annotations) that reuse other common EJB services (one level of indirection);
create EJB web services that reuse common logic as POJO (one level of indirection).
All three a valid choices to me.
If you're confident about the API of the EJB service, but not the API of the web service (there could be some impedance mismatch), I would go for 2.
If you are not confident about what your EJB service should do, then that's probably the first thing to figure out ;)
If you're confident now, but suspect it might change in the future, I would pick the simplest solution 1 for now, and refactor later as necessary depending on what must be changed. Apply YAGNI.
I have an existing domain model annotated with JPA annotations that I would like to easily expose CRUD operations on via Web Services. I already have DAOs to perform CRUD operations on all of my entities in my domain.
Does anyone know of an way to do this that does not involve a tremendous amount of effort?
It depends on how my operations and services and what you call "a tremendous amount of effort." You're likely to be disappointed if doing anything more than pushing a button and having your wishes come true is too much.
But there are three parts to your problem:
Writing DAOs that expose the CRUD operations. I'd recommend an interface-based approach.
Exposing these as "contract-first" web services, either SOAP or REST.
Mapping HTTP requests and responses to your API.
I'd recommend Spring, because it'll help with DAOs, web services, and mapping. But I don't know if it'll be as effortless as you want it to be.
You can use Apache CXF in combination with Spring ROO to achieve this.
Please see this post for more details: http://forum.springsource.org/showpost.php?p=284028&postcount=4
Throw some annotations on that DAO, like #WebService and #WebMethod and use your JAX-WS implementation of choice. You can use JAX-WS Commons Spring for Spring integration.