bean类：是一些实体类，包括viewbean,databean等等。
action类：可作为接收显示层的数据，连接显示层和业务逻辑实现层的控制层。
model类：MVC中model层就是到层。在java中无特殊含义就是模块。
util类：工具类
dao:数据库操作类。对数据库进行曾删改查等操作
bean 就是基本的JavaBean ,多为实体
action类 是 操作方法，对于页面Form 表单的操作方法，具体操作方法的实现就在Action 类里面。
model类 是模块，这个不清楚你提的是哪一块，是想问MVC 中的M，还是某段代码中的model.
util类，多为工具类，不知道这里你问的JDK中的Util类，还是一般通常程序员自己写Util类？
JDK中util的基本都是容器、集合相关的类。
至于dao ,就是数据库操作类，对于数据库的增删改查的操作都在这里。
首先这是现在最基本的分层方式，结合了SSH架构。modle层就是对应的数据库表的实体类。Dao层是使用了Hibernate连接数据库、操作数据库（增删改查）。Service层：引用对应的Dao数据库操作，在这里可以编写自己需要的代码（比如简单的判断）。Action层：引用对应的Service层，在这里结合Struts的配置文件，跳转到指定的页面，当然也能接受页面传递的请求数据，也可以做些计算处理。以上的Hibernate，Struts，都需要注入到Spring的配置文件中，Spring把这些联系起来，成为一个整体。
首先解释面上意思，service是业务层，dao是数据访问层。
呵呵，这个问题我曾经也有过，记得以前刚学编程的时候，都是在service里直接调用dao，service里面就new一个dao类对象，调用，其他有意义的事没做，也不明白有这个有什么用，参加工作久了以后就会知道，业务才是工作中的重中之重。
我们都知道，标准主流现在的编程方式都是采用MVC综合设计模式，MVC本身不属于设计模式的一种，它描述的是一种结构，最终目的达到解耦，解耦说的意思是你更改某一层代码，不会影响我其他层代码，如果你会像spring这样的框架，你会了解面向接口编程，表示层调用控制层，控制层调用业务层，业务层调用数据访问层。初期也许都是new对象去调用下一层，比如你在业务层new一个DAO类的对象，调用DAO类方法访问数据库，这样写是不对的，因为在业务层中是不应该含有具体对象，最多只能有引用，如果有具体对象存在，就耦合了。当那个对象不存在，我还要修改业务的代码，这不符合逻辑。好比主板上内存坏了，我换内存，没必要连主板一起换。我不用知道内存是哪家生产，不用知道多大容量，只要是内存都可以插上这个接口使用。这就是MVC的意义。
接下来说你感觉service的意义，其实因为你现在做东西分层次不是那么严格，在一个你们做东西业务本身也少，举个最简单的例子，你做一个分页的功能，数据1000条，你20条在一个页，你可以把这个功能写成工具类封装起来，然后在业务层里调用这个封装的方法，这才是业务里真正干得事，只要没访问数据库的，都要在业务里写。
再有不明白的追问，这是经验问题，呵呵，其实以后你就会懂。只是刚开始写的代码都是有个请求，我就去数据库取，业务几乎没有。
Dao主要做数据库的交互工作
Modle 是模型 存放你的实体类
Service 做相应的业务逻辑处理
Action是一个控制器
action 主要是struts2，用来进行跳转的，比如jsp页面提交表单就是进入到action action在调用service的里面的逻辑，最后返回到客户端jsp页面响应请求。
dao 就是用来存放对数据库的操作的方法 没有逻辑 就是增删改查
model 就是java bean 或者pojo用来存放实体对象
service 是用来进行业务逻辑的，比如从action进到service 进行了哪些操作都在这里
util 是工具包 用来存放一些工具类 比如日期转换等
jre jdk 的配置文件
referenced Library和webappLibrary 存放jar文件
webroot 存放一下jsp或者jscss等前端显示文件还有其他的配置文件web.xml等
最近又在看
在java1996年发布,当年12月即发布了java bean1.00-A,有什么用呢?通过统一的规范可以设置对象的值(get,set方法),这是最初的java bean;
在实际企业开发中,需要实现事务,安全,分布式,javabean就不好用了.sun公司就开始往上面堆功能,这里java bean就复杂为EJB;
EJB功能强大,但是太重了.此时出现DI(依赖注入),AOP(面向切面)技术,通过简单的java bean也能完成EJB的事情,这里的java bean简化为POJO;
Spring诞生了.
----------这里是分隔线 2016年03月13日更新------
随着自己参与项目积累的增加,又接触几种,这里补充一些.
· PO(plain object):用于持久化时(例如保存到数据库或者缓存);
· VO(value object):用于前端展示使用(例如放置到JSP中解析或者给前端传递数据)
· DTO(data transfer object):用于接口互相调用返回,数据传输(例如很多接口调用返回值或消息队列内容);
这里规范有一个小坑:属性名ICar是合法的,但iCar是非法的..有一个要求(属性前两个字母大小写必须一致)主要是get和set方法无法区分.上面两个属性set方法都是SetICar()
在Struts + Spring + Hibernate的系统中，
对象的调用流程是：JSP—Action—Service—DAO—Hibernate。
数据的流向是：ActionFormBean接受用户的数据，Action将数据从ActionFormBean中取出，封装成VO或PO，再调用业务层的Bean类，完成各种业务处理后再Forward。而业务层Bean收到这个PO对象之后，会调用DAO接口方法，进行持久化操作。
从Stack Overflow看到的答案，我觉得应该能完美回答你:
主要区分三个：JavaBean，EJB，POJO。
JavaBean
JavaBean是公共Java类，但是为了编辑工具识别，需要满足至少三个条件：
1.有一个public默认构造器（例如无参构造器,）
2.属性使用public 的get，set方法访问，也就是说设置成private，同时get，set方法与属性名的大小也需要对应。例如属性name，get方法就要写成，public String getName(){},N大写。
3.需要序列化。这个是框架，工具跨平台反映状态必须的
最近看
EJB
在企业开发中，需要可伸缩的性能和事务、安全机制，这样能保证企业系统平滑发展，而不是发展到一种规模重新更换一套软件系统。 然后有提高了协议要求，就出现了Enterprise Bean。
EJB在javabean基础上又提了一些要求，当然更复杂了。
POJO
有个叫Josh MacKenzie人觉得，EJB太复杂了，完全没必要每次都用，所以发明了个POJO，POJO是普通的javabean，什么是普通，就是和EJB对应的。
总之，区别就是，你先判断是否满足javabean的条件，然后如果再实现一些要求，满足EJB条件就是EJB，否则就是POJO。
SSH框架的优点：
Hibernate的最大好处就是根据数据库的表，反向生成实体类，并且还有关系在里面，还有就是它对数据的操作也很方便；
Spring，省去了在类里面new对象的过程，把这个调用与被调用的关系直接展示到了配置文件里，做任何操作都变得简单了。
简单流程举例说明：
程序框架搭建好，并且把各种jar包导入后，就开始进行业务逻辑分析——
假设一个最基本的注册功能：页面有两个文本框，一个用户名(username)和一个密码(password)。以QQ注册网页说明，这里以昵称和密码为代表进行举例。
首先是action层：它是负责在页面和程序之间传输数据的，还有作用是做页面跳转。页面由用户填写表单数据，点击提交按钮，页面的表单数据由Hibernate自动封装到该页面表单所对应的ActionFrom（ActionFrom跟实体类不是一个东西，ActionFrom是页面有什么值，类里就写什么属性，是用来封装表单数据用的；而实体类是完全按照数据库的字段生成的，实体类可以当做ActionFrom用，但ActionFrom绝对不可以当做实体类用），这样表单数据就以ActionFrom对象的形式在Action的点击“提交按钮”执行的那个方法里存在了。这个时候需要做的就是把表单数据存入数据库中。此时，Action的功能告一段落，接着是把数据传入BIZ层。
BIZE层（业务逻辑层）：负责的是对数据的处理。如果没有数据处理任务的话，此层只做单纯的数据传递作用，而后又到了DAO层。
DAO层（数据库操作层）：负责对数据向数据库增删改查的操作。
在该注册的框架中，如果不使用Spring的话，每个层之间的数据传递都需要new一个调用该层数据的类的实例。而使用了Spring的话，需要做的就是把DAO层和BIZ层的每个类都写一个接口类，接口类里写实现类的方法，在调用的时候不new对象，直接用对象点(.)方法就可以，别忘了对每个对象加上set/get方法。
DAO,Service, Action职能划分
DAO的设计和使用与Service, Action等层次是密不可分的，因此在讨论这个问题时，我们是不是应该讨论清楚3者间的职能划分。
我见过有人这样设计和使用过：
一、Action, Service, DAO皆有，Service与DAO里的方法一一对应，大部分的逻辑处理都在DAO里面完成（许多的SQL语句），而Service则是一行调用DAO对应方法的代码。
二、觉得DAO多余，就把DAO和Service合并了（以前我就这么干过）
三、条件多点的查询，查询条件（HQL, 或SQL）从页面或Action传过来
四、Action直接调用DAO
五、一个复合的业务操作（需要由多个步骤完成），都在一个DAO中实现了
六、数据库事务放Action, Service, DAO（放哪里的都有）
总之没能合理划分3者职责的情况非常普遍，这个问题是Action, Service, DAO职能划分的问题，主要也是Service, 与DAO的职能划分。
我是这么认为的：
Service的语义是业务上的，存在于Service中的方法应该是如：
创建用户账号，
增加账户余额，
用户操作违规扣除积分，
。。。
DAO中的语义则是针对数据库的，存在于其中的方法就应该说成：
创建user记录
更新account表中balance的值
更新user_score中score的值
加载user实体
加载account实体
加载user_score实体
。。。
以上的DAO方法都应是最简单的，一般都可以通过一条“简单”的SQL语句完成，如果SQL语句很复杂可能有2种情况：1）业务确实复杂，通常是查询；2）DAO方法的职责不是单一的。我们应该尽量实现单一功能的DAO方法，尽量让SQL语句简单。
Service中的内容应该是复合的，简单的CRUD那也没什么说的，想怎么就怎么吧。
逻辑稍微复杂点的功能都是可以划分成步骤的，比如对增加账户余额的功能，对应service中的方法可以是这样的
1）加载用户实体
2）用户存在，然后找到账户实体
3）验证账户余额，
4）增加或减少账户余额
上面4个方法都对应着DAO中的一个方法。
通常的业务性操作都是可以总结出这样的方法的，但也不排除一些特有操作，这个操作很不通用，就是在某一个地方使用的，根本没法复用。这可能是由于业务研究不透彻，设计不明确照成的，这很正常，因为没有足够的时间去好好推敲方法的设计吗。还有就是各种各样，五花八门的查询。
对于查询，我是没办法，干脆就一个查询一个DAO方法，参数都包含在MAP里，SERVICE里别包含SQL, HQL（HQL和SQL不都是不能垮平台、跨系统的障碍吗）。
不能闲麻烦，就是多几个配置文件吗，一个人用几天就都写完了，累是累点，但那不算是问题。真正耗费时间的是在关键代码书写上和BUG调试上。
DAO还是有存在的道理（如果只用一个通用类，那么JdbcTemplate就可以了）， Service, DAO, Action3者到底应该放置什么样的代码，他们的职能划分才是关键