Bo Larson

Thanks!

I guess the reason I didn't consider them "DAOs" is they perform such specific tasks that aren't really related to persisting data for my application. The CustomerImportThing only supports looking up a customer in the ERP system. It doesn't access any data local to my application, it just has methods like public Customer getCustomerByCustomerNumber(String customerNumber), which returns a Customer object populated with data from the ERP system...from there I can persist this object using my CustomerDAO. Likewise, the CustomerExportThingy only has operations for saving and deleting Customers from an external database.

Then the PortalService is what really threw me....but I guess I can sorta think of it as a data source. Again, however, it doesn't actually persist any data for my application.

Let's say I had some other class that would publish a customer's photograph to Flickr...would it also be considered a "DAO"?

Please be nice, I'm all alone out here and am new to many of these concepts.

I'm writing a spring MVC 2.5 application and I've got the thing organized into what I believe is a fairly standard structure. I've got DAOs over here, domain pojos over there, a service layer, and then my controllers and presentation.

Everything is working fine, but I've got these classes and I don't know where they fit....like...where do I put them? What do I call them? What "kind" of classes are they in terms of all this design pattern madness (DAOs? Services? Wha?).

1) I've got an interface that I'm currently calling CustomerImportService. Its implementation queries a local ERP database and returns Customer objects (part of my domain model) which my application can then save in its own database.

2) I've got an interface called CustomerExportService. The implementation of this thingy exports Customer objects to a remote database.

3) I've got an interface called ContactPortalService. Its implementation takes a Contact from my application and adds / updates / deletes an associated user account on an external portal server via SOAP.

All three of these classes use services of one form or another that are external to my actual application. I don't know exactly where they fit though in my project structure. They're not part of the DAO layer I wouldn't think, although the import and export classes are sorta like DAOs. They could be considered services, but they are services local to my application, not services in the sense that some higher up client will be using them. Where do they fit into my application / project structure?

(thankfully this thing is working ok...I just want to realize my application in the context of standard practices)

Thanks everyone. I read the thread that Pat linked to and I believe that my problem stems from not really having a problem. I want to use what I'm "supposed" to use, but really I'm just looking for something to help deal with two things: persistence and the UI. The in-between stuff I'd like to be as close to "just java" as possible... and this shouldn't be an issue since my projects really are small. I'm thinking too big instead of just getting to work.

I'm settling on GWT for the time being because it looks sorta fun and I like the idea of developing an application in a browser rather than a bunch of web pages and forms clobbered together and called an application. In my case I don't need web sites, I need applications that are accessible. I'll likely use Eclipselink(Toplink?) for persistence because I already have it setup so what the hey. But I swear, if there are too many instances of something not working and having no clear indication of why it's not working, I'll just use plain old JDBC.

I must say that it is nice to see published, experienced Java developers being pragmatic about frameworks instead of just recommending a favorite to everyone. I feel like I wasted a fair amount of time trying to wade through all of these frameworks and whatnot only to realize that most of them weren't for me because they don't solve a problem I'm currently having. It's hard not to run with the herd and it's good to hear someone in-the-know say "you don't really need all that stuff right now." This is a good forum.

Well it's nice to have someone actually confirm that for me. I went through a couple JSF tutorials and really just felt like it wasn't something I wanted to do.

I noticed your links and looked at your Front Man framework. It might be the simplicity I'm looking for.

However, I think I'm going to give GWT another go... but this time do it within the narrow margins they provide. The idea of writing a web application in much the same way that I'd write a traditional GUI is very appealing. I do really want to use JPA with it, because I don't want to write DAOs by hand. I know there are some technical details that make this challenging.

Thank you.

I'm not so sure about JSF -- I certainly don't like the markup and frankly it just feels like there's a lot of code and meta junk to generate just to perform a relatively simple operation. Not to mention that there is still a lot of reliance on naming convention and string parsing for flow, etc, for which the tools I'm currently using don't help much with.

The hard thing here is that learning JSF requires a pretty good amount of time and effort that, in my case, might be wasted if there is something simpler for building the UI. Yet I'm also wasting time by trying out simpler tools like GWT that turn out to complicate the back end.

I worry that I'll put a lot of effort into JSF only to reach a point where I'm efficient with a technology that is a chore to work with. Back to square one in a way. Thoughts?

So I've been playing around with Java web development thinking that it would somehow save me from the hell of PHP. Unfortunately, things on the Java side seem to have become a giant mucky swamp of technologies and frameworks and containers and whatever else.

