為了與它提供的其他重要概念的抽象相一致，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的實現變得容易起來。
