Loosely Coupled

When developing Java RPC-style web services, I'm torn whether to follow a top-down or bottom-up approach. Using the bottom-up approach, you create your Java classes first and use the @ WebService and @ WebMethod annotations to specify that this is your web service interface. The WSDL for the service is generated automatically during the build (pretty nice). This approach has it's advantages in that you never have to leave Java to create the WSDL. Creating a WSDL file is not trivial and using this approach means you never need to think about the WSDL's <service> , <binding> , or <portType> elements and how they're linked together. Conversely, a top-down approach means you create your WSDL first, then use a utility (either your IDE or a command line program) to generate the Java skeleton. Using this approach you need modify the generated Java stubs to call your business logic. If the interface (the WSDL) changes, you'll need to regenerate t...

Again and again the topic comes up at work about fine vs. coarse grained web services. Is anyone else talking about this? I guess I don't understand what the big debate is about. I think of a fine grained service as implementing a very specific, atomic operation. Course grained services implement larger, multistep operations... possibly consuming other services. The way I look at it is this: a business has some piece of functionality it wants to make available for others to use (the service). It shouldn't matter if the steps performed by the service can be broken into smaller components. If no one can use these intermediate (finer-grained) components, the energy spent defining, building, and maintaining this (unused) functionality is wasted. My position is that it's better to wait. Should the need to reuse some of the functionality arise, then refactor the common functionality into a smaller, reusable service. Am I thinking about this wrong? What am I missing?

I'm back at JCAPS training this week. This time the focus is on the eInsight Business Process Manager . eInsight is the JCAPS architecture layer used to combine web services. The services are connected using BPEL which is an XML-based language to define business processes. The latest version of NetBeans also includes a BPEL tool, and I'm anxious to see how they compare. We have some time scheduled at the end of the formal training to explore some of the JCAPS problems we've been experiencing. In addition to the problems I've already outlined with the repository . I'm hoping we can also explore the following: Lately, we've seen some weird behavior where things that were previously working stopped. The errors in the logs don't seem to make any sense. At first we thought it might be due to some code that was copied to a different location, but I've seen this problem where no code was copied. The only remedy we've found is to recreate both the...

In my last post, I described I was implementing a SOAP web service controller between my Ruby chat bot and a CORBA component my company is developing. The WDSL for this service was straightforward, and with help from the Eclipse Web Service wizard, it was complete in no time. I had some downtime before the CORBA module I needed to connect with was complete, so I began to look into re-implementing my controller as a REST web service. A little digging led me to Restlet . Restlet is a lightweight framework for developing REST web services in Java. I've seldom had an easier time integrating a new Java package and getting something up and running. Restlet comes bundled with it's own HTTP server, but I opted to deploy a WAR file to our existing Tomcat installation. There are three basic steps needed to get this to work. Creating a Resource is the first step. The Resource is the brains of your service. It captures request parameters (from the URL or encoded in the body), the...

I've spent a lot of time away from the office lately and haven't had much of a chance to post. Here's a quick update on what I've been thinking about. First off, the Ruby XMPP-bot I had started is complete. This was insanely easy to implement in Ruby. The only snag I ran into was in creating a new chat room with the bot. The 0.3.1 release of XMPP4R seems to hang when creating a new room. After some research , it was apparent that others experienced this problem and had already submitted a patch. Cool. My next job is to connect the bot to an application my company developed. Communication to this module has been done previously using CORBA. Unfortunately (or not), I have not been able to find an acceptable Ruby CORBA module ( Rinn looks like it's dead and R2CORBA does not appear mature enough). Recently many of our legacy CORBA API's have been replaced with Web Service API's and I'm going to take this approach with this module. While researchi...

I'm still struggling with the decision to create a REST or traditional web service. Over the weekend I started reading RESTful Web Services and I'm now thinking that a RESTful approach is very doable. Here are my thoughts: REST resources are inherently stateless and shareable. All the information needed to reconstruct the view of a resource exists in the URI. Although I listed this a a "pro" before reading the book, I'm more convinced of the benefits now. I had a concern about long query criteria in the URI, but I'm thinking of adopting the Ruby-like approach of referring to ids. The RESTful authors prefer a more human readable URI (as it is self documenting), but many of my filter criteria cannot be accessed through unique strings. I believe I was trying to do too much at the beginning (not keeping it simple). My object relationships are complex, with most objects linked to several related (non-subordinate) lists of objects. I wanted to have a sin...

Now that the models are complete, I want to expose access to them as a web service. I'm thinking REST is the way to go. A RESTful approach seems simple. It appears to solve pesky "back button" problems and session timeout issues, but I have one big question: How to fit all the information I need into the URL? The application I'm working on has A LOT of data. The main objective of the application is to allow filtering of this data down to a useful, manageable set. It wouldn't be uncommon for a user to ask for something like: Give me everything connected to Item1, Item2 and Item3, Hide anything that has to do with Item4 or Item5 In addition, give me anything that mentions Items 6, 7, or 8 and is new to the system in the past month. To put all this information in the URL is a scary proposition. In it's previous life as a Java web application, all this search criteria was built incrementally and stored in a user's session. Since the client ...

All my models are implemented in Rails and I wanted to give a quick update on how things are going. For now, I'm been using the rails views and controllers to test my code (automated tests coming soon). This has worked out great for me. Since my application only allows users to view and filter database records, I don't have a lot of validation checks, but I wanted to get a feel for the performance of pages need to display a lot of data from various tables. One page I tested performs 35 queries (including all the counts and show field commands) and takes about 5 seconds using the Webrick server (from NetBeans so I believe JRuby is being used). The development log lists the time spent in the database as less than 1 second. I'm sure performance could be better, but this is a big improvement over what we had before and the database I'm using contains more records. I'm still noticing that when you ":include" more than one model in a "find" comman...

I'm a big fan of Web Services and Service Oriented Architectures (SOA). I've developed a handful of web services for my company to use internally and there are a few reasons I enjoy working with this technology. Ease What I think I like best, is how easy it is to create a web service. I use Eclipse and this IDE provides a web service wizard (I'm sure other tools have something similar). All you need to do is create the WSDL and most of the heavy lifting is done for you (opening and closing connections, serializing the object to the wire, etc). Hook the generated code into your business objects and it's ready to go. Since Web Services use HTTP, installing your WAR file on the web server is the final step. No other setup is needed. I did not find CORBA as easy to use. In CORBA, you need to communicate what ports you want to use, optionally set up a CORBA name service, etc. If there was a port conflict on one of the machines you were using, you needed to ...