I've looked into things like JSF, Spring, GWT, and about a half dozen other projects and haven't found one yet that feels like it'll get out of my way and let me work on what I want to work on. Google Web Toolkit thus far has been very interesting and I love the feature set and overall simplicity, but the proprietary (perhaps not the right word) back end is driving me nuts. That is, trying to make it work on Glassfish in hosted mode is a mess, and getting it to play nicely across multiple projects isn't fun.

Basically all I've got is some simple databases and I'm doing some relatively basic CRUD operations in a corporate environment. This stuff won't be facing the public internet. I would, however, like to provide a UI that is modern and provides a good user experience. I would prefer to work with something that has good Eclipse support, but Netbeans is doable. I prefer not to spend a whole lot of time writing XML files and or having to rely on naming conventions to make sure the code will run. (I'm definately one of those guys who needs his tools to help him remember what the hell he's doing.) I would also like some automation for database operations - that is, some kind of persistence and entity generation tools etc.

Right now I've got some headless EJBs (3.0) running in Glassfish, but frankly I could probably start over. (JPA can be used without a J2EE container, right?) I'm a little more comfortable with Tomcat 5.5, actually.

So there it is, can somebody recommend a pathway to developing simple, maintainable applications?

Sorry if this is the wrong forum.

Thank you again so much for your help. I just checked and the book you mentioned is up on Safari so I'll be able to take a look at it soon (Safari is the best).

BTW, I ended up using BIRT. The API is a bit overboard in that you have to create umpteen objects and call a dozen methods just to get it going, but I do have a hacked-together Liferay portlet that is showing BIRT reports. I was able to accomplish in less than eight hours what I had been struggling with for a week or two. And it's nice to be able to visually design reports instead of coding up JSPs. I guess I was just a little overexcited about these concepts that are new to me and wasn't concentrating on finding the simplest solution to the problem. I've read so many articles and have listened to so many podcasts buzzing about SOA and web services that I tried diving in without thinking it through. I really appreciate you taking the time to help me think about how I can appropriately use these technologies when the time arises (and it will, soon).

Thanks! You've been very helpful.

When I mentioned a remote client getting an "inventory report", I didn't mean human being with a web browser, I meant a remote application. Using the word "report" was not appropriate.

I think I'm coming around to what you've told me here; it's starting to make pretty good sense.

Here's a question, though: how do I expose the ERP system via web services without losing the features of the database? I could end up with a thousand little simple queries that essentially just grab table records and then I have to do the "joining" logic manually, or I could end up writing a new function for every specific complex query that I want to perform against the db.

The most reasonable solution almost seems like it would be best to have just one "query" function that takes an SQL query, runs it on the database, and returns some arbitrary table structure. This could prove difficult to secure though.

Ok, so then I have to think: what is the point of using a web service if I just need a database connection? I don't have to go through a bunch of firewalls, and I'm in control of the ones I do, so using HTTP isn't much of a benefit.

And then I need to think about the fact that at this time the database is read-only. I can't put data into the ERP reliably without purchasing special modules from the vendor, and at this time I don't really need to put information in...i just need information out.

The only part of this whole thing that is really interactive is an integration database that I use to map user accounts in a portal to customer numbers in the ERP. Even then, I don't need a web service - I just need a web application that can hit that database. Would you agree?

What I need is a reporting tool and a database connection. I think I've been wasting my time with this web services business. I think maybe I just need BIRT or something similar (simpler?).

I see. I was envisioning the "web service" as being too high up, when it should have been down at what is currently my DAO layer. So basically the web service in this case is just a way of retrieving data to be used by the application.

I'm going to have to let that sink in a little bit.

When is it appropriate to expose higher level constructs as web services? What if I wanted to offer an "Inventory Report" service to be used by remote customers. Would I end up with a web service that ultimately uses another web service for its data source? Won't it almost always end up that way?

Take this scenario:

* I point my browser to a URL inside my local network, and the service residing at that URL generates a nice inventory report and sends it back to my browser.

Solution 1:
I have to have some kind of client application running on that URL, and the client application would understand business objects like inventory reports, and it would ultimately end up calling a web service to retrieve data from the ERP to populate the business objects.

Ok, so what's the benefit of that over:

Solution 2:
I have a dumb client running at the URL that only knows how to display specific data. It retrieves the data by calling a web service. The web service knows all about business objects and sends the appropriate data to the client.

