I have an assignment that requires exposing a web service to 3rd party vendor based web application. I have the choice of server platform (between the 2 mentioned below) on which to deploy the web service. Should I deploy on tomcat 6 vs websphere 6.1.
I want to developed JAX-WS compliance web services in this case (with all the annotation support etc.)
My main concern - which of these two server platforms will scale my web service better - for example today the load might only be 300 transactions a second but it could increase 3-4 times in very near future..
This is probably something you will have to figure out for yourself by doing some load testing against both servers (if you already have them installed). Performance issues will always be dependant on how you have coded your web service and what resources are utilised (e.g. database, jms, etc).
A well tuned Tomcat server will perform just as well as a well tuned Websphere server because it's just a JVM under the hood. Keep in mind that Websphere provides a full J2EE stack, it will provide you with access to J2EE functionality that Tomcat does not provide (e.g. EJB) which is only a servlet container.
As long as you write your web service in a portable manner, you will be able to migrate between Tomcat or Websphere or ServerX in the future if that is what is required. Portability can be achieved by using a framework like Spring, with remote services so that you're not tied in to using a particular vendor's stack.
If you already have investment in Websphere servers I would continue to use them. If you are starting from scratch, why not begin with Tomcat (it's free!). Should you run into perfomance issues you'll have to look into using a load balanced solution and both servers can support this configuration.
Related
We have a web service running on an old version of an application server. It this old application server is running on JAVA EE 1.4. Its clients are on another server also running on the same version of the application server.
The move to upgrade our application server has started. The new version now will run on Java EE 6. The thing is, the clients would still run on the old version. Would it still be able to access the web service that will now be running on Java EE 6?
If yes is the answer to #2, I have a follow up question below
Our web service will now be created using JAX-WS. Does that mean that we should generate client classes as JAX-RPC? for the clients running in the old version to be able to access it? if yes, how?
To rephrase the question, if you have a JAX-WS web service, how do you generate a JAX-WS client and how to generate a JAX-RPC client? ive done some initial research and they seem to be done the same way, which I'm not sure is correct. Im confused.
thanks
Since you mentioned J2EE 1.4, I am guessing that the web service is based upon JAX-RPC 1.x standard. As the Java EE 6 based web service is based on JAX-WS, I would suggest generating client stubs using wsimport command by using the WSDL from your new service to generate stub classes.
In case you want to dig deeper and you should always refer to the JAX-WS specification document here (read up on chapter 4 - Client APIs)
The service consumer (client) and service provider technologies are independent. You can (for the most part) have a JavaEE6/JAX-WS web service provider but still consume with a JAX-RPC client, technically (for that matter, clients might not even be implemented in Java!). The only technical barriers to this would be perhaps if your service provider used SOAP 1.2 constructs that JAX-RPC could not handle, but I suspect that not to be the case if you are strictly migrating/upgrading the provider application.
Several application servers still support JAX-RPC even though it is now (JavaEE 5 & 6) optional for compliant app servers to implement.
I would personally however recommend updating the clients to JAX-WS as you upgrade those applications/appservers. I would think they should work with the upgraded web service provider without change - so long as the service provider WSDL doesn't change when that application is upgraded (though you may have to regenerate them if there are subtle differences in the regenerated WSDLs - the marshal/unmarshal technology in JAX-RPC is notoriously brittle).
-SH
I have created a Web Service in Net Beans 6.9 and deploy it locally. And I am using it via a java SE application by adding Web Service client in this application. How to obtain the link of the Web Serice so that it can be used from anywhere ?
2) From where to obtain WSDL file of Web Service ?
3) How to host a Web Service on the internet ?
Thank a ton in advance..!!!
You could create a new project of type web application in Netbeans.
In the web application, you will then create a web service (NOT a web service client).
For publishing and testing the web application, you will have to deploy it to a web server (e.g. GlassFish).
After publishing the web application, the WSDL file will be typically located at: http://localhost:<port>/<your web app>/<your service>?wsdl
For GlassFish, the default port is 8080.
If your current Netbeans installation doesn't support web projects or you don't have GlassFish installed, I suggest you download and install the latest version of Netbeans with Java EE support (bundled Apache Tomcat and GlassFish server in the same setup).
http://netbeans.org/downloads/index.html
Hosting SOAP web services on the internet at large has not been terribly successful. For example Google had SOAP based web services initially, and they switched to REST based services in the end. You may want to reconsider and deploy a REST based interface. If the bulk of your code is not embedded in the web service, then you should not have that difficult of a time switching the interface.
To deploy a SOAP or a REST web service, you would need to deploy a 'full' Java EE container (e.g. Glassfissh or JBoss) on a machine with access to the internet. You might virtual hosting e.g. Westhost, Amazon, or there are turnkey solutions like Heroku (note: I'm not endorsing any of the companies listed here; they're just examples). If you just want to deploy a REST based service, any web container will do e.g. Tomcat or Jetty. In addition to services mentioned above you could probably host a rest web service on any service that will let you upload a war file.
Suppose I have 2 web services A and B in SOA project. Both web services are running on a remote servers. Web Service A depends on information available from only a locally installed desktop application on a human actor machine and thats all web service A does i.e. provide this information). There are hundreds of such human actors with the same locally installed application providing its own information that web service A needs. Web service B needs this information from web service A, the result of which (which is the whole benefit of this project) is provided to that human actor who originated this process (by loging into system and clicking some command button). So this human actor is acting like the consumer of Web service B. The question is how can I make this locally installed application act as Web Service A (in the context of SOA project)?
This question could best be answered by some one with extensive experience in Web services and SOA.
This SOA project uses java, like ESB based on Java and there is no Microsoft specific services running although the desktop application is a Windows application. The application provides c/C++ API for an external process to call and retrieve the information needed by Web service A. What I want is the both web services A and B are hosted on remote server and interacting with each other via ESB but the problem is how to make local application information available to Web Service A?
There are two types of solutions
The first: have the original client application add a parameter with the address of web service A, and use this address for calling the service.
The second: pass a more abstract user identifier from the client (actually, there's a good chance you have such a field in the service). and use a translation service to retrieve the physical address corresponding to this id.
To allow such translation, the desktop application that acts as a server needs to "register" with the translation service when starting up.
If you are using an ESB, or other SOA infrastructure (like a service directory, message queuing service) it will include much of the functionality you need to build the translation service.
regarding the actual hosting of the service in the client machine.
the simplest solution is to use a different process from the actual application, and just access the files or DB the application uses.
In this case you can use any infrastructure you like to develop the service.
a more complex scenario is when you need the actual application to supply the service. in this case you will need to have a thread in the application that listens to service requests.
if you are using WCF see Hosting Services about how to host a web service in your application.
EDIT
some additions regarding you clarification.
as I understand, the desktop application exposes a C\C++ API that is available for external processes on the same machine.
You can either write a web service that will use this API. Googling "C++ Web Services Windows" will give yo several relevant pointers on implementing those.
Another good option is to use a messaging infrastructure. most JMS providers provide API's in languages other then Java - including C++.
Your application will be a C++ windows service that listens and sends messages to you JMS provider.
Simple problem, actually. I am trying to evaluate the possibilities of Google Apps, using Python as development language. It seems practical to create a web application or web site with it, but how about creating web services?
I am not too interested in solutions to create a SOAP or REST service in Python for Google Apps, since a simple Google search should provide plenty of solutions. I am more interested in experiences and ease of use.
But the real question is: When comparing a web service in Google Apps with web services in the Microsoft Azure environment, which would provide the better performance? The best user experience? I don't care for the actual development languages but need a good comparison of pro's and cons of web services in both the Google App Engine and Microsoft Azure.
Somehow, Azure seems better suited for services while Google seems better for sites. A tough choice...
Would be very interesting to see if both could be combined into a single solution. :-)
Btw, choosing which engine to use also means choosing the proper development environment and programming language. While I'm proficient in .NET and Python and many other languages, the choice for the service engine determines my focus for future projects.
When building services in Windows Azure, they'd simply be processes running in your VM (Windows Server 2008 SP2 or R2 SP1). You can host services easily in any of the three role types:
Web Role (essentially Windows Server with IIS running) - just add a WCF endpoint to IIS or self-host from your own process).
Worker role (Windows Server with IIS not running) - self-host from your own process
VM role (your own Windows 2008 Server VM pushed to Windows Azure) - Host with whatever mechanism you install / set up.
Each VM in Windows Azure may expose a total of 5 endpoints. These can be a combination of input (external facing) and internal endpoint, each port supporting tcp, http, or https. You define endpoints in your vm role's properties.
Internal endpoints are only usable by other VMs in your deployment. You can't see them / access them from anywhere else, including other Windows Azure deployments. Input endpoints are accessible by the outside world.
If you want an app running in Google to access your Windows Azure service, simply connect to the endpoint via ip+port. The one thing you'll want to be aware of is bandwidth usage. Because your Google-hosted app will be in one data center and your Windows Azure service in another, you'll pay ingress / egress for data going in and out of your Windows Azure service (and I'm guessing there's an associated bandwidth charge on the Google side, but I'm not sure).
It's actually pretty simple to set up a service. For .NET-based examples, look at the labs in the Windows Azure Platform Training Kit (this also other good examples, such as setting up your first Windows Azure application). For a python service host, you'll need to execute python.exe from your VM role's OnStart() event handler, passing in your script name (and optionally port number to listen on). For a simple example of launching python.exe, look at Steve Marx's blog post here.
EDIT: If you're looking to host multiple services (e.g. multiple ports), you can choose to host them in a single VM role or in separate roles, to optimize for cost (with the known limit of 5 endpoints) or performance (scale each service independently).
What are the differences between a web service and a Windows service?
My experience has mostly been with Windows services, and I have never created a web service.
Do web services behave similarly to Windows services?
Can they have scheduling, run at certain times, etc.?
When you would use a web service in place of a Windows service, and vice versa?
They're about as different as two things can be.
A Windows service is an application that runs without a user being logged into the system, usually to process some data on the machine that needs no user intervention to work with.
A Web service is a website that, when contacted, returns XML (typically) in one of several standard formats for the service consumer to process.
One can't be substituted for the other. They are fundamentally different.
You are asking us to compare apples and oranges. I am posting definitions as well as links to further reading for you so you can see why these two things are exclusive and cannot be compared like you are trying to do.
Web service:
Web services are frequently just Internet application programming interfaces (API) that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services
Windows service:
A Windows service is a long-running executable that performs specific functions and which is designed not to require user intervention.
A web service is an HTTP interface to a system. For example: the Twitter API or the Google Maps API are REST web services.
A Windows Service is a background process that runs without user interaction.
The two are not related.
Webservices are simply a way of exposing services for consumption. They are about interaction between components.
A windows service is an executable that runs for a long time on a machine to perform some task.
You wouldn't use one in place of the other - they perform two entirely different functions.
For (a simple) example (to highlight the difference), if you wanted a method to pass control messages to your service, you could expose a webservice as the protocol through which third parties would communicate with your service.
A web service is software system used for machine to machine communication over a network.
Here's the wiki for Web Service.
A windows service, in contract, is a service that runs on an local machine.
Here's the wiki for Windows Service.
They are independent technologies, one would not replace the other.
I don't think there is a very large difference, a web service runs in IIS or Apache, a windows service doesn't. You can call windows service methods by using remoting and you can create windows service with WCF. The methods of a windows service can return xml or json too.
IIS 6 doesn't support all the WCF possibilities so we have build WCF windows services (this is called self hosting).
Both a web service and a windows service are apps that run in the background. You can use WCF to build both kind of services.
web service was mostly used in application integration between systems.
windows service was mostly used in background tasks, scheduled tasks.
A windows service program can call web service methods.
web service program cannot call window service methods.
A Web Service is a dll hosted by a web server and run as a web application and can be spun up upon request.
A windows service is an exe hosted by the operating system and runs continuously waiting on a request.