The second installment of Richard Monson-Haefel's "Guide to Enterprise JavaBeans" has been posted on TheServerSide. This month's article provides a high-level primer on Web services, then goes on to an overview of JAX-RPC and the new EJB endpoint interface.
Read "EJB 2.1 Web Services (Part 1)" from Richard Monson-Haefel's Guide to Enterprise JavaBeans
can somebody help me sort the benefits of WebServices out?
I understand WS as a standard, where on top of the XML-standard some additional XML-based standards (SOAP,WSDL,UDDI) were defined, that helped to describe the properties/capabilities of a Webservice like methods, location etc.
Benefits I see:
- Easy creation of toolkits based on WSDL metadata for webservice (that is probably the major benefit)
- Platform and language independence (therefore high reuse potential?)
- Quite some communication overhead: If everything is a webservice and and objects are marshalled in xml-notation to be transferred over a network there must be a big performance drawback. Anybody has experience with this? Even Doug Purdy in his interview mentioned that MS encourages customers to deploy enterprise services on the same machine with the ASP.NET components (sort of like JSP,EJB in the same VM) to avoid this XML marshalling.
- Quite some xml parsing overhead: To consume a webservice both on serverside and client side the soap request and response must be parsed with some sort of xml parser.
- The very hyped reuse of WebServices ... how does this work? As already discussed in other threads, transactionality and security of WebServices are not available to this point (besides some specs), so how can I assemble an application consisting of "foreign" webservices. For purely informational apps, that'd work, but transactional (as most enterprise apps are)?
Funny to watch the evolution of programming languages and then end up with no language at all. Yay, protocols rule...
Anyways, I'm sure I misunderstood a lot and if you guys can help me, it is very much appreciated.
While I agree that there is going to be a performance overhead incurred while communicating via web services, I think you are forgetting that it was never meant to be used in the manner in which you speak. Why do you think local interfaces are pushed for components within the same process? Just because something is available doesn't mean is has to be used everywhere.
Web services are meant to integrate between different systems, across networks, etc. They aren't meant to integrate components within a single application stack. Sure, you can access them this way but you generally won't.
I agree that transacations (and security) still need to be addressed but the technology is still maturing. It will get there. Right now, you'll have to roll your own transaction management across systems but there really isn't much else out there if you want to tie together services from different platforms/languages and have built in transaction support in the communication protocol. Unless of course I'm forgetting something (it is late but still..).
Mike, I agree with you. We are actually using SOAP to have a backend MS based object communicate with a J2EE web based frontend and it works fine. This is what it was designed for, to integrate different platforms, languages and so on. Having a clean open interface also protects your investments and makes migration lateron (as technologies come and go) much easier.
Web Services are not just about performance. They allow interoperability between EVERYTHING. Performance is hardly a concern when you can finally solve EAI problems or connect trading partners. As for benefits.. I could list 10 pages worth of reasons, both technical and business-oriented. Sure, they might be slow. But if you can make an extra 500 thousand or 50 million dollars because you can add-on more services, create workflow between departments and organizations, then the performance hit isn't a big deal.
Let's first solve the problem, then we worry about how to make it work fast. People like you said the exact same things with OO. "OO is slow! I don't want that overhead". Now, all projects usually can't survive without it, that is if you know how to use it. Don't be critical about performance, you will become just as ignorant as these non-OO people were years ago.
People like you said the exact same things with OO. "OO is slow! I don't want that overhead".
What are you, an overzealot crusader for Web Services or for that matter, any new technology? There is no need to jump on Bob for things he did not say or imply. In case you failed to notice, he had asked his questions in the spirit of hoping to get good answers so that he could clear his doubts and make an informed decision. And instead of attacking him and making sweeping statements like 'I could list 10 pages of good reasons' or 'WS is for integration between EVERYTHING' (are you a manager?) spell out those good reasons, like a couple of other people have done earlier on this discussion forum.
I could list 10 pages worth of reasons, both technical and business-oriented</>
Agreed, I read about 10 as well. The heartattack of some is the boredom of others.
People like you said the exact same things with OO. "OO is slow! I don't want that overhead". </>
Actually, no, can't remember I said that.
If you wanna share some of your wisdoms maybe you can lecture a bit about the reuse-part of my question. The performance-part, I consider it answered by Mike and I guess I can live with it. Thanks.
I'm not a web service specialist but here are some examples of situations where web services would have been useful to me:
- retreiving financial data from reuters
they have exposed an http / xml based service for retrieving stories and financial data. if this was done using web services we would have had several prebuilt libraries to use to get the data
- connecting flash to j2ee
in one of our apps, we connected a flash frontend to a j2ee backend for online quizzes, flash mx and web services would have been a more elegant solution.
Here's the problem that I believe Web Services are attempting to solve:
There is no high level, highly interoperable way of exposing remote services available on the internet at the moment.
- Corba (IIOP) is just too scary
- RMI is too Java
- HTTP + XML needs more structure to it
- XML-RPC is friendlier but doesn't have the support
- Anything (other than Web Services themselves) by Microsoft is just too proprietary
I suspect that Web services are also part of Microsoft's strategy to replace the browser as the ultimate web application interface. .NET has many Web Start like features that make it easy to deploy applications over the internet. In addition, it needs the same kind of connectivity to services that a browser has. Enter web services. Now, instead of using a dumb web browser, you can use rich applications to access your bank account, shop at amazon, read you e-mail, collate your news and all using the same friendly, highly interoperable backend web services.
Fortunately for us Java developers, Java is currently the best solution for developing practically anything on the backend. Unfortunately, Java currently doesn't have a decent answer to .NET on the front-end but there is still time (and some interesting possibilities).
Jamie, thanks for the input. Agreed, WebServices are very useful for applications, that are purely "informational" like the ones you described. I did that when I had a Cajun beta for evaluation: Very easy to acess some data from e.g. a database and expose it as a WebService. But then you still need to e.g. XSLT the info you need to generate say a HTML/WML page. The page generation process in a WS application becomes more and more difficult the more WebServices you are trying to access to assemble your page. I think there are some efforts going on to make that easier (like WSUI on wsui.org).
Regarding MS, sure, their focus definitely is not the browser. They are talking about smart devices, which are smart about users, smart about web services, smart about five or six more other things. Honestly, I like and don't like this. I like it, because it is a vision. I don't like it because I still can't see how all this smartness can be implemented sooooo easily ("why code? just drop in your webservices"). And I don't like Passport either. Well, I guess that's what a a vision is - and a long way to go.
I think the whole effort of JCP guys in integrating web services into J2EE is unnecessary!
They should have waited for another 6 month or 1 year for technology and the market of web service to mature down.
When I first read article on web services I was really excited, since then my excitement has faded away a bit. Reason is there isn’t much project going in this area.
Most of the companies don’t want to invest in a technology that is still evolving.
Sun was doing a good job in realizing web service development packs, but integrating web service with J2EE is a bad idea. J2EE is a matured technology now. Sun should avoid integrating thing in J2EE that are still evolving and nobody is sure about how it will look like in the end. As bob has pointed out transactionality and security of WebServices are still not available.
They should have waited till EJB 3.0 when the picture in web service will be much more clear.
Instead JCP should have concentrated on decreasing the complexities of J2EE and EJB. Lots of people (including me) complain that J2EE is most complicated technology from Sun. One of the origin goals of Java was to keep the things simple and make it more productive for the developers. This is certainly not happening with J2EE now. The learning curve is too steep.
One more thing that I would have loved to see is integration of JDO with EJB and J2EE. When will that happen any idea..
"They should have waited for another 6 month or 1 year for technology and the market of web service to mature down."
Don't you think the itegration of web-services in its current state will gather a great feedback and help to determine the way to improve the technology and its integration with J2EE? And will make this process to flow faster?
Couple of thoughts that spring to mind.
(i) I wonder when we will see a 2.1 compliant app server in the market? BEA Weblogic 7.0 has Web Service's in it but apart from a non final JAX-RPC implementation every thing else is their own stuff.
(ii) Many people talk about the lack of tansactional support. I always considered the best approach to implementing a web service is that one call to a service equals at most one transaction. Is anyone out there making multiple calls to web services that span one transaction and if so what was their design reasoning?
Just some food for thought.
<David>Is anyone out there making multiple calls to web services that span one transaction and if so what was their design reasoning? </David>
I cannot believe there is a webservice application doing that. How long did it take to define/implement distributed 2/3-way committed transactions in relational databases? For WebServices they are just spec'd (http://www.hpmiddleware.com/SaISAPI.dll/SaServletEngine.class/products/webservices_transactions/default.jsp
Basically for each webservice transaction, you need a compensating transaction to make it able to run in a transactional context.
The standard example is the travel agency, where you book a flight, a rental car and a hotel reservation all in one transaction. I do not believe WebServices can do this reliably. But this is just my humble opinion and I'm not a WS specialist either.
"I'm not a critic. I just want to believe."
One of the real value propositions of Web Services is indeed the fact that "Everybody's doing it". Systems that can communicate through such a mechanism grow in value with the square of the number of components, per Metcalfe's law.
XML and HTTP are cheap, easy and ubiqiutous technologies and this fact is ensuring that just about everyone will be able to use Web Services to communicate.
The other major issue that remains unresolved is the granularity of Web Services. RPC is severely limited in application and applicability on the Internet. It is really at the sub-system and system levels that WS will start showing real value. Look to the REST people to drive this point homw in the next 12-18 months.
The models for this type of computing have not yet been discovered. Everyone assumes that the existing development models of the distributed component world will be the basis for Web Services, but if this is really a new paradigm, and I think it is, then we need entirely new approaches.
Look for new types of applications, new angles, new directions. This is uncharted territory.
"Everybody's doing it".
That's kind of not true. There has been a number of discussions recently on how the take up on Web Services has been slow as companies are less willing to spend money on hype. Don't get me wrong, Web Services do have their place (I have implemented several) but at the moment it is contecting distributed systems across the internet in a standard way.
"XML and HTTP are cheap"
The one thing XML/HTTP is not and that is cheap. Connection sub-systems using XML/HTTP within the same LAN is very expensive and should only be used if cheaper protocols like CORBA/RMI are not a possibility.
>> That's kind of not true
Maybe not yet in uptake, but definitely in terms of the availability of the technology, which is more what I meant. Already it seems the case that if you are going to connect disparate systems over the Internet, Web Services is the way that you will do it, regardless of the underlying platform. This is vastly different to systems like CORBA, RMI/IIOP, DCOM, .Net Remoting, Flash Remoting, etc etc.
>> The one thing XML/HTTP is not and that is cheap
Again, you are thinking in terms of old-world RPC models. There may be performance issues with XML/HTTP, but in terms of availability and ease-of-use, these technologies are incredibly cheap. The ubiquity of the web is proof enough of this. Going further, REST architectures are immensely scalable, and easy to develop.
"Maybe not yet in uptake, but definitely in terms of the availability of the technology, which is more what I meant"
I do think uptake on Web Services will be a lot slower than some people believe and vendors like IBM and Microsoft hope. Companies are using SOAP to do basic XML RPC between partners and some sub-systems where CORBA or RMI is overkill but I still have yet to see extensive use of dynamic discovery.
"Already it seems the case that if you are going to connect disparate systems over the Internet, Web Services is the way that you will do it"
Well yes that is what I have constantly been saying. SOAP is great for this kind of stuff and there are a lot of tools like AXIS, SOAP LITE and GLUE to help you connect disparate systems over the internet.
"There may be performance issues with XML/HTTP"
Well yes there are performance drawbacks with XML/HTTP. I don't know what to say to anyone who doesn't believe there isin't. Also the fact that XML/HTTP is available and easy to use doesn't mean that it is the right tool for every job.
I don't think I know anything about REST architectures so I am unable to comment about it at this late hour :-). I will take a look at some documentation tommorow.
I think Web Services r being promoted to allow Services in different platforms, different languages to take advantage of each other and work in synergy . The cumulavtive effect surpasses the performance cost incured.
I still think the one thing that is missing here is the fact that Web Services tend to work best when connecting distributed systems across the internet.
The only time I would consider it internally at the moment is when I had no choice. Maybe when I was connection a Microsoft System to a J2EE system and CORBA was just way to much of a headache and overkill.
On a side note is any one doing dynamic discovery using WSDL, UDDI or ebXML at the moment? Most things I have seen so far are just SOAP interactions. I didn't see anything in the spec with regards working with Web Servies registeries.
David, are you looking for specification? on www.uddi.org/specification.html<P>
Or do you look for registration sites like http://uddi.microsoft.com?
To lookup uddi info from a registry in Java checkout http://www.juddi.org
No thanks, I have read the specs and a couple of books. I also played with JUDDI and the IBM registry a few months ago. All very good theory.
I was just kind of interested to see if anyone was on a project where they were using the registration, dynamic discovery side of Web Services.
I went to a Sun One conference last year and their take on it was that business would adopt SOAP first, then an internal business registry and if that worked out they would expand to using a global registy.
Has anyone taken a look at the security implications of Web Services? Specifically, WS are typically touted as running over HTTP on port 80 to pass through firewalls. Port 80 w/ HTTP is typically open on firewalls because that's what people use to browse web sites, but now we're going to open up remote procedure calls using the same port / protocol, so how are we going to secure this?
There's a reason the other ports / protocols were blocked, and it's because it was not secure to pass RPC's across the firewall, or to allow applications to communicate with outside applications. Pushing everything through port 80 / HTTP and now making the endpoints potential applications, not just documents served up from a web server, seems inherently insecure, and possibly un-securable (is that a word?)
I do not think SOAP messages need to be passed using Http. They could also use e.g. Https, which would ensure at least some level of security on the transport layer.
As far as I know, instead of using the security of https, SOAP specifies its own security model. This makes SOAP abstract from the transport protocol used (http, smtp, tcp). They would need to pass trusted security tokens between SOAP client and server (like X.509 certificates) in the SOAP message.
For further security considerations, there will most likely XML encryption and signatures, bringing all the problems of PKI into WebServices. Especially when multiple parties are involved in assembling a WS, this might get rather ... difficult :|
The benefit of it is, that you can control, which SOAP requests you allow to consume your webservice (based on the security info passed).
Just want to add my $.02 to the discussion. I think Web Services are going thru' the hype phase that acommpanies any new technology. Any new technology is usually touted as the cure to all problems before it matures and ocuupies it's rightful place.
-Anyone remember OO Operating systems?(If I remember correctly, IBM-Apple were collabriting on one of them).
-What about JavaOS and Netscape's Javagator(sp?).
I think the biggest bang for the buck would be in replacing the EDI systems that are currently in place. I feel it will fit in naturally into the EAI space. It will ease some of the pain in implementing these systems , although by no means will it be a magic wand.
I am currently skeptical on WSDL and the whole automatic discovery process. It seems kind of unworkable for everything except the most trivial of tasks(Correct me if you think I am wrong, do not flame me).
Also We will have to wait and see how transactions,security shape up. The risk here is that they may end up being difficult to implement like in CORBA.
A great example of XML-RPC (Web services) in action is in the UserLand's blogging software(http://www.userland.com