Spring Integration: a central service and message bus

Home

News: Spring Integration: a central service and message bus

  1. SpringSource has announced the creation of Spring Integration, a project designed to provide a central service and message bus inside the Spring Framework. This builds on Spring's already-impressive capabilities for providing simple models for using services. The benefit is that a Spring configuration can manage all of the communication protocol, such that the service barely has to know it's a service for an ESB at all. An example is given on Mark Fisher's blog entry discussing the announcement:@MessageEndpoint(input="inputChannel", defaultOutput="outputChannel")‏ public class SimpleAnnotatedEndpoint { @Handler public String sayHello(String name) { return "Hello " + name; } }Note the simplicity of the sayHello() method: there are no message protocols involved, and it's using simple and common (and extremely testable) input and output mechanisms. Spring Integration is a logical next step for Spring, as it already provides services for JMS, remoting, scheduling, email, lifecycle management, transaction management, event publication and subscription, and transaction management. In a way, Spring Integration is an extension of all of these features, adding a generalized message subscription and publication mechanism, instead of relying somewhat on a JMS template or an email template, for example. It's scheduled for 1.0 in Q2 2008.

    Threaded Messages (32)

  2. Very usefull[ Go to top ]

    It's a good thing that PtoP and P&S channels will also be available in Spring. It looks like the EBP (event-based processing), a feature available in the Azuki Framework. Azuki's EBP. However, you should also consider using Azuki, as it also provides a straightforward weaving tool to define communication endpoints.
  3. Is this related in any way with Apache Camel (http://activemq.apache.org/camel/) ?
  4. Really?[ Go to top ]

    As a Spring user since 2003, I'm actually confused by this project. I've always bought into the thinking that Spring rarely creates new solutions when there are already good solutions in place. ORM (Hibernate/IBatis/Toplink/JPA) is an obvious example, as is scheduling (Quartz/Java Timer). I'd say the Spring MVC framework would be a counter-example since things like Struts and Webwork (and really countless others) already existed, but hey, seemed like everyone was making their own MVC framework back then. So I'm not sure how this isn't competing with a lot of other existing solutions, including open-source options like Mule and ServiceMix. I understand that Spring already provides a lot of capabilities that are commonly associated with an ESB (isn't that what this is - a "central service and message bus"?), but why not work with something like Mule so that Mule takes better advantage of existing Spring capabilities? I thought Mule already had some tight integration with Spring - couldn't that just be extended further so that Mule dosen't have to provide things that Spring already does? I guess I'd just like to hear the thinking that resulted in the creation of Spring Integration, and why it was decided not to better integrate with an existing ESB.
  5. Re: Really?[ Go to top ]

    No offense, but I just feel that you probably have not had time to spend on Spring Framework enough to discover the advantages of it. Take a look at Spring MVC closer, it is not just URL mapping, Model mapping and Error handling; it is, rather complicated, capable to allow developers to build sophisticated web-flow that clearly separates the view and action models. For Struts, it is still good but it is more or less a quick way of doing small scale web site only. The most you get from Spring Framework is not the libraries in it, it's about how the framework tights things together and put an abstraction on top that builds a unique framework for you to build however the way you want. Yeah we know we can download all components separately, like Quartz, JPA, Hibernate or even Struts (you can integrate Struts inside Spring) but as I said, the best part of Spring is the engine that builds a framework for you so you can focus close to 100% on your business model and minimize your time spending on assembling components and its configurations.
  6. Re: Really?[ Go to top ]

    That's true. I move to Spring MVC after using struts for 3 years. I feel Spring MVC is very easy to learn, and it enables you to write good code. It is powerful framework that lets you customize most of the stuff very easily.
  7. Re: Really?[ Go to top ]

    No offense, but I just feel that you probably have not had time to spend on Spring Framework enough to discover the advantages of it.
    Well, I'd actually say that I know Spring MVC inside and out, and I agree with your points. However, it still is different from much of the core Spring framework in that it competes with existing alternatives as opposed to integrating with them. And since reasons can be given for why Spring MVC exists, then it'd be good to hear the reasons for why Spring Integration is being created instead of leveraging what's already been done on something like Mule or Camel. After all, the Camel website says it is a "Spring based Integration Framework". We now have "Spring Integration". Isn't there reason to wonder about the obvious potential overlap?
  8. Re: Really?[ Go to top ]

    Rob, Our primary motivation is to provide a programming model for enterprise integration that is completely consistent with the Spring framework and portfolio. Going beyond "integration with Spring" or even "built on top of Spring", we will fully exploit Spring's capabilities in the very core of the Spring Integration framework - including such areas as AOP, annotation-based configuration, lifecycle management, task execution, transactions, and security. The Struts vs. Spring MVC comparison here is actually quite interesting in that the Spring team has provided multiple options for integrating Struts 1.x based web-tiers with a Spring service layer - from a simple ActionSupport base class that offers convenient access to the Spring ApplicationContext to a delegating request processor that enables full Spring dependency injection for Struts actions. Nevertheless, most Spring MVC and Web Flow users will agree that completely embracing the Spring programming model in the web tier provides immense value beyond merely injecting dependencies. The fact of the matter is that Spring MVC and Web Flow were designed by the Spring team, and they have evolved alongside core Spring and other Spring portfolio products. If you look at recent developments in the Spring Web stack, such as annotation-driven request mapping and first-class JSF integration, it is increasingly evident that these technologies allow Spring users to harness the full potential of the Spring programming model in the web tier. As the Spring Integration product evolves, I believe you will see the same benefits in the integration space. I also believe that with time, those who currently provide integration products that collaborate with Spring will actually see this as a positive move from their perspective as well - and we do look forward to working with them. Our view is wholly positive - Spring already offers a huge amount of support in the enterprise integration arena, but we can provide even more value - in this case extending the Spring model into the domain of Enterprise Integration Patterns. Whereas other products may leverage Spring, their teams' primary focus will always be on their own product - and understandably so. Our focus on the other hand will be on *Spring* - whether it be Spring Integration, the Spring Framework core, or other products within the Spring portfolio. I spoke with many developers at The Spring Experience this past week who were excited about this new offering for that very reason. Again though, I think it's important to recognize the potential of this new product - not only for those developers who are excited about using it, but also to increase the level of integration possible for those who use other products as well. These motivations are not mutually exclusive, and the recognition of that has always been one of the greatest strengths of the Spring model. -Mark
  9. Re: Really?[ Go to top ]

    Rob,

    Our primary motivation is to provide a programming model for enterprise integration that is completely consistent with the Spring framework and portfolio. Going beyond "integration with Spring" or even "built on top of Spring", we will fully exploit Spring's capabilities in the very core of the Spring Integration framework - including such areas as AOP, annotation-based configuration, lifecycle management, task execution, transactions, and security.
    So, Spring is going from a "lightweight" framework to an application server?
  10. The information is sketchy, but if you read Mark Fisher's blog and the articles he links to, the Spring Integration project appears to be a set of tools that let you add ESB-like capabilities to your application. Some of Mark's quotes mimic the value propositions you hear from ESB vendors, for example: "What this does is it provides a layer of insulation that manages those different endpoints and routes them to the same service implementation..." It sounds like a service developed using Spring Integration is made available through any number of transports. This is one core ESB feature. I wonder where Mark would position this project in the integration landscape... I haven't seen anybody from SpringSource compare this project to the common integration technologies like ESB, EII, or ETL. Is the intent to replace or augment these? I'm the project lead at XAware.org, an open source, real-time data integration project. We already use Spring for core processing capabilities like resource management, data source connectivity, security, and management. It *seems* like the data services we produce would work well with the ESB-like features in Spring Integration. But it would be nice to hear the intent and direction from Mark and company.
  11. Hi Kirstan and everyone, This project sounds interesting..i also looked at XAware ..i am new to integration technology landscape and have few queries .. We have a product to be deployed for N different customers..each is a distinct installation and they are not related. For every installation our product needs to integrate with a customer back-end systems. The customer back-end systems may speak SOAP, XML/Http,.Net Remoting, Propritary protocols etc. Our product typically plays a role of Service Consumer rather then a Service Producer..the interaction is as shown below : [MyDesktopClient]<--> MyProtocol/http <--> [Product/J2EE]<-- protocol X1/X2..Xn---> [customer system] So ,basically from MyProtocol to X1/X2..Xn is required.. Now can we embed spring-integration or XAware engine or any-other-recommended into our Product to solve this kind of problem... Can we do this with ZERO-CODING efforts? If you point me to appropriate docs/demos then also its ok.. Warm Regards, Vimarsh
  12. Vimarsh, sorry for the delayed reply, just getting back from vacation! While I would need more information to tell for sure, it sounds like a viable solution to embed xaware.org features into your application. There are a number of companies that have done exactly this. The typicial model is that the application developer wants to hide the complexity of the deployed environment behind a set of services, which are then implemented using XAware. The application then calls the XAware-based services using one of the supported technologies like Java API, SOAP, JMS, or simple HTTP. Deployment to a customer site then involves mapping those service definitions to the actual interfaces available. The mapping can occur without coding for many of the data sources - JDBC/Data sources, SOAP, XML/HTTP. Some of the technologies may require more work. .Net Remoting, for example, would require another access package like J-Integra (http://ja.net.intrinsyc.com/) or JNBridgePro (http://www.jnbridge.com/jnbpropg.htm). For a brief technology overview (flash), you can look at http://www.xaware.org/content/view/38/245/. We also have a bunch of flash tutorials on the site. Of course, please feel free to contact me directly if you'd like more information (kirstan at xaware dot com).
  13. Good.[ Go to top ]

    I'm very happy about this. As a long time Spring user, I've been trying to figure out what integration style I want to focus on and have looked at everything from Service Mix to Mule to simple remoting/JMS, to Spring Web-Services, to full blown commercial ESBs.
  14. Existing ESB[ Go to top ]

    Spring Integration is a logical next step for Spring, as it already provides services for JMS, remoting, scheduling, email, lifecycle management, transaction management, event publication and subscription, and transaction management
    I do understand why Spring would not just pickup one of the existing ESBs. Mule is a really good solution. Why spend time developing one from the ground up? I felt the same way about SpringBatch. Why not pickup Quartz and add modules to do batching? Am I missing something?
  15. Re: Existing ESB[ Go to top ]

    I felt the same way about SpringBatch. Why not pickup Quartz and add modules to do batching? Am I missing something?
    This is a common misconception: Quartz and Spring Batch have different goals. Quartz schedules a given piece of work, Spring Batch will help you to define that actual piece of work. Combining Quartz (or any other scheduler, also commercial ones) with Spring Batch is therefore very common: Spring Batch does not provide any scheduling capabilities by itself. This is also in the FAQ: http://static.springframework.org/spring-batch/faq.html#quartz In larger corporations, a commercial scheduler is typically already in place to start jobs on different machines and platforms using distributed agents: depending on any given scheduling solution, including Quartz, would severely limit the applicability of Spring Batch in such environments. Joris Kuipers Senior Consultant at SpringSource
  16. Re: Existing ESB[ Go to top ]

    I think Mark has already provided some great insight into the question of where to position Spring compared to other offerings. I have to say I have had mixed feeling with ESBs in the past. In some application I have had the need to start using the Enterprise Integration Patterns described in Gregor Hohpe's book, but I've never felt the need to add in an ESB. I think that is where Spring Integration is different and that's where it's key differentiator in. The way Spring Integration makes you look at the concept of an ESB has taken away the negative associations with the term ESB that I previously had. I think the one central point to take away here is the fact that our idea and vision has always been to put the application in a very central position and build on top of that. This means the application programming model and its non-invasive nature are what you build the most part of your application with, only referencing any external environment where needed and if you do so, do it in a non-invasive way as possible. On a core level, this means you use dependency injection and AOP to build the fundamentals of your application. Using facilities like init-method or the new @PostConstruct you declare certain things to lifecycle management features to be enabled. If now, you need remoting, you can use one of Spring's exporter (HttpInvokerServiceExporter, RmiServiceExporter) to export your bean to a remote endpoint. If you need transaction management, you start declaring certain methods to be transactional (using XML or @Transactional annotatations). The above happens all in more or less the same declarative, non-invasive way and using the same consistent Spring programming model. Back to Spring Integration. Spring Integration essentially does the exact same thing. It looks at the existing Spring programming and answers the question: 'how can we bring the Enterprise Integration Patterns to this already fully fleshed out programming model'. At first sight there is a slight difference between this and asking 'how can be have our application run inside an ESB', but this slight difference is pretty fundamental IMO. Adrian Colyer gave a keynote at The Spring Experience last week where he described how Spring supports different application styles. If you need a tiny bit of batch, you use the Spring programming model and the add the batching functionality to your existing application. If you need a tiny bit of remoting, you export components from your existing application to remote endpoints. If you need a bit of web functionality, you just deploy an DispatcherServlet component and off you go. If now, you need a little ESB-like behavior consistent with the Enterprise Integration Patterns, you just add in a little Spring Integration. One application with multiple styles. Other than that, as Mark already said, this does in no way mean that third parties cannot add value to the Spring programming model in ways they would like to do so. We're already seeing that with a lot of other vendors (take fore example GigaSpaces). regards, Alef
  17. Re: Existing ESB[ Go to top ]

    I do work for SpringSource... I should have added a disclaimer.
  18. Spring Batch[ Go to top ]

    Sergey
    I felt the same way about Spring Batch. Why not pickup Quartz and add modules to do batching? Am I missing something?
    Spring Batch addresses a different problem from scheduling, although many batch users use Quartz and other scheduling solutions. Spring Batch grew out of the realization by Accenture and SpringSource that there were many common problems in batch that were solved over and over again in different projects. As Accenture use Spring heavily, it was natural to look to a Spring-based solution for those problems. If you look at the Spring Batch home page, you'll see many objectives that are simply not addressed in other products. To quote from that page: Business Scenarios * Commit batch process periodically * Concurrent batch processing: parallel processing of a job * Staged, enterprise message-driven processing * Massively parallel batch processing * Manual or scheduled restart after failure * Sequential processing of dependent steps (with extensions to workflow-driven batches) * Partial processing: skip records (e.g. on rollback) * Whole-batch transaction: for cases with a simple enough data model or a small batch size Technical Objectives * Batch developers use the Spring programming model: concentrate on business logic; let the framework take care of infrastructure. * Clear separation of concerns between the infrastructure, batch container and the batch application. * Provide common, container services as interfaces that all projects can implement. * Provide simple and default implementations of the container interfaces that can be used ‘out of the box’. * Easy to configure, customize, and extend services, by leveraging the spring framework in all layers. * All existing container services should be easy to replace or extend, without any impact to the infrastructure layer. It's our goal that Spring Batch and Spring Integration will work very naturally together. Remember that people questioned the necessity for Spring itself several years ago (why not just use Struts?) until they looked at it closely enough to realize that it was something new. Rgds Rod
  19. Re: Spring Batch[ Go to top ]

    Business Scenarios: I personally think that Processing Languages how e.g. BPEL 2.0 are existing solutions which are destinated to rule and govern the Business Processes in Service-oriented and Event-driven Architectures. Business Processes are in many cases very distinct from technical processes, needing the rich tools and technologies to describe the rules and the flow in a flexible, abstract, standard way and has potencially activations over a long period with continually receiving events. I know that the Spring solutions are excellent products - so I'm very anxious for the announced Spring Integration and their features. Maybe after the availability of the first stable release we can see, which of the features indicates positive distinctions to existing solutions and provides advanced potentialities to solve the existing or future integration problems. Roland
  20. "I want my ESB" Syndrome ?[ Go to top ]

    SOAP is not a so appeasing precedent. Guido
  21. Testable code[ Go to top ]

    I have worked on several projects using commercial ESB's and one of the most difficult parts of every one of those projects was figuring out the best way to unit test and do first level integration tests without the framework fully present. There are many tricks and patterns you can use and I won't go into those but they never felt like they were a complete solution. On my current project we are using Spring, where one of the core concepts is creating testable standalone POJO code. I look forward to these concepts being brought to the ESB world and actually being able to write easily tested code. Tim Ferguson xaware.org
  22. The Un-ESB?[ Go to top ]

    The information I've read so far tells me this new project has key features you typically find in an ESB. But I applaud Mark and Alef for not trying to over-hype it by actually calling it an ESB. Instead, they state they are implementing Enterprise Integration Patterns described in Gregor Hohpe's book. I've blogged about this here: http://www.xaware.org/component/option,com_myblog/show,The-Un-ESB-Spring-Integration.html/Itemid,54/ I've also found Gregor's web site that describes these patterns here: http://www.enterpriseintegrationpatterns.com/ I love the fact that SpringSource is implementing well-defined patterns. While it will be obvious to some which of the patterns are implemented in Spring Integration, it would be great if Mark or Alef published a list of patterns they intend to deliver with project.
  23. IS anybody care about the name?[ Go to top ]

    Spring guys you call the product what ever the name you guys want As long as it make the same quality and good enough to slap at the face of some CIO, CTO direct talk agent channel it is GOOD. An ESB should be a framework to provide me flexible, configurable, adaptable framwork to establish transaction aware Transformation, Translation, Wiring, Routing (different protocol, format and layout) of messages based on a common message content such as XML. Those who know JAVA A collection of POJO with supporting tools can do it. However most CTO and CIO do not know JAVA, as long as that model continue, most BIG vendor can sell their GARBAGE to them, Then CTO and CIO Ship that to India or China for cheap labor using average hardworking middle class consumer's money. So again spring guys bring it on and let us do a party on release. Thanks
  24. Smart move![ Go to top ]

    This is a seriously clever move by SpringSource in many ways. Reading some of the other comments already posted above, some people are asking why create something new when there are perfectly good implementations out there already. I can only think that these people must believe that open source software just grows on SVN trees or CVS bushes. SpringSource is a company that have employees and those employees have families and mouths to feed. SpringSource is a business and separating their dependency from other ESBs might hurt some slightly but it will add huge value to the Spring brand. Calling it "integration", which is what it is rather than following marketing trends towards TLAs like SOA, JEE, ESB etc. is brave but beautifully simple, this isn't an app server, it's not a bus and it's not pretending to provide a architecture for services, it's just doing what everyone needs, integration. Any decent architect can piece together TLAs from the essentials ingredient of "integration". Nice one guys, 2008's going to be a big year for you. -John-
  25. Re: Smart move![ Go to top ]

    I can only think that these people must believe that open source software just grows on SVN trees or CVS bushes.
    Yes, I'm clearly a naive idiot for asking why there is a "Spring Integration" when there's Camel that advertises itself as "Spring-based Integration Framework", and Mule touts "Spring framework integration" on its home page. And I'm sure that the creators of Camel and Mule appreciate your implication that their products just grow on "SVN trees and CVS bushes". Very classy. As a long-time Spring user, I'm very interested in Spring Integration, but I think it's very rational to wonder how it will differ from existing products that provide similar features and already integrate with Spring. SpringSource has not done this in the past for things like ORM, remoting, or job scheduling, so it's important to know why this is being done for EIP. Mark - thanks for the useful explanation above. I checked your blog - any more news on when the 0.5 code will be available?
  26. Re: Smart move![ Go to top ]

    Rob
    As a long-time Spring user, I'm very interested in Spring Integration, but I think it's very rational to wonder how it will differ from existing products that provide similar features and already integrate with Spring. SpringSource has not done this in the past for things like ORM, remoting, or job scheduling, so it's important to know why this is being done for EIP.
    We believe that what we have something to add in this space. The fact that numerous existing products heavily promote being "Spring-based" or "Spring integration" indicates the central role of Spring in this space, and the importance of seamless Spring integration. We are offering something different to existing products and are hopeful that they will choose to work to add value over Spring Integration as they have done to date over the Spring Framework. It is important to note that the Spring Framework has always had an integration capability, and that this direction is consistent with that. Also, as the Spring Portfolio has grown (with Spring Web Services, Spring Batch etc.) it makes more and more sense for a higher-level integration programming model to be part of Spring itself. The question is whether or not Spring Integration proves to be a good product and whether it solves problems for users. I'm excited about Mark's ideas and think that its programming model (which I was involved in defining) will be innovative. If people don't agree, they don't need to use it. Spring has never been in the business of me-too projects, and we aren't going to start. Rgds Rod
  27. Re: Smart move![ Go to top ]

    any more news on when the 0.5 code will be available?
    Rob, I will be posting another blog entry tomorrow to walk through a couple samples while also providing the link for anonymous SVN checkout. I have been snowed under this week (figuratively and literally). Thanks for the patience! -Mark
  28. Re: Smart move![ Go to top ]

    I can only think that these people must believe that open source software just grows on SVN trees or CVS bushes.

    Yes, I'm clearly a naive idiot for asking why there is a "Spring Integration" when there's Camel that advertises itself as "Spring-based Integration Framework", and Mule touts "Spring framework integration" on its home page. And I'm sure that the creators of Camel and Mule appreciate your implication that their products just grow on "SVN trees and CVS bushes". Very classy.
    The point I was trying to make that either I didn't express correctly or you misunderstood was that open source is a business, particularly in the case of Spring, Camel and Mule. It's not just something people donate for the good of mankind. I know Ross who created Mule, James and Rob who created Camel and Rod and Adrian from Spring very well, they're all good drinking buddies of mine (and none of them are American incidentally). Ross is running MuleSource with Dave and they're charging money for license and services, that's where Ross and Dave's salaries come from. James was lucky enough to have been acquired by IONA who pay his salary but the business (of IONA) still need to see generated revenue from Mule and Fuse in order for James to remain on the payroll. Finally Rod pays himself from SpringSource, it pays for his flight, hotels, drinks, wife and children. If Rod (and his colleagues) just sit back and let Mule and Camel take the money for the implementations while SpringSource just charge for the framework there's a limit to how long this can last. The VCs and potential acquirers will not see the same value in SpringSource without productising things like Integration, Batching and perhaps OSGi. With SpringSource's move into providing an implementation they clearly separate themselves from the other two. While this might not seem logical if they were paid salaries for doing something other than open source but business-wise it's a very smart move. It's very difficult to make money from open source, it's only the top brands that make money and the best way is still the acquisition exit plan as demonstrated by JBoss. JBoss never really made much money, they didn't before acquisition and they didn't afterward, they so bad at it that Red Hat was recently downgraded from "buy" to "hold" because of JBoss sales (of lack there off). To make money you have to have something that clearly differentiates you from the general noise and/or be behind a standard or following such as Spring, OSGi etc. -John-
  29. There is nothing wrong with making money[ Go to top ]

    Everyone needs to feed their family and themselves. There is nothing wrong with making money as long that means to getting the money is morally right. With respect to the open source projects only the best products survive. I wish all the best to smart and hard working people out there.
  30. Re: Smart move![ Go to top ]

    After all, please - we will not forgot, that the work of the most Open Source Projects are not based on single persons, but rather on many, many peoples which are still and hard working in the background. Many of those people are knowing, that are never receive any money for their engagement. Maybe, the fact, that are involved in the evolution of a great work, which ist very distinct to the form of their daily working-parts, the liberty and the team play, are satisfaction enough for their participation. Many, many thanks to such peoples which are involved in Open Source Projects. I personally think, that the modern Information Technologies - are not in the same advanced state, without the progress which we have received from many of those Open Source Projects over the last years. Sorry, for my simple English. Merry Christmas. Roland SOA Competence Network
  31. Camels, Mules and Kangaroos[ Go to top ]

    This year I have taked a closer look to some nice animals how e.g. Camels and Mules - very great animals, which fantastic characteristics. Now, for the next year I have planned to take also a closer look to an other nicely animal: The Kangaroo, which is very dynamic - his principal characteristics are: to spring very fast and efficiently from each site to other ;-) --- Roland SOA Competence Network - Merry Christmas and a Happy New Year to All - Feliz Navidad y Próspero Año Nuevo para Todos - Schöne Weihnachten und ein gutes und erfolgreiches neues Jahr für Alle.
  32. I haven't coded anything with this yet, so I may be jumping the gun, but, at first look, this is just too good to be true. Simple, consistent, and highly-applicable to a number of situations. We have also looked at ESB's in the past, but we haven't needed everything an ESB offers. Instead, we've needed only the "skeleton" in order to implement our own, light-weight message framework. And here it is. Great job!
  33. cool[ Go to top ]

    thanks for the info its realy been helpful to me