为了与它提供的其他重要概念的抽象相一致，Spring提供了一个对元数据实现的外观（facade）， 以org.springframework.metadata.Attributes这个接口的形式来表示。
这样一个外观很有价值，因为下面几个原因：
目前还没有一个标准的元数据解决方案。 Java 1.5版本会提供一个，但是在Spring1.0版本的时候， Java 1.5仍是beta版本。而且，至少两年内还是需要对1.3和1.4版本的应用程序提供元数据支持。 现在Spring打算提供一些可以工作的解决方案： 在一个重要的环境下等待1.5，并不是个好的选择.
目前的元数据API，例如Commons Attributes（被Spring 1.0使用）， 测试起来很困难。Spring提供了一个简单的更容易模拟的元数据接口。
即使当Java 1.5在语言级别提供了对元数据的支持时，提供了一个如此的抽象仍然是有价值的:
JSR-175的元数据是静态的。它是在编译时与某一个类关联，而在部署环境下是不可改变的。 这里会需要多层次的元数据，以支持在部署时重载某些attribute的值－－举例来说， 在一个XML文件中定义用于覆盖的attribute。
JSR-175的元数据是通过Java反射API返回的。这使得在测试时无法模拟元数据。Spring提供了一个简单的接口来允许这种模拟。
虽然Spring在Java 1.5达到它的GA版本之前将支持JSR-175，但仍会继续提供一个attribute抽象API。
Spring的Attributes接口看起来是这样的：
public interface Attributes {
Collection getAttributes(Class targetClass);
Collection getAttributes(Class targetClass, Class filter);
Collection getAttributes(Method targetMethod);
Collection getAttributes(Method targetMethod, Class filter);
Collection getAttributes(Field targetField);
Collection getAttributes(Field targetField, Class filter);
}
这是个最普通不过的命名者接口。JSR-175能提供更多的功能，比如定义在方法参数上的attributes。 在1.0版本时，Spring目的在于提供元数据的一个子集，使得能象EJB或.NET一样提供有效的声明式企业级服务。1.0版本以后，Spring将提供更多的元数据方法。
注意到该接口像.NET一样提供了Object类型的attibute。 这使得它区别于一些仅提供String类的attribute的attribute系统， 比如Nanning Aspects和JBoss 4（在DR2版本时）。支持Object类型的attribute有一个显著的优点。它使attribute含有类层次，还可以使attribute能够灵活的根据它们的配置参数起作用。
对于大多数attribute提供者来说，attribute类的配置是通过构造函数参数或JavaBean的属性完成的。Commons Attributes同时支持这两种方式。
同所有的Spring抽象API一样，Attributes是一个接口。这使得在单元测试中模拟attribute的实现变得容易起来。