In solution 2, if my business logic changes I don't necessarily have to physically update any of the clients. In solution 1, if I wanted to change some business logic then I would have to physically make sure to update every single client. The only way around that would be to have an intermediate web service that would do the business logic, but then it's more like Solution 2 with a web service for the data layer.

Thank you again for your reply!

You said in #2 that "you also have business objects that create the data objects with data extracted from the ERP", but then in #3 you said "the business objects extract the data from the ERP using 'web services'".

The term "business objects" is confusing me here. There seems to be a contradiction since in #2 I'm reading that the business objects are analagous to data access objects that retreive local data, and in #3 I'm reading that business objects retrieve data from the ERP using web services.

I'm stuck on the part underneath the web service and am not concerned yet about consuming web services.

Are you suggesting that I have two web service layers? One that exposes data in a dumb fashion, and another that consumes the data and then exposes it in a useable way?

I'm sorry if I'm a little bit dense here... maybe if I diagram how I envision it working...

Example:

Human Being -> Client Program (returns view) -> ****WEB**** -> Web Service (returns data transfer objects) -> Inventory Service (returns inventory-specific data objects) -> Data Layer (returns lots of data objects) -> Local Database.

Thank you very much for your detailed reply. I've reviewed it several times.

In the first paragraph of my first post I did mention that my questions might not have anything to do with web services specifically. I guess the only reason that I brought up web services is that the book I happen to be reading uses web services as the basis for its entire implementation from the ground up. And ultimately in my current scope a web service is what I'm after.

So if we completely toss out the idea of a web service, then, I believe that my questions still apply... but maybe I have to rethink them. Here's a try based on your reply:

1)I have an object model that represents the data that I�m working with.
2)I have a data layer that populates the object model from the ERP system.
3)I have a mysterious �service� layer that delegates calls to the data layer. The book I�m referring to calls this service layer a �fa�ade�, and claims that it isolates the data layer from the application? (I think)

Number 3 is one area where I�m confused. First, I thought that a fa�ade presented a simplified set of methods to work with a finer grained layer below it. If this �fa�ade� I�ve got just delegates calls to the data layer, then what is it and what is its benefit?

For example, to work with my model, the code looks something like this:

InventoryFacade fa�ade = MyInventoryFacade.getInventoryFacade(); inventoryItems = facade.getInventoryItems(null);

And the guts of �MyInventoryFacade� look something like this:

private static InventoryFacade facade = null; public static InventoryFacade getInventoryFacade() { if (facade == null) { init(); } return facade; } private static void init() { InventoryFacade facadeImpl = new InventoryFacadeImpl(); InventoryDAO = InventoryJdbcDAOImpl.getInventoryDAO(); ((InventoryFacadeImpl) facadeImpl).setInventoryDAO(dao); facade = facadeImpl; }

So given that, it seems to me that this facade is simple a mechanism to isolate the data layer. Its implementation delegates calls to its DAO on a one-to-one basis, currently. Does that seem correct?

So basically once I've got that (which I do), I implement a web service that uses this model. Where then does your "component" level fit in?

And what comprises a service? Take my case where I need to expose different subsets of my inventory to two different groups. Do I write two web services, one for public consumption and one for internal consumption? They would share some functionality which confuses me... like populating DTOs and retreiving certain pieces of information like when the last time the inventory was updated (our ERP system has a horrible ODBC driver so I wrote some code to recreate and sync portions of it in an external database on a schedule...I run my queries then against the replica).

Perhaps I'm missing something here because I'm using a tool to do some of the work for me. In Eclipse I just choose a class in my "service", which is the "thing" above the model that I'm referring to as a web service, and choose "Create Web Service"...then it does some junk to actually implement the "web service" part of the "web service".

Is the "thing" I'm calling "web service" the missing component level?

I've been following a book that is essentially a tutorial on designing web services, and have been applying it to a specific problem that I need to solve. My question(s) isn't specifically about web services I suppose, just design in general.

The simplified problem is this: I need to expose a product inventory from our ERP system. I'll need two views of this data - one which will be a full inventory list for internal use, and another which will be a subset of inventory items appropriate for public consumption. Ultimately I'm exposing everything via web services.

I've got the technical details out of the way. That is, I've got the data, have some test cases, and even have a little Liferay portlet that shows the public inventory. I'm having a hard time with the design itself though, especially considering that I know this project will increase in magnitude.

