I want to create a web service (SOAP) under Apache Tomcat with Axis2, and I must respect the three-tiered architecture:
DAO -> Business Logic Layer -> Presentation Layer
I'm new to web services. Is there a step-by-step tutorial for this?
There isn't really a presentation layer in a web service, unless you consider the service itself to be the presentation layer.
http://www.roseindia.net/webservices/axis2/
There is tons of DAO information on the web, and there's nothing special about a DAO layer for a service versus any other application. A lot of this will depend upon how you want to build your DAO layer. I like using Spring JDBC.
Three tiered architecture means different things to different people.
One common interpretation is (with tiers from the user starting with #1):
Presentation layer running in the browser. I.e. Javascript (possibly from some framework such as jQuery, GWT, etc).
Business Logic layer running on the server. I.e. A dynamic web server (Tomcat in this case)
Database such as MySQL, SqlServer, Oracle, PostgreSql, etc.
It's also possible to have a layer #2.5 doing the DAO work for you (or a custom DAO) such as Hibernate.
Another interpretation is that #1 is actually the web server, and #2 is a separate business logic server, where #1 and #2 live in separate server instances (likely on separate machines or VMs) for security, isolation, and the ability to scale and release separately (and many other motivations).
In any case, you should read up on typical Java serving architectures and possibly describe your goals better. I.e. you use "Presentation Layer" which in some definitions doesn't make sense for a non-UI based web service. Of course, Axis2 could be your "presentation layer" for a web service as well :)
Related
I have developed a web application with Java EE, which connects to a DB. The app is deployed on Tomcat 8. The app is divided in three layers: db layer, business layer, and presentation layer.
Now I need to develop a RESTful API that will use the business layer and will provide most of the functions that the presentation layer provides. Clients will have two options to choose from: open a browser, connect to the APP and use it or consume the RESTful web services from their own software.
My question is: should I deploy the RESTful API on the same server where the APP is deployed or separately? What are your suggestions?
And, what kind of authentication would you suggest for the REST web services?
Thanks!
It is a rather broad question and the short answer is it depends.
Functionnally, you have three parts here:
the presentation layer
the API interface
the back office: business and db layers behind the 2 first ones
Common technical architectures are:
one app for the API and business and db layers, one app for the web layer using the API
everything (API, Web and business) on the same application.
The former offer a better separation and can be interesting for heavy loaded applications, or if you plan to move to a javascript interface (AngularJS ofr example), the latter will be simpler to implement.
For the authentication, it is simpler to pass the credentials along with each request for an API, but you should considere managing it outside the application itself through filters and/or AOP concepts. Spring Security is an example of how this is possible and gives a very loose coupling between the business code and the authentication and authorization ones. You can then choose and change your authentication methods with little impact on the core of the application.
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.)
Supposing a classical 3-tier JavaEE architecture like this
JSF / JSP / Servlets (Web)
EJB (Biz)
DB (Persistence)
All JavaEE tutorial examples show the web and biz layers in different containers, but in the same JavaEE server.
Is there any situation where there is an advantage to keep the EJBs apart, in their own machine? In this case, supposing they're going to communicate with the web tier via RMI, is there any kind of JavaEE container that manages EJBs but not JSP and servlets?
Is there any situation where there is an advantage to keep the EJBs apart, in their own machine?
Sometimes, specifics non-functional requirements can determine your app design.
For example, security: in order to achieve some security norms, the business layer has to reside in a more secure server not exposed directly to Internet.
Availability: if your business layer exposes some services consumed by a different client than the web server, and these services offer some kind of mission-critical functionality, probably they need to run on a 24/7 server.
I'm not sure that think in terms of "advantage" is the correct way to see this kind of decoupled architecture.
I think that is more like a price (which is translated in a more complex design) that you have to pay if you need achieve this kind of requirements.
is there any kind of JavaEE container that manages EJBs but not JSP and servlets?
Yes, for example OpenEjb.
Is there a possible architecture that a developer can think of when it comes to extending a web application by introducing Web Services to the existing architecture or vice-verse. The main concern in this context is the data integrity and security.
The following images will suggest two approaches that a developer can think of.
This architecture indicates that all the request should be handled by an individual service layer. Therefore, only the service layer can communicate with the Data Base and satisfy request for both the web application and the gate way.
The second approach shows the web application is directly communicating with DB. For an example an Admin Portal. Meantime there can be an external web services also communicating with the DB. This approach may lead to Data Integrity Violating scenarios. However, introducing external web services might be easier than refactoring an existing Web Application to call a web service from developer end. Hence, can we still compromise for the long term consequences by having external web service and a separate web application instead of both the Web Application and the Gateway being catered with a single web service layer. Any reasonable comment on this would be appreciated.
You could build an API that has access to everything. In other word, the web application could work trough a rest/rpc api using Ajax/WebSockets.
Since everything goes through the API, data integrity shouldn't be enforced at any time. Also, you'll get a clear separation from Client, Api and Database.
This will allow you to replace the database by anything else without breaking other parts of your system.
I would personally advise to have at least a shared data access layer which handle data validation and persistence.
The best way would be however as defined in your first diagram with a shared service layer to factorize transaction management which should be defined at this level. You could so take advantage of custom transaction isolation and / or locking policy in order to ensure Data integrity. Public service layer methods could be in this case directly exposed as rest services and consumed by both mobile and web apps (gateway / API component is not necessary).
All of this will depend on the estimated time to refactor the legacy app architecture on a way and to duplicate data access logic (and business one ???) on the other. Of course the duplication will decrease maintainability and extensibility.
I've had to answer this question on several projects; there's a 3rd option which you don't mention, which is my favourite.
The problem with option 1 - "web services as persistence and business logic layer" is that it introduces a lot of additional moving parts into the design. Those moving parts are expensive - you have to write, test and maintain a lot more code, and very often the services you want from your web services to run your own application are not the ones that would make sense to a 3rd party developer.
You are also introducing a potentially significant performance and scalability risk - calling a web service which calls a database is measurably slower than just calling the database.
The second option - duplicating business logic across web app and service layer - has all the problems of duplication.
The option I prefer is to develop the business logic layer as a separate component, and have it used by both the web app and the web services; each application uses the component as a library. This means you have to have separate teams - the "library" team and the "app" teams - but you avoid duplication, and you avoid invoking a bunch of web services every time you have to render a web page.
The business logic layer is responsible for persistence - including making sure that database consistency is honoured, and managing transactions. As the business logic layer is shared between both the web app and the web services, this logic is concentrated into a single code base, and - ideally - made entirely transparent to the apps.
The web services now do far less. Their job is to handle incoming requests, translate them into method invocations on the business logic component, and returning any response data in the appropriate format (XML, JSON). They may offer "coarse grained" service requests and map them onto several more granular business logic methods. They may deal with authentication, authorization, request throttling etc. They just don't deal with the actual business logic.
If I have a hosted web application, is it good practise to split the web and api web service into 2 different projects/hosted applications in tomcat?
I can see that if people try and abuse the API it will effect the performance of the web application.
If I was to go with creating 2 separate projects (or if not initially but build for the potential to split things off), can I somehow share my hibernate data layer between 2 projects?
I'm using IntelliJ, how can I do this? Would it be to create a seperate module for hibernate (domain entities, Dao, and Service classes).
I wouldn't say is a good practice in general, but maybe a good idea for some scenarios.
In a service oriented architecture, a service layer is consumed by not only the web layer, but potentially other clients. In this case is probably a good idea to build the web and service layers in separate servers.
Another case would be when you want to perform separate deployments, because e.g. work in both layers is done by different teams or in separate workstreams - I would question whether this is a good practice though as opposed to teams working in vertical features rather than in layers.
You can create your service layer in many different ways:
As web services. When you need interoperability.
As remote EJBs (this is possible in TomEE). When interoperability is not necessary.
You can also create a combination of the both above, they are not mutually exclusive.
In terms of splitting the projects, you could create:
A set of domain objects in a jar module that is to be shared between your web and service layers.
A war module for your web layer.
A jar module for your service layer interfaces that is a dependency for your web layer.
A jar/war module for your service layer containing services and DAOs.
What's the difference between what you call "web" and "api web service" from the client perspective? A programmatic client can "abuse" either of those, so not sure if it makes sense to split them for that reason. You can use a load balancer to scale out.
You could make an internal API that the web interface consumes, and a web api that consumes the internal API.