Hi Helcio, Web services are extremely important because nearly everyone uses them. There are two approaches to web services, SOAP-based WS-*, and REST. Both are important, but if I were teaching the subject, I would focus on REST because 1), you don't use IDEs to auto-generate everything, 2) you use web standards that every developer should understand, 3) there are real design considerations involved when designing your service, 4) there are great examples in-the-wild that your students could study. I strongly recommend "RESTful Web Services" by Richardson and Ruby, if you are interested.
I think you might be doing a disservice if you ignore JMS. As I see it, there are really Three important areas: 1) Low-level protocols (UDP, TCP, Multicast, etc) 2) Synchronous RPC (RMI, Web Services) 3) Asynchronous messaging (JMS, etc) These divisions aren't clean. For example RESTafarians would be outraged that RESTful web services are categorized under RPC. I suppose you could have a fourth category for web-style applications that would include REST, but not WS-*. At any rate, these seem useful ways to organize a discussion of network middleware for discussion. Sean On Thu, Apr 19, 2012 at 11:15 AM, helcio silva <[email protected]> wrote: > Hi, Dan. > > Some years ago, when I was a PhD student, I had a graduate course > related to design of distributed systems. On that course, we used > technologies like sockets, Sun's RPC (in C) and CORBA (in C++). Those > were the most popular technologies of that time (there was not web > service yet). > > I would like my students learn how to design distributed systems > using some modern technologies. But, I must to confess, I am not an > huge fan of IDEs or too complicated frameworks. We have an > undergraduate course about programming for Web using Java frameworks > that is aimed to provide such frameworks. > > Helcio. > > Em 19 de abril de 2012 05:14, Dan Creswell <[email protected]> escreveu: >> Cool, so you know what? >> >> I'd be very tempted to suggest you replace step 3 with some more raw-http >> like thing (I hesitate to say RESTful because that's poorly understood and >> not entirely meaningful/useful). >> >> That sort of thing can be done with any of the straightforward webservers >> e.g. Jetty. >> >> Such a choice also allows you to branch out into Web APIs and the like >> which are pretty relevant today in many environments. >> >> You could go further and then build the JINI version which embodies some >> similar patterns plus moveable code etc (interesting contrast with the web >> "standard" for moveable code, JavaScript). >> >> However, there is one big question I think maybe we should answer first >> which is: >> >> What do you want your students to walk away with? >> >> On 19 April 2012 05:27, helcio silva <[email protected]> wrote: >> >>> Hi to everybody. >>> >>> Currently, I am teaching a undergraduate course on distributed >>> systems built using Java. I am structuring that course of the >>> following manner: >>> >>> * first part: I present a centralized application, and I separate >>> it on two components - server and client. Both communicate using the >>> sockets API. >>> >>> * second part: I distribute that application using Java RMI. There >>> are three components now: server, client and registry (rmiregistry). >>> >>> * third part: I wanna distribute the application using Web >>> Services. However, this technology seemingly requires the use of Java >>> EE, and I don't want to use nothing more than Java SE. In effect, I >>> write my programs in emacs, compile them using the 'javac' compiler >>> and run them using the 'java' interpreter on a Linux shell. I really >>> think Web Services is boring. In fact, I don't know how important is >>> Web Services in the distributed systems world. >>> >>> I am considering to replace Web Services by River on third part, >>> mainly because I have some experience on that technology. What do you >>> think about that, gentlemen? Will be my students prejudiced? >>> >>> PS: sorry by post my issue on this list. >>> >>> Best regards to all. >>> >>> Helcio. >>>
