I have just started my web services certifications and using Monson Hafel book for my exam. I have just completed XML Schema, WSDL, SOAP, (SKIPPED UDDI) and started JAX-RPC section. I have some very very basic doubts. Please forgive if it's very dump quesion. I want to expose something as services. For eaxmple 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. Am I right?So i will registry this service in UDDI so that users can use this service. How can a user(both java/non-java client) will access this service? What is purpose of Java2WSDL and WSDL2Java?Where it will be used? Which one will be created first WSDL or Java? What is role of SOAP?
I know that it's very bacis questions and I have to learn a lot.But I want to visuliaize how all WSDL,SOAP and Java works together? 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?
SCJP 1.4 (86%), SCWCD 1.4 (86%), SCBCD 1.3 (85%), SCDJWS (Just Started...) - Satisfaction Lies in Our EFFORT, Not in the ATTAINMENT
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.
You mentioned servlets and EJBs can be published as web service. But I think, any java class (talking only about java) can be published as web service even bean classes, tags or anything... isn't true?
You mentioned servlets and EJBs can be published as web service. But I think, any java class (talking only about java) can be published as web service
Peer was answering Michael's question (which was not about Java classes, but about ways to publish WS). Any Java class can be published as a WS, provided it meets the requirements set out by the API it uses, and the server it's running on. E.g., using the JAX-WS API nothing more is required than an @WebService annotation in a class to publish its public methods.
Joined: Aug 19, 2005
Originally posted by ankur rathi: You mentioned servlets and EJBs can be published as web service.
To rephrase what Ulf has already stated:
"Java classes and EJBs can be published as web service - however either of them will require a web server (of some description) to publish them".
Servlets are not published as web services. Servlet technology is usually used to realize web services that are based on Java classes.
And technically you are publishing the methods on the java class - not the class itself.
All the IDE wizards and web service magic pixie dust try to make things look so easy but the truth is that SOAP web services use the HTTP protocol to transport SOAP envelopes that can only contain XML - and there are all sorts of things that can go wrong. HTTP clients can only contact HTTP servers not the other way around; the HTTP Server may be down when the request is made; HTTP may travel over proxies and firewalls so a request may travel one way but not in reverse; XML is hierarchical, not object-oriented; etc.
This all happened before with EJB when they tried to "abstract away the relational database". Well, the solution was heavy-weight, still not object-oriented, and the abstraction leaked (EJB QL looks like SQL which is relational in nature). It wasn't until Hibernate treated the relational database for what it was that things started to improve.
The same is happening to Java Web Services. The vendors are trying to make web services look like Java - but web services are nothing like Java. And if you (developers in general) keep treating web services as Java then you are going to eventually run into trouble. When you run into trouble with web services you better have an understanding of HTTP, XML, XML Schema (, WSDL and SOAP for SOAP web services) - otherwise you will get completely stuck in tar every time the Java abstraction leaks.
Whenever somebody states "Java classes can be published as a web service" I start to cringe - I think somebody who states: "I'm implementing a service in Java which will be accessible over HTTP through the exchange of SOAP messages as described by a published WSDL document" has a much better chance of success.
I don't think that you can be successful with web services if you are only comfortable in the confines of your favorite IDE/Language/Paradigm. You need to be a Generalizing Specialist with this kind of technology.