So the book had me create a model consisting of classes that are essentially data structures representing my business objects. So I've got InventoryItem, InventoryItemPriceSchedule, and stuff like that. I populate these things via a data access object, so I've got an InventoryDAO interface and an InventoryJdbcDAOImpl concrete class that uses JDBC to pull from my data source.

Now the part(s) where I'm getting confused. The book had me create a "service" package in my project...the word "service" seems to have many meanings... the service interface defines a facade that essentially delegates requests to the DAO interface. The book is calling it a facade here, and I'm not sure if it is. Basically the code looks something like this:

class InventoryFacadeImpl implements InventoryFacade { private InventoryDAO inventoryDAO; public void setInventoryDAO(InventoryDAO inventoryDAO) { this.inventoryDAO = inventoryDAO; } public List<InventoryItem> getInventoryItems() { return inventoryDAO.getInventoryItems(); }

Ok... so I understand how this thing isolates the data layer, but is it a facade if it's just delegating requests to the data layer? The problem with books and tutorials is that they're over simplified. What should this service object...thing... be doing? Should it map requests to the DAO on a one-to-one basis? That seems a little bit silly since I could just not call the InventoryDAO a DAO and just use its interface and skip this layer of abstraction.

I think that the reason the book chose this method might be that there can be multiple implementations of the service... so I might have a facade that uses my Jdbc DAO, and another that uses some other type of data access. (in other words, I have an implementation class that creates the InventoryFacade concrete class and gives it a reference to my DAO concrete class, and returns a new InventoryFacade interface) But I can't imagine why that would ever be necessary in this case.

Finally the book had me create a whole new project which I believe represents my "web service". It calls my InventoryFacade to populate data transfer objects. I generate my web clients from classes in this project.

So here comes the matter of my public vs. internal inventory. In my actual DAO object my method to retrieve items takes an optional list of item numbers to retrieve. Through this mechanism I can specify to only retrieve "public" item numbers, or retrieve all item numbers. Good. But then where do I implement the logic to "only retrieve public items" or "retrieve all items"?

Do I create methods in my InventoryFacade like getEntireInventory() and getPublicInventory()? That would require logic there and I'm not sure if there should be any. Besides, what happens when I want to getSomeOtherSubsetOfInventory()?

So I'm thinking that this logic should go up in the web service itself. Yeah? Nah? What if my list of public inventory items is in the database itself...I would then have to add a method to my facade to getPublicItemNumbers()...which then causes the same problem I mention in my last paragraph: what happens when I want to getSomeOtherItemNumbers()?

And in regards to the web service, the DTOs I'm creating apply to both my public and private web services. How / where do I share them?

I don't think I'm making much sense. I'm holed up in details here even though I've got the functionality working. I just want to figure out how to do this right. I've been away from development for far too long.

Please, any advice would be much appreciated.

Figured it out. My J2EE module dependencies were wiped out which initiated this whole mess.

Hi, I don't have much experience with Eclipse or WTP. A while back I downloaded the complete J2EE Eclipse package and have been running it successfully. I'm using a clean Tomcat 5.5.

I've been writing a web service that until yesterday was working just fine from Eclipse. That is, I created a web service via Eclipse WTP and could run it from Web Services Explorer. I also generated a client and was able to run it as well. No problems. Then I decided to rename my projects and everything went south.

My workspace has two projects in it. One is a Utility project that contains my model and a service facade. The other is a Dynamic Web Project that uses the facade from the Utility project. After renaming the projects, I now receive a NoClassDefFoundError and ClassNotFoundException for the facade class when I try to invoke the web service in Web Services Explorer or from my generated test clients.

All of my unit tests for both projects are fine.

I have tried the following (extreme) measures:

1) I completely removed Eclipse and Tomcat and unzipped fresh copies in fresh folders. In fact, I used Eclipse to install Tomcat.

2) I created a brand new workspace for the new Eclipse install.

3) I recreated my Utility and Dynamic Web projects and imported the source folders from the projects in the old workspace.

4) I regenerated the web service and clients.

Still no luck.

In brief, when I invoke my web service I'm getting an exception that my facade class in a separate project is not found. When I run unit tests on the class from which the web service was generated they all pass. Something must be hosed with the way that the service is being published to Tomcat... something that would persist through a reinstall of both Eclipse and Tomcat? Hmmm.