I have a JAX-WS web service exposed through the simple Endpoint interface (example)
If I understand the API correctly, as an alternative to directly calling Endpoint.publish (which uses the Sun's HTTP Server), we can:
Create the Endpoint --> Endpoint e = Endpoint.create(impl);
Publish the Endpoint ---> e.publish(context);
Can I use this e.publish(..) API to publish to an embedded tomcat server? (example)
The javadoc of the Publish method is pretty confusing to me.
Although it is more than two years old, this answer to a related question still applies. If you want to deploy to tomcat, no matter whether it is running in embedded mode or normal, you need to package a war and place it in the webapps directory.
To be usable with the publish() method in the way described in your question, tomcat would have to provide a Sun HTTP Server Service Provider Implementation, which it does not. An alternative to Sun's HTTP Server is for example Jetty.
Related
We are required to build some Java JAX-RS web services that will connect to some other external web services to retrieve data. Logically, we should host these new JAX-RS web services on a container like WebLogic. Due to cost saving measures by management, we are told to use IIS to host these JAX-RS web services as it is supposedly cheaper than WebLogic. They want the services to be written in Java because it is OS independent, so using .NET is out of the question.
(1) Is using IIS to host Java JAX-RS web services instead of a fully J2EE compliant container like WebLogic to save cost a good idea?
(2) How do we host Java JAX-RS web services on IIS 7.5? What are the required add ons?
Thanks in advance.
First of all, IIS does not support Java. See this old post in MSDN (2005)
IIS can never directly support the use of JSP because it requires an add-on to run Java code in a JVM to Load,
Therefore you always require a J2EE server to execute J2EE services, and the IIS add-on isapi_redirect (see the link). The add-on will capture the requests and forward them to the J2EE server (in the example is used tomcat)
So the answer to your question
(1) Is using IIS to host Java JAX-RS web services instead of a fully J2EE compliant container like WebLogic to save cost a good idea?
No, because you allways need a J2EE server., so the cost parameter is non applicable (without considering other aspects). I suggest also to consider some free of charge servers like Jboss, Tomcat or Jetty
Note also you do not need a fully compliant J2EE server to use JAX-RS. Latest versions of JVM are shipped with an implementation of JAX-RS.
I am a little confused about the roles of a java application server and its differences from a web server.
I found many sites explaining the same difference between the two but not to my satisfaction.
So please explain me about the two following cases:-
1)App. Server and its difference with web server:
From these two links:
Difference between an application server and a servlet container?
What is the difference between application server and web server?
web server: It handles everything through http protocol by accepting requests from clients and sending
responses to them with the help of its servlet container(e.g Apache Tomcat)
App. Server: An application server supports the whole of JavaEE like JMS,JPA,RPC etc.
Now what I am confused with is that how can I use a lot of JavaEE APIs like JMS,JPA etc. with my Tomcat
by adding their jar files in my web application ?
Does that mean that if I use an appliation server I don't have to add those jar files?(I don't think so)
2)The roles of an appl. server (This is very important to me)
From Wikipedia
http://en.wikipedia.org/wiki/Application_Server
An application server provides services such as security,transaction support etc.
"The term is often used for web servers which support the JavaEE" -- It sounds like if we add the required jar files of JavaEE APIs a web server becomes an appl. server.What about it.
Now my question is how an application server performs the tasks of security control or transaction management by itself ?
E.g. in my web application using Spring framework I am providing security by using spring-security and transaction management by using #Transactional annotation and all those things you know.
So does the appl. server have anything to do with my security or transaction management or it has its own ways ?
Forgive my ignorance.
Using Spring, you're in fact embedding some kind of Java EE container inside your application. But even when using Spring, if you need JTA support (because you need distributed XA transactions), you'll need to use an additional transaction manager. If you need JMS, you'll need to install an additional JMS broker. If you need connection pooling, you'll need to use an additional connection pool. Sometimes it's as simple as adding additional jars to the classpath and properties or XML files. Sometimes it's harder.
A Java EE app server comes with everything bundled. You have less flexibility, but you don't need to install, configure and make everything work by yourself.
When you use the Java EE framework, that is a specification. So the application server, if it is Java EE compliant, needs to implement this. So once it is implemented the specification, then it will address Security,transaction etc because it is mentioned in the spec. So it is a contract. Whereas, in a web server, it will just pull out your static resource. There is no need for handling other stuff.
In case of the Spring framework, the framework knows how to handle transaction, security etc. So particularly the developer need not look into these aspects which are implemented by the Application Server in the other scenario.
how an application server performs the tasks of security control or transaction management by itself
It is rather the specification that address these issues, not the application server. So, the duty of the app server is to implement these.
So, if your application is Java EE compliant, then these areas will be addressed and the implementation would have been done by the app server.
May be this is oversimplification,
A web server is basically a HTTP server serving contents over http protocol. So a web server is simply about serving the contents over http protocol. A typical example would be Apache web server. This is simply a file server.
Now the question is where does the web server gets the contents from ? Possible sources are
Static contents (the contents like images/css etc) which are not generated on request but statically served.
Dynamic contents: Simply put, the contents to be served are generated upon the user request.
For the static contents, the web server does not need anything as it simply reads the file and serves it.
For dynamic contents, the web server might need help of additional components which will generate the contents to be served.
Here the Application Server comes into picture.
Now these additional components referred earlier, might interact with database or some other system etc.
In a web environment where your website is exposed to huge number of users (intended/unintended), you need typical services like transaction/security/concurrency etc. so that the user get expected responses and do not see inconsistencies in the behavior of the application.
An application server has inbuilt abilities to manage transaction/security/concurrency/resource management. generally these are referred as Managed services and environment offered by them is called Managed Environment where these basic services are managed by the application server and programmer does not have be bother for them.
Application Server needs web servers or we can say Web servers use Application server's services to generate dynamic contents.
For example, JBoss uses Tomcat as inbuilt web server. Whereas web logic has its own web server. Tomcat again can be called as application server (in principle) as it also offers managed environment for servlets (it manages concurrency and instance pool of servlets/JSPs ).
Coming your your example of Spring:
An Application server will come inbuilt with transaction/security etc whether you need it or not. The Spring offers a very nice way handling this. Spring has all these things BUT you use what you need. Not just these, but just a Java Web Sever like Tomcat is sufficient to build a full fledged services that needs an application server.
I'm currently writing a few applications that contain web service clients and servers, as complete standalone applications, eg without any web application server / servlet engine. I'm using plain Java 6, and for the "server" part I'm using the sun HttpServer. Working like a charm.
(actually I am using CXF, but only for their wsdl2java tool, which is more flexible than the one that ships with Java 6).
I've been wondering now if there is any benefit for me to look at frameworks like CXF. Strangely enough, I can't find any information on the CXF web site on such a scenario, they just seem to blindly assume that everybody uses an applications server (and worse, maven).
One of the reasons why I'm looking at CXF is that in the near future I expect that I need to support AIX as well, and there I can't use:
reqcontext.put(BindingProviderProperties.CONNECT_TIMEOUT, connect_timeout);
reqcontext.put(BindingProviderProperties.REQUEST_TIMEOUT, request_timeout);
CXF has this thing called an HTTPClientPolicy which would nicely fit the bill.
Does anybody have any links to articles discussing using CXF without any application server / servlet engine? Are there any other benefits that CXF could give me over the current Java 6 JAX-WS implementation?
Maarten
Almost all the samples that come in the CXF distribution are setup specifically as a "main method" type service that starts up the service and clients and such as standalone applications without any use of an app server (or even Tomcat). The CXF samples would be a good place to start.
That said, they do all use Maven now. :-)
I made a web project in Java, using Java-WS.
How can I invoke service methods through HTTP only.
I don't want to generate (or worse write) any java web clients, and similar stuff.
I'd just like to invoke the method with a HTTP request.
And parse the result (manually) from response.
In .NET web services I invoke methods just with:
http://serviceUrl/serviceName.asmx/operationName?parametars=...
How to do the same thing in java + tomcat?
Edit: Let me rephrase my question.
So this is what I have done so far:
Created a web application (btw. using NetBeans IDE)
Added all the necessary source files
Added web service classes with WebMethods defined
I deploy the app on tomcat and it deploys fine.
Now, what do I need to do to be able to invoke my WebMethods via HTTP?
Typing:
http://localhost:8084/MyService/MyMethod
doesn't work.
Sorry if this is a stupid question, but I'm not really a Java guru, I've been working mostly on .NET.
Multiple possibilities:
use new URL(url).openConnection().getInputStream()
use apache http components
use a REST client (if you invoke restful services), like http://code.google.com/p/rest-client/">this, or these. Or spring's RestTemplate
In this case, if you want to do an HTTP Web Service that returns an HTTP 200 Web Response, why not look at doing a RESTFul application?
JavaWorld briefly explains the role/use of REST. There's been similar questions on REST tutorials in SO. I hope this helps you.
Apache CXF has a 'plain http binding', but we recommend that people write JAX-RS services, instead. They are very, very, simple. However, the plain HTTP binding is there and supports GET.
I generate a RESTful Web Service in NetBeans by clicking on "Generate SOAP-over-HTTP Wrapper" in my service context menu.
It generated successfully, compiles and deploys fine.
But I still can't figure out how to make a HTTP invoke
how hard is adding a basic web services interface to an existing java server application without having to turn it into a .war, or embedding a small web server like jetty?
say, xml-rpc instead of more modern approaches, if it helps.
if not too hard, can you suggest a starting point?
thank you in advance :)
It sounds like you're asking for the impossible: expose an HTTP service without plugging into or embedding an HTTP server!
Unless you want to reimplement what Jetty already does, I'd reccommend using Jetty as a library. That way you don't need to conform to the more awkward aspects of the Servlet spec. E.g. your servlets can have real constructors with parameters.
There is also a simple HTTP server implementation in JDK 6, but it's in the com.sun namespace so I'd avoid it for production code.
Check out the Restlet API which provides a painless way to implement RESTful web services that can run inside a web container or standalone.
I don't know what you are doing, but what about rmi?
RMI # stackoverflow
Spring-WS has the facility for using JRE 1.6's embedded web server, if that's an option for you. Spring-WS gives you a very nice SOAP server layer, if that's what you're after.
If not, then an embedded Jetty instance is probably the best idea.