Hi I am newbie using IBM BPM v. 8, and I have also developed using Spring framework. Where do I can find infomation to integrate "Integration Designer "(I have seen this is the part within IBM BPM 8) where one can instantiate a class and invoke its methods) with Spring. Is this possible? Or am I dreaming over something is not needed?
AndrewPaier 2700040K2Q836 Posts
Re: Using Spring with IBM BPM 82013-08-28T11:50:40ZThis is the accepted answer. This is the accepted answer.
It is possible, but, in general, not recommended. Spring (and java in general) is not what I would call a "first class citizen" in Process Designer. You can integrate to them if you desire, but they are essentially an integration point, not a direct member of the Process.
Where would you possibly use Spring? Well in a typical process you create Business Objects to contain the data that collect through the process. While "Objects" is in the name, in reality these are essentially data structures, not true objects. For a given process instance, if you create the Business Object at at the BPD level, you can hand it (or parts of it as appropriate) into/out of services to display them and receive updates.
Where Spring might come in is if your business wants the data in the objects saved to a relational database, you have a decision to make on how you want to tackle that problem. If you want to write all the relational data code on your own, you will need to use the database services in the System Data Toolkit. If, on the other hand you want Spring to do all that heavy lifting then you need to do something like the following -
- Create the Business Object(s) for your process.
- Write at least some of the code that will allow you to display/update these BOs.
- Create your Spring code for the persistence of the BOs.
- Write a Java integration where you hand your BO to the integration and it creates the correct Spring object and saves it.
- Likely make sure you can do the opposite as well (create a BO from the Spring data)
- Add the integrations to the appropriate places in your solution.
email@example.com 270002TGMJ424 Posts
Re: Using Spring with IBM BPM 82013-08-28T16:24:25ZThis is the accepted answer. This is the accepted answer.
- AndrewPaier 2700040K2Q
I think the critical issue here is "what do you mean by integrate with Spring" and what benefit are you expecting to get? Andrew is assuming that you are looking to use Spring as a bridge to a persistence framework, but obviously Spring is a pretty big framework with lots of "stuff", most of which is fairly modular. Much of it is designed to eliminate boiler plate code. Other big parts are to provide a MVC framework for handling web and REST requests.
Additionally, a lot of Spring framework components, like its MVC framework and security framework just don't make any sense in the context of IBM BPM. BPM has its own layer for UI that is very tightly integrated with the process. If you absolutely need to use an external framework for managing the UI, you should probably be looking at implementing using an "external activity" or the REST API. (Not that I typically recommend that approach.)
If you are asking "I have a bunch of spring-enabled Java objects with all of my business logic, can I just include them in my process application and invoke them directly?" the answer is a little more complicated. In short I concur with Andrew's answer: you probably can, but you probably shouldn't.
Several years ago, I was much more willing to consider this kind of approach. But I ended up with a couple of problems.
- Firstly, conflicts between Java version libraries. IBM BPM has a lot of open source libraries in it. And I frequently seemed to run into problems where IBM BPM depends on one library and the framework depends on another.
- Secondly, Spring (and many other frameworks) is very configuration file dependent. IBM BPM generally wants your process applications to be not dependent on the server state: to make deployment/clusters easier. There are some ways around it, with installation services, but why make your life harder?
- Finally, Spring seems to generally take the approach that Spring is in control of everything and is going to keep the whole big object graph in memory. IBM BPM, conversely, is going to treat these Java objects as "I am going to instantiate one object temporarily in order to get one specific thing done. Next time I make a request, I might not even be on the same server, so everything must be stateless." This can be overcome with some adapter classes, but is generally a mismatch that needs gets in the way.
But the real thing that has changed my opinion here that this is a real architectural mismatch. If you have a bunch of business functionality that you want to offer as a service to BPM, why not offer it as a service? Offering it as a POJO is too tight of coupling. (Which causes all of the symptoms above.) Especially when Spring now has tools to making offering functionality as a service fairly easy.
In the common case, I generally find that if you have a bunch of a Java assets that need to be included as part of the business functionality of a process that it is best to consume these Java assets via REST/SOAP rather than via POJO. It's the cleanest architecturally and the tools to do so are easy enough.
So, to summarize my rule of thumb advice:
If you are asking "can I use Spring to make my job writing Java code easier?" I'd answer, "you shouldn't be writing Java code".
If you are asking "can I use these pre-exisiting Spring objects in my process?" I'd answer "yes, but the best approach is to integrate with them via REST/SOAP rather than trying to invoke them directly via Java connectors."
If you are asking "can I use Spring as a persistence layer for external data?" I'd point you to Andrew's answer. Yes, you can, but you it's not simple to do. You need to ask "why is the out of the box functionality of variables types, shared variable types, and database connectors not sufficient?" and "Will Spring make dealing with those cases any easier?" and "Are there any approaches other than Spring that might be even easier?". Spring might be the easiest approach for some use cases, but it's certainly not the typical case.
DavidUpdated on 2013-08-28T16:32:22Z at 2013-08-28T16:32:22Z by firstname.lastname@example.org