Originally posted by Micheal John:
I want to expose something as services. For example I am writing a hello java program which will return "Hello World" string and i want to expose this as service. So I can use either servlet/EJB/standalone java for this.
Servlet. This is the most common way to expose a web service implemented in Java. However note that the framework/application server could chose to use a single controller servlet that handles all the web services on a single server instance (like Axis 1.x does) or each endpoint could have its own dedicated servlet. EJB. Initially it was thought that it would be convenient to expose existing SLSBs as web services. However your typical SLSB interface is too fine-grained and chatty to expose as a web service (too much overhead resulting in a web service that is too slow and consumes a lot of your server resources and bandwidth. Also you loose all the usual EJB benefits of (declarative) transaction control and security. Web services should have a much coarser grained interface than your typical SLSB. However there is some advantage to exposing a planned (coarse-grained) web service contract to other application servers behind the same firewall through an SLSB interface - the resulting inter-server communication will be much faster and more efficient compared to web service interactions. standalone java. NOT POSSIBLE. To expose a web service requires a web server of some kind. In most cases it will be exposed through a servlet -type construct. That servlet may be accessible to the web services developer or it could be buried somewhere deep in the framework/application server.
So i will registry this service in UDDI so that users can use this service.
That is possible but not necessary. You can simply email WSDL to your business client (or make it the WSDL publicly available through a public URI) - that is enough. If you register your web service with a PUBLIC registry (try to find one right now...good luck) then a prospective user can find your web service by searching for key words and business area classifiers - then they retrieve your WSDL which they then use for their web service client.
How can a user (both java/non-java client) will access this service?
The WSDL
describes the web services interface, it establishes the web service contract. Your business clients can use that to either generate a static stub on their platform (Java or not) to access your service or they can use it dynamically to build request messages and parse response messages "on the fly".
What is purpose of Java2WSDL and WSDL2Java? Where it will be used?
Java2WDSL interprets Java objects and generates a WSDL web service contract based on that. Personally, I'm not fond of this approach because it ignores the impedance mismatch between the object-oriented and service-oriented paradigm (and more fundamentally the
object-hierarchical impedance mismatch). See one of my
rants. And many JAX-WS annotations are
web service magic pixie dust. Java2WSDL is easy on Java developers because they can specify their web service interfaces in Java - however this approach will often lead to overly obscure WSDL web service contracts;
you should make matters as easy as possible for your business clients - design a clean and clear WSDL (web service contract)
contract first.
WSDL2Java basically does the opposite. It generates a "Java-API" from a web service contract specified in WSDL. While Java2WSDL is a pure web server service tool, WSDL2Java can often generate both web service client stubs and web server service skeletons.
See also:
Java BluePrints: Patterns, Guidelines, Conventions, and Code: Designing Web Services with the J2EETM 1.4 Platform: 3.4.1 Designing the Interface
Which one will be created first WSDL or Java?
I think I made my preference clear. Do the WSDL (contract) first. However for convenience sake quite often Java comes first - and then the real problems may only come down the road.
What is role of SOAP?
SOAP is simply the XML envelope for your XML (message) payload. It is used to keep interactions extensible so that additional features like security and transaction control can be added without impacting the XML (message) payload; it also keeps fault information separate (separation of concerns). These features then keep their information in areas separate from the payload, like the SOAP header. Also SOAP/WSDL was originally designed to function in various transport environments - not just over HTTP. So SOAP allows for routing control over multiple intermediary SOAP nodes
between the initial sender and ultimate receiver; currently this feature is rarely used in web services, though it can be useful in service-oriented architecture scenarios. Usage of the HTTP transport protocol negates certain WSDL features; HTTP cannot accommodate the Notification or Solicit/Response MEPs (Message
Exchange Patterns). They either have to be faked though the use of
]asynchronous operation web service patterns or through the use of additional web service protocols like the
SOAP conversation protocol,
Web Services Conversation Language (WSCL) or
Web Services Addressing (WSA) (which basically require that both the sender and receiver are full blown web service servers).
Can anyone explain me what are the steps needs to be done if a user wants to write a java program to be exposed as service and how the client will access it?
That is possibly the wrong way to look at it. You decide that you need a web service for your clients. You design the interface (contract) that is required to serve your clients. Then you design the WSDL which describes the service contract. Finally you decide that you are going to implement the web service in Java. So the Java consideration is at most
secondary.
3. WSDL2Java: Generate the Server-side Wrapper Code and Stubs For Easy Client Access