Quoting the JBI spec: "SEs are the business logic drivers of the JBI system." "BCs are used to send and receive messages via particular protocols and transports."
Let's talk about the jsr181 component. I think the definition for BCs clearly indicates that the jsr181 component is not a BC, so I think it must be a SE ;) The fact that you deploy some java code on it is just a side point: each JBI component has its own deployment model for service units and I would not consider a java class on a different level than a BPEL process. If you do not want to deal with classpath issues, we could add a default classpath location of "." to the SU if nothing is specified. And I do think that the service deployed on the jsr181 component contains the business logic in the same way a BPEL process do. The lwcontainer is a bit of a problem. If possible, i would not categorize it as a BC or SE. Actually, the lwcontainer will never send or receive exchange itself. The only operation performed is to start / stop lightweight components (which can be BCs or SEs). For the shared-library part, it would be cool to put lightweight components in a shared library. However, due to classloader considerations, this shared library would need to contain all the dependencies of all lightweight components, and that would make a very big SL (in tens of MBs). WE could also put all these dependencies in the lwcontainer, but the problem would be the same. I' m not very keen on having a 30 Mb component just to use a lightweight component i would have created on my own. Btw, SL can not really be used when embedding servicemix -- or you use the full JBI feature set (component installation, SU deployment, etc) and it is not really embedded anymore ;) Feel free to argue :) Cheers, Guillaume Nodet On 7/24/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
I have been working through the lw-container, JSR181 and wanted to share some thoughts on these service engines. I'm wondering whether then should be service engines, since they each require a additions to the classpath I'm wondering if they shouldn't be Binding Component Archetypes. I suppose the question becomes one on how best to define the JBI spec. Here is the logic for my argument: If a binding component is meant to broker some interaction with an external system then the JSR-181 and lw-container are most likey doing that. If I can presenting a service interface to the ESB for business logic (most common usecase in the JSR181) then I would have thought I was a binding component. In a binding component we would be able to handle additions to the classpath through the JBI descriptor, while in the Service Units this is don't outside of JBI. I'm thinking that the lw-container and jsr-181 se could be better places as shared libraries that archetypes use - such that you can create an archetype (even add classes to the dependencies) and still have the functionality. This leads into the ServiceMix components and LW-Container - I'm wondering whether servicemix-components would be better off being a Shared Library, then you could create a binding component based on the lightweight component shared library and the servicemix components shared library and hopefully the class path would be resolved. The only problem I see here is that if you are working in a servicemix embedded model you might need to be able to reference shared libraries in your servicemix.xml to force them to load in there so that the packaging can be consistent. I realize this is all large scale changes but I wanted to throw them out there to see what people think? Cheers P
