Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på Twitter
Spring Source recently announced a new member of the Spring family: Spring integration . It is an attempt to provide an abstraction for messaging, in the domain of business integration (i.e. it is not Telecom Messaging). Due to the lack of frameworks in this area, we have designed messaging abstractions for several large Java EE projects. One such effort was presented in a speech I held at Expertzone Developer Summit (slide 42 and onwards) and also at Cadec 2006 (page 28 - 37) . It is indeed a very welcome addition to the Spring family!
“Integration” without a namespace, overlaps with the core of Spring itself. Spring is a framework for none-intrusive integration of platform mechanisms into application logic - sometimes by defining a unifying abstraction (api) for each class of mechanisms (Transaction Management, Batch Processing, Servlet Requests etc), and always (even when the Java platform has a sufficient abstraction - like JDBC) by providing a configuration mechanism to integrate various implementations in a loosely coupled fashion (dependency injection). So - when Spring itself is about integration - what is then Spring Integration? Meta integration? No, the name Integration stems from the ambition to provide a framework that helps developers apply the Enterprise Integration Patterns (EIP) . When an application architect approaches integration, her concern is to abstract messaging. There are several reasons for doing so:
Spring Integration defines such an abstraction.
I’m not quite sure it is.
EIP includes Web Service integration. Web Services have not yet been incorporated, but communicated as a target. Although Web Services are often used for integration (integration of services) and are also by definition an abstraction for message based communication, there will be a substantial loss of semantics, when hiding it as a Channel Adapter type . I’ve had a common messaging abstraction across asynchronous messaging technologies and web services in mind when designing similar abstractions (also Spring-based) for customers. According to my experience to much of service semantics are lost when pushing Web Services (WSDL-defined services) down under the cover of a messaging abstraction. Today, I would say that the opposite is a better approach. The Spring-based service integration framework Apache CXF is a good example. I think Spring Integration should have been named Spring Messaging and solely be focused on the application developers perspective of message-based communication.
Spring is a framework for application architects. When an integration architect approaches integration, applications are considered “frozen commodity”. A substantial part of EIP is targeting the needs of an Integration Architect. Aspects like routing, scatter/gather, pub/sub and other types of advanced mediation is better externalized to ESB-type of subsystems than integrated into the application build/release cycle. Mediation sub systems may of cause be based on Spring (maybe Spring Enterprise Integration to support realization of such subsystems).
As the framework is scoped, it may inspire to bad habits rather than common integration best-practice . Even if a application framework supports multi-channel access to other systems (like files, sockets, and of-cause - JMS), it is typically not the path an application architect should take. Chose a single, robust endpoint technology, like JMS and then delegate semantic and technical adaption to an ESB subsystem that connects to the JMS source.
If you chose a message-based approach, like JMS, Spring Integration is an excellent abstraction that should be used (please provide support for Java EE Message Driven Beans!). If you chose a service-oriented approach, chose a service-oriented abstraction like JAX WS with Apache CXF (if you need Spring), rather than Spring integration. Don’t use Spring Integration (or Apache CXF) for point-to-point / multi-channel integration - delegate to your enterprise ESB or to an application-bound light-weight ESB like Mule .