On 7/24/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
Yeah I know the spec speaks about SE and the business logic - though I tend to this that was meant in the context of BPEL and Business Process - I suppose the question becomes if i have an application that wants to expose functionality should that be a SE? SE's by the spec are meant to contain artifacts which in my mind would push them toward the concept of re-usable services (complex routing/transformation/process defintion). I'm just not convinced they suit a programming environment that people can use to make their application "ESB-able". While I might be a bit off the mark - I suppose I'm trying to look beyond the JBI spec at how we can make people using ServiceMix in their applications easier - and if I wanted to start developing an endpoint for my application I would imagine that I'm going to create a component that is going to include many of the library from my application and therefore I would be writing a Service Engine (according to the spec) but what if going to go in my Service Unit? I suppose it is a discusion on the user-cases for implementing :) I'm coming from a place where I think of SE's as re-usable services supplied by the IT department to service integration and therefore when the ESB touches upon an application in the enterprise I don't think of them writing a Service Engine to expose their accounting services, in an ESB model they would be exposing Endpoints that aren't really re-usable in a Service Assembly? I'm sure I'll be shouted down a bit for it, but I'm just thinking out loud on how ServiceMix gets implemented in a large scale SOA?
If you read the introduction in the JBI spec, from a user pov, there are mainly two roles: * JBI component developers * JBI application developers I really think these roles are not the same and may require different skill sets. As i said in another mail, the lightweight components / container is not the best way to think about JBI. I think that xslt, file, ftp, drools, groovy lightweight components should be reusable standard JBI components were you would deploy SU. Given that, ServiceMix would ship with the a set of reusable components that would cover most of the basic needs. Thus, the main role to target imho is the JBI application developer. All routing, transformation and binding should be covered by existing components and the developer should just have to create the SUs (xslt stylesheet, routing definitions as done in the EIP component), http or jms bindings, and link them together in a SA. Of course, there are cases where you won' t find an existing reusable JBI component to provide the feature you need. In such a case, you can choose to develop a simple lightweight component instead of trying to create a fully reusable SE. This is where the lwcontainer comes into play, but again, i would prefer a component that would not rely on servicemix specific features (a la spring toolkit). On the components note - I was thinking we turn both the lw-container and
servicemix-components in shared libraries and then create a lw-container and lw-container-with-components projects that would simply reference both of these? I was hoping the parent first class loader delegate would get us around it?
This would not work, because the JVM will always load classes that are referenced directly from the same classloader. So if you put a lightweight component in a SL, the dependencies need to be in this classloader or the parent one(s). Cheers, Guillaume Nodet Nothing like a Sunday night discussion :)
P On 7/23/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > 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 > > > > > >
