I have couple of questions.
What is the main difference between WebAppContext and ServletContextHandler.
My application has pages and restful service. Can ServletContextHandler be intended to use for Rest services than WebAppContext? (That means, is ServletContextHandler better to handler servlets to manage calls/requests to restful services?. But I have encountered running JSP s with ServletContextHandler) What are the advantages and disadvantages?
Is there any drawbacks if I use two contexts: WebAppContext to load JSP and other static contents(like js, css) and ServletContextHandler to handle requests to restful requests ?
WebAppContext represents a traditional webapp like a war file, the ServletContextHandler maps to a servlet
If your rest services are backed by a servlet, then of course, a ServletContextHandler could be used to mound that rest service. JSP support is a servlet so you can just run it that way. The only real advantage or disadvantage is a WebappContext brings all the automatic deployment and wiring of things up with the web.xml...if you don't need that then don't use it and wire things up yourself.
Not really, but if you are just using the WebappContext for jsp and static resources I would just use the JSPServlet and a DefaultServlet for the static content.
There are lots of different ways to do what you are looking to do. If you are comfortable dealing with servlet instances directly then just avoid the whole concept of the WebAppContext entirely. One other thing to be aware of, the WebappContext also provides classloader isolation for the deployed webapp, so that may or may not be a factor or something you are interested in.
Related
Please let me know if the premise of my question even makes sense...
I have a WSDL file from an existing (locally served) web service. I would like to "wrap" that web service with a Web API so I can easily make RESTful AJAX calls to it. If I add the WSDL as a Service Reference, I can write controllers and make calls.
I guess my questions are two things:
Is there some easy way to expose all the WSDL actions without manually writing controllers for each one?
Is this even a good idea in concept? Is there a better way to create a nice client AJAX relationship that I'm not thinking of?
Yes, it is a good idea in concept. Abstracting the ASMX for the clients and providing an easy REST based endpoint is good.
I'm assuming the ASMX is a separate component in itself and doesn't share any Middle-tier code with your Web API project.
It is okay to abstract out the ASMX.
As for an easy way to expose all the WSDL actions as controller actions, how many Web methods are we talking about?
Typically we only have a single ASMX web service with a few web methods. (5-15)
If you have just a few, creating a single controller with 10-15 actions should not be that painful.
On the other hand, if you have unmanageable number of web methods, you might want to think of Text Template files (.tt) to generate controllers out of 'Reference.cs' files. (proxy file) i don't think there are auto-tools to convert asmx to a web api controller.
i have found it easier to hand-write the web api controller due to the nitty-gritty of the request/response types, return types, [FromBody] [FromUri] attributes, HttpPost, HttpGet attributes, and of course the action definition itself.
The text template logic could get error-prone trying to figure out HttpPost actions vs. HttpGet etc.
Also, a good controller will end up having injected dependencies for Data Access, Caching etc. and you would want direct control on the class, rather than being created by an automatic tool.
We are using ejb 2.1 to expose as a webservice using apache axis2.I have read in codebranch website that both are serverside components where in ejb can be run in more than one server unlike servlets..but I didn't get clear picture of difference.
Let me quote this old (but good) comparison.
Enterprise JavaBeans are components meant to encapsulate business logic. They do not handle presentation and have a precise set of restrictions they must obey. An EJB may not manage threads, access files with the java.io package, have a GUI, accept socket connections, or load native libraries. These restrictions are imposed because EJBs execute inside an EJB container, roughly analogous to the way servlets execute in a servlet container. Where servlets can be used to perform many arbitrary tasks, including the generation of HTML pages, EJBs are used almost entirely as business objects. A session bean represents a client for a session or transaction and an entity bean represents a persistent business object that is usually stored in a database. Unlike servlets, a single session bean may exist per client. A single servlet may serve many clients. A session bean usually mediates client access to entity beans, shielding the client from the details of managing state.
I got exact answer Both are server side entities.EJB is designed by wrapping RMI API's.EJB is a service at Enterprise level.Main advantage that EJB can be a webservice which can deployed anywhere in the world.EJB is servicelayer enity which can even used by servlets.
We can have plain java in the service layer but differance that EJB has is it(EJB) can be alone deployed in any server unlike plain-java service layer.
What happen even many request comes through one spring controller?
Does Spring pipe it?
How about add #Transactinal on controller?
Is it have a benefit to use on controller layer?
Basically you are asking 2 questions
How are multiple, concurrent, requests handled by a handler.
Should we add #Transactional to a handler.
Multiple concurrent requests are handled concurrently. Each thread has its own callstack and location in memory and doesn't share a thing. In general no problem (used Spring MVC in very high concurrent applications) unless you start, for some reason, sharing state in your singleton, or forget to clean-up ThreadLocals.
Adding #Transactional is something bad, IMHO. The transactional layer is NOT your web but your service layer. So don't add transactions to your web but add them to your service layer.
We need to expose some services (i.e. AddressValidatorService, CustomerFinderService) that currently reside in an ASP.NET application to other applications within our organization. Exposing these services via WCF seems like a natural fit, but I don't see any best-practices for how to pull these common services into a WCF wrapper in such a way that my existing ASP.NET application can continue to use them with minimal code changes and/or awareness that the service they are consuming is no longer in-process.
I'm especially looking for recommendations on how to structure the existing ASP.NET solution and whether to host our new WCF in the same solution or in some new shared WCF solution referenced by both our ASP.NET application and external callers.
Also, is it bad practice to simply promote the DTOs currently only consumed in-process via ASP.NET to full fledged data contracts or is it preferable to create duplicate DTOs that are explicitly decorated with [DataContract]? The latter seems like a maintenance nightmare.
To answer your second question:
Also, is it bad practice to simply promote the DTOs currently only consumed in-process via ASP.NET to full fledged data contracts or is it preferable to create duplicate DTOs that are explicitly decorated with [DataContract]? The latter seems like a maintenance nightmare.
It is considered a bad practice to expose your business model as WCF contracts. So if your DTOs are replicas of your domain model then it would be a strict no-no, because
1. any change in the model would directly effect the contracts and hence all the clients using it
2. you would be exposing your business "know-how" to the outside world.
The latter can tend to get difficult for any evolving system, but then you have various open source tools (like AutoMapper) that ease your mapping nighmares.
You can convert an existing project to WCF, then continue to use it in-process by using a project reference. It can then be consumed by an eternal source using the WCF client. A WCF client converts the class name from ClassName to ClassNameClient when consumed over WCF, but the class will function pretty much the same.
For example:
MyClass obj = new MyClass();
obj.DoSomething(withData);
Would become:
MyClassClient obj = new MyClassClient();
obj.DoSomething(withData);
You would publish the WCF project to some endpoint, like address.example.com, then use a service reference to the endpoint to reference the code, like a project reference, in your other projects.
Note that while the externally referencing projects would not be impacted by the change or know that the data is going over the network, if you have chatty calls to the project in question, it will definitely take a performance hit. You may want to consolidate related methods into single methods to save on round-tripping.
If these are exposed as static page services, there's no magic wrapper -- you're going to need to move code to a standalone service implementation class and put a .svc file in front of it. (Or use WCF4 fileless activation, or a service factory, but that's getting a bit away from the core question here.)
If these are exposed as ASMX, you can actually put an ASMX facade in front of a WCF service class and get basic HTTP/XML/ASMX responses as you would from your legacy ASMX webservices. You an expose that same WCF service class through standard WCF configuration for non-legacy consumers.
Finally, you can expose any WCF service as basicHTTP with serviceMetadata + httpGetEnabled, and you'll get a service endpoint usable by legacy consumers of an ASMX service.
http://msdn.microsoft.com/en-us/library/ms751433.aspx
I am trying to understand Jetty.
Tell me please:
When is it better to use Servlets and when Handlers?
Can I use Connectors with Servlets for "thread-per-request model"?
In Jetty, Handlers handle requests that are coming through Connectors. One of the Handlers, specifically ServletHandler, allows Jetty to (mostly) support servlets. Servlet is a portable Java EE concept, so you can design your application in a more portable way if you use servlets in Jetty. On the other hand, they are likely to bring some overhead, so you might want to implement a Handler directly that would handle requests coming via Connectors.
If you are using servlets in Jetty, you can rely on the servlet security model, on the session support, etc. If this is unnecessary for your application, you might be better off implementing a very simple handler.
One interesting observation I found when played with it. I had a jetty-based application(dropwizard.io) and here I was planning to add handler after actual(there was special use-case for it)
server.start()
using org.eclipse.jetty.servlet.ServletContextHandler.insertHandler(HandlerWrapper handler) it just throws illegalStateException: STARTED if the server already started. Because of:
public void setHandler(Handler handler) {
if (isStarted())
throw new IllegalStateException(STARTED);
//..
But in case of org.eclipse.jetty.servlet.ServletContextHandler.addServlet(ServletHolder servlet,String pathSpec) it will add your servlet to existing servlet collection and everything will work.