Re: ServiceMix 4.0 documentation
I agree that the way maven is organized helps some...I really like the way
the apache Tomcat products are split up by revision on the main page...it
really makes navigating the page easy.
As for the javadoc I think it is a good idea...I know I've had to dig
through the code to figure out how things were working when it wasn't
explained clearly in the documentation. At least with javadoc developers may
be able to find what the are looking for faster. The ActiveMQ project
suffers from javadoc laziness as well...so maybe we could help promote this
philosophy there :)
bsnyder wrote:
>
> On 10/5/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>> I was wondering if we should create a separate wiki space for
>> ServiceMix 4.0 documentation.
>
> That's a good idea, in fact, we will need to completely restructure
> the wiki into two sections; 3.x and 4.x similar to the way that the
> Maven team did it when Maven 2 overtook Maven 1.
>
>> Also I need to take a look at how the camel book works: it generates a
>> pdf from the wiki, so maybe we could do the same...
>
> I'm sure you know this already Guillaume, but for the sake of others
> here's how this works. There's a page on the ActiveMQ wiki named Book
> In One Page that contains the contents of the book. This page is then
> exported to PDF using Prince XML and the Boom CSS. This is a very
> powerful combination that produces a very nice PDF for download.
>
> And speaking of docs, another goal of ServiceMix 4.0 is to provide
> great Javadocs and comments in the code to explain everything as much
> as possible. So if you are reading through the code and see something
> that is not Javadoc'd or commented appropriately, please stop and fix
> that broken window (i.e., fix the problems when they are small, before
> they get big).
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>
>
--
View this message in context:
http://www.nabble.com/ServiceMix-4.0-documentation-tf4573543s12049.html#a13065370
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: ServiceMix 4.0 modularity
On 10/4/07, Chris Custine <[EMAIL PROTECTED]> wrote:
> I agree that eventually you will have certain components that have their own
> release cycles seperate from the core components. I think it will take
> several releases of all components as an entire system before you will be
> comfortable splitting things into seperate sub-projects, but as the core
> components mature and stabilize I think it will be a natural desire to have
> more frequent releases of the optional components.
Agreed.
> The dependency management issues mentioned by Bruce and Kit are valid, but
> don't forget that the bundles are able to specify required version
> information for their own dependencies. So the dependency management issue
> is more about shipping a properly working default configuration with the
> main ServiceMix distribution than about the seperate releases of components.
That's a good point and something I forgot about. I guess we'll need
to relax any static version requirements once the core stablizes so
that we can allow a wider range of acceptable versions of various
components.
> I like Guillaume's idea of offering a basic image that is capable of
> provisioning itself from a managed OBR repository. This could also allow a
> user to configure their own customized provisioning configuration similar to
> kickstart files for Linux distributions. I think you will also want to
> offer a fully loaded and self contained image that already has all of the
> components available, but the auto-provisioned basic image will be very
> useful for a lot of users I would think.
I think this is a good paradigm as well. However, a question arose
today about continuing to allow ServiceMix to be embedded in any old
Java app. Some folks may want an OSGi container to be started when
embedding ServiceMix, and some may not. All I'm saying is that we need
to keep this in mind as a requirement because there are a fair amount
of users who are embedding ServiceMix today.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
ServiceMix 4.0 modularity
I'd like to make ServiceMix 4.0 as modular as possible. This would mean that ServiceMix 4.0 main distribution would come with the minimal set, while additional features could be provisioned and configured using OBR, the Deployment Admin or our provisioning system. Such features could include: * an activemq broker * an apache ds server * jbi 1.0 compatibility layer * jaxws support * ... Although from a project perspective, if we could split these features in different projects, that would make things easier to release: i.e. release a single "feature" at a time, rather than releasing everything each time. Kinda like maven does with its plugins. Thoughts ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Do you know the probable Release Date ServiceMix 4.0?
"Do you want to help on that ?" You are flattering me. I am currently at a user level. Thank you for the good work. On 9/7/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > > Well, not yet as it's still a bit fuzzy... > In 2008 for sure... > Do you want to help on that ? > > On Sep 7, 2007, at 3:52 PM, Simon Sekat wrote: > > > We are counting on using it because it supports OSGI deployment model. > > > > Thank you, > > > > -- > > > > Simon S. > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > -- Simon S.
Do you know the probable Release Date ServiceMix 4.0?
We are counting on using it because it supports OSGI deployment model. Thank you, -- Simon S.
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
On 8/28/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote:
> I'm using Colloquy (http://colloquy.info/)
Yeah, I've used it for the last few years. It's not as comprehensive
in functionality as some of the hard-core IRC clients for Linux (e.g.,
BitchX, etc.) but it's pretty nice and perfect for MacOS.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
I'm using Colloquy (http://colloquy.info/) Cheers, Guillaume Nodet On Aug 28, 2007, at 11:57 PM, Daryl Richter wrote: On Aug 28, 2007, at 8:53 AM, Nodet Guillaume wrote: On Aug 28, 2007, at 2:48 PM, Piotr Bzdyl wrote: Hi, I would also like to participate in this session. When are you going to send data about the location of the IRC session? See http://www.nabble.com/forum/ViewPost.jtp? post=12323536&framed=y&skin=12049 We will use the standard IRC channel: see http://incubator.apache.org/servicemix/irc.html I have also another question: could you recommend any easy in use IRC client (for Windows preferably)? I haven't been using IRC (except one or two times). Before switching to mac, I was using xchat. See http://www.xchat.org/ So, now that you are on mac, what do you use? ;) (Another IRC newbie) Cheers, Guillaume Nodet -- Daryl Email *my = [ daryl at: @"eddl" dot: @"us" ]; Weblog *blog = @”http://itsallsemantics.com”;
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
On Aug 28, 2007, at 8:53 AM, Nodet Guillaume wrote: On Aug 28, 2007, at 2:48 PM, Piotr Bzdyl wrote: Hi, I would also like to participate in this session. When are you going to send data about the location of the IRC session? See http://www.nabble.com/forum/ViewPost.jtp? post=12323536&framed=y&skin=12049 We will use the standard IRC channel: see http://incubator.apache.org/servicemix/irc.html I have also another question: could you recommend any easy in use IRC client (for Windows preferably)? I haven't been using IRC (except one or two times). Before switching to mac, I was using xchat. See http://www.xchat.org/ So, now that you are on mac, what do you use? ;) (Another IRC newbie) Cheers, Guillaume Nodet -- Daryl Email *my = [ daryl at: @"eddl" dot: @"us" ]; Weblog *blog = @”http://itsallsemantics.com”;
Re: ServiceMix 4.0
Guillaume, No problem... I think you will be happy with this choice. Also to clarify something important, I really encourage you to replace commons-logging-1.x.jar with jcl14-over-slf4j which implements the commons-logging interfaces and maps them to slf4j static binding. This will solve the problem with other projects like Spring that still use commons-logging and provide consistency for your projects. Cheers... Chris On 8/28/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > Thanks Chris ! > It seems like the experts have answered... > So i guess we will switch to slf4j :-) > > Cheers, > Guillaume Nodet > > On 8/28/07, Chris Custine <[EMAIL PROTECTED]> wrote: > > You are correct about OSGi having more control over classloaders, but in > the > > case of JCL things are a little different. Below is a link to the > mailing > > list thread where we went through all of this pain on the Spring-OSGi > > project and decided to replace JCL with the slf4j facade in order to > > eliminate the side effects caused by Spring using JCL. I think > Spring-OSGi > > uses slf4j natively now because of this and I believe it has been a > > consideration for Spring itself to move to it, but I am not sure of the > > final outcome of that discussion. > > > > http://tinyurl.com/3axajc > > > > I think the thread was cross posted to Equinox as well and a discussion > > occured there... > > Just google "commons logging madness" :-) > > > > As you said about OSGi being flexible, one nice thing about using slf4j > in > > OSGi is that you can have all implementation bundles (slf4j-log4j, > > slf4j-jdk14, etc.) available in the container, and it is up to each > bundle > > to specify which one it imports, thereby adding it to the classloader > > wiring. I can't remember if that is built in functionality of slf4j or > if > > it is something that I made work, but it is all done with manifest > headers > > so it is easy to do if its not shipped like that. > > > > Good luck! > > Chris > > > > On 8/27/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > > > > > > I would say the opposite. The OSGi classloaders are much more > > > powerful and you can more easily control the visibility of classes. > > > In addition, if JCL is required by a given bundle A, it does not > > > mean that it will be visible by a bundle using bundle A. > > > > > > Obviously, this means to be tested (or maybe OSGi experts could > > > help there...) > > > > > > Cheers, > > > Guillaume Nodet > > > > > > On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote: > > > > > > > Also, moving toward an architecture based on OSGi almost guarantees > > > > that we will run into classloader issues with JCL. > > > > > > > > Bruce > > > > > > > > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ >
ServiceMix 4.0 api
I've refactored a few things in the api and introduced back the listeners and flows. For those who prefer to read javadoc, take a look at: http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/ The javadoc is quite low on comments right now, so if any area appears to be unclear, ask for comments and I will improve the doc asap. Although any ideas, feedback, patches are always welcome. To test the API, I have started a really dumb implementation of it in the branch, but don't expect much at this point ;-) http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/ Cheers, Guillaume Nodet
Re: ServiceMix 4.0
I would highly recommend switching to slf4j for internal logging, and then
use the slf4j over jcl facade to permanently get rid of commons-logging. If
you are going to use OSGi in the future, you will have trouble with the
dynamic classloading issue introduced by JCL. The slf4j facade will
alleviate this because the linkage is static (based on which jar you choose
to use).
I blogged about this a while back here:
http://blog.organicelement.com/2006/12/21/commons-logging-classloader-woes
Also slf4j is fairly OSGi friendly in that it has OSGi manifest headers
already built in so you can deploy with OSGi and make the logging package
available to all bundles.
Chris
On 8/27/07, Bruce Snyder <[EMAIL PROTECTED]> wrote:
>
> On 8/27/07, James Strachan <[EMAIL PROTECTED]> wrote:
>
> > > > 1. Use slf4j as the logging framework. (http://www.slf4j.org/) ->
> btw,
> > > > I'm not sure if its a better option, but I did hear some good stuff
> > > > about it.
> > >
> > > Yes, SMX should switch to using the slf4j-api which will allow any
> > > logging framework to be plugged in at deployment time.
> >
> > how's that different from commons-logging (other than adding yet
> > another dependency, since many things SMX depends on also depends on
> > commons logging)
>
> There are a lot of reasons, including an extremely good writeup about
> JCL that Ceki did back in 2004 that is available here:
>
> http://www.qos.ch/logging/thinkAgain.jsp
>
> But the most important point of all is that the use of JCL is most
> oftentimes incorrect from an architecture standpoint. At least this is
> what the creator of JCL says:
>
> '...The purpose of Commons Logging is not to somehow take the logging
> world by storm. In fact, there are very limited circumstances in which
> Commons Logging is useful. If you're building a stand-alone
> application, don't use commons-logging. If you're building an
> application server, don't use commons-logging. If you're building a
> moderately large framework, don't use commons-logging. If however,
> like the Jakarta Commons project, you're building a tiny little
> component that you intend for other developers to embed in their
> applications and frameworks, and you believe that logging information
> might be useful to those clients, and you can't be sure what logging
> framework they're going to want to use, then commons-logging might be
> useful to you...'
>
> See Rod's full blog entry here:
> http://radio.weblogs.com/0122027/2003/08/15.html
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>
Re: ServiceMix 4.0
I would say the opposite. The OSGi classloaders are much more powerful and you can more easily control the visibility of classes. In addition, if JCL is required by a given bundle A, it does not mean that it will be visible by a bundle using bundle A. Obviously, this means to be tested (or maybe OSGi experts could help there...) Cheers, Guillaume Nodet On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote: Also, moving toward an architecture based on OSGi almost guarantees that we will run into classloader issues with JCL. Bruce
Re: ServiceMix 4.0
On 8/27/07, James Strachan <[EMAIL PROTECTED]> wrote:
> > > 1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
> > > I'm not sure if its a better option, but I did hear some good stuff
> > > about it.
> >
> > Yes, SMX should switch to using the slf4j-api which will allow any
> > logging framework to be plugged in at deployment time.
>
> how's that different from commons-logging (other than adding yet
> another dependency, since many things SMX depends on also depends on
> commons logging)
There are a lot of reasons, including an extremely good writeup about
JCL that Ceki did back in 2004 that is available here:
http://www.qos.ch/logging/thinkAgain.jsp
But the most important point of all is that the use of JCL is most
oftentimes incorrect from an architecture standpoint. At least this is
what the creator of JCL says:
'...The purpose of Commons Logging is not to somehow take the logging
world by storm. In fact, there are very limited circumstances in which
Commons Logging is useful. If you're building a stand-alone
application, don't use commons-logging. If you're building an
application server, don't use commons-logging. If you're building a
moderately large framework, don't use commons-logging. If however,
like the Jakarta Commons project, you're building a tiny little
component that you intend for other developers to embed in their
applications and frameworks, and you believe that logging information
might be useful to those clients, and you can't be sure what logging
framework they're going to want to use, then commons-logging might be
useful to you...'
See Rod's full blog entry here: http://radio.weblogs.com/0122027/2003/08/15.html
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
+1 - Original Message From: Daryl Richter <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent: Monday, August 27, 2007 7:34:08 AM Subject: Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0) On Aug 25, 2007, at 2:12 AM, Nodet Guillaume wrote: > Ok, sounds like we have enough people. > So we just need to find a data and an hour. > What about Friday 3 pm GMT, 11 am EST, 8 am PST > Adrian, I'm not sure how to find a time that would suits you... > Other propositions are welcome... +1 > > Cheers, > Guillaume Nodet > > -- Daryl http://itsallsemantics.com "Under capitalism, man exploits man. Under communism, it's just the opposite." -- John Kenneth Galbraith Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
Re: ServiceMix 4.0
Feel free to let me know when this is scheduled and I will try and attend. Terry
Re: ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
On 8/24/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > > So if i understand you correctly, you are mostly concerned of enhancing > the JMS flow in the following areas: >* avoid ping/pong and lower bandwidth requirement >(avoid sending the whole exchange and only send the actual data) >* enhance security (authentication, encryption ?) >* enhance the endoint registry wrt to services or instances going > up and down Did I catch you correcty ? Yes.The registry piece is a little interesting for us to. Because we are integrating "hardware" via service components we've had to abstract the notion of capabilities. It would be nice if the registry were extensible. For the bandwidh requirement, I'm sure we can do that and reconstruct > a fake > exchange on the other side. We would loose informations wrt to the > input message > but I don't think this would be too much a problem. For the ping/ > pong stuff, I'm sure > we can find a way to optimize it somehow. We may have troubles > handling the > InOptionalOut pattern though, as you don't really know if you will > receive an Out > message or nothing, but for the other simple patterns (InOnly and > InOut) it should > be quite easy to send back the exchange with a DONE status just after > having send > the jms message containing the In or Out. I think as long as everything is optional wrt to optimizations the fact that it may exclude various patterns is acceptable. We've done everything in an InOnly world. On the security subject, I know there is lots to do, but this is an > area i'm not so familiar > with. My biggest concern is that we security can be applied at the > connection level > or at the message level. NMR-NMR security for the JMS flow could be > delegated > to ActiveMQ i guess (using AMQ security features). Agreed. It is now...the Network of Brokers feature. But, there is not really any concept of policy. On the registry side, I think one of the main problem is that there > is no way to tell the > difference between an endpoint that goes down because the server is > no more > accessibe (it will be up again at a later time) or because the > endpoint has been > undeployed. Imho, this is a key requirement to be able to make > routing decisions. > I don't know yet how to handle this problem: if a server has been > shutdown, it may > never go up again... Yeh, like if it has been blown up by an IED... > So i'm still not sure how to handle the problem :-( Yep, you are right. Right now if we undeploy a service assembly, its endpoint still exists, and messages are still routed to it. Could just be a bug. ; } I'm sure more discussion on this will follow. Cheers, > Guillaume Nodet > > On Aug 23, 2007, at 3:35 PM, Kit Plummer wrote: > > > Sure Guillaume. > > > > Maybe the best thing to do is explain the concept...and what we've > > done to > > meet our requirements. > > > > It is actually quite simple. We needed to be able to connect two > > computers > > together via TCP/IP, and have a publisher on one system, the > > consumer on the > > other. Granted we've got lot's of both on each - but, the premise > > is that > > link between is transparent. > > > > Currently, we are using a feature of ActiveMQ called "Network of > > Brokers" > > (NoB) to create a mapping of destinations/endpoints. > > > > Where it gets really complicated is when we only want to allow a > > specific > > MEPs to cross the NoB connection. In this example, bandwidth is not a > > commodity and must be tightly constrained. We were tolerant of all > > the SEDA > > flow handshaking, but I believe it would be nice if InOnly MEPS > > really were > > just a single transmission (turning off levels of reliability/ > > durability). > > Also, in our environment multicast isn't possible, and the networks > > are > > fairly ad-hoc...meaning not stable. Plus, we need to know about > > the state > > of the link. > > > > Service registration happens also in different configurations. For > > example, > > one topology we support is a hierarchical flow (master-slaves). > > Imagine a > > simple sensor net. There would be a single point at the top, where > > are data > > were to be aggregated. So, in this example the NoBs need to support > > "followers" only communicating with their "leader"...and the > > "leader" only > > communicating with its "leader". But, there might also be a need > > to have > > "shared" data that is available on all platforms in network > > (health, state, > > etc.). Ding lifecycle. > > > > I could keep going...but, am curious if anyone else looks at it > > this way. > > Obviously, the notion of simple performance scalability is one way > > to look > > at. There is a lot of capability in the NoB, but I think it falls > > a bit > > short. There are a few features that we'd like to see, that would > > help us > > federate better. BC/SE/SA-level authentication to the bus, as well as > > platform-to-platform, or NMR-to-NMR authe
Re: ServiceMix 4.0
On 8/24/07, Adrian Co <[EMAIL PROTECTED]> wrote:
> Not sure if this is the right forum to bring this up, but I was
> wondering if this is a good opportunity to migrate some of servicemix's
> infra to newer version.
>
> i.e.
>
> 1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
> I'm not sure if its a better option, but I did hear some good stuff
> about it.
Why not ? I'm not sure about the pros and cons here, but I'm open :-)
> 2. Upgrade to junit 4.x (Port the existing test cases maybe?)
+1 to move to junit 4 (or testng ? i haven't tried any)
>
> and maybe others.
>
> Just my 2 cents. :)
>
> Daryl Richter wrote:
> >
> > On Aug 23, 2007, at 4:21 PM, Bruce Snyder wrote:
> >
> >> On 8/23/07, Kit Plummer <[EMAIL PROTECTED]> wrote:
> >>
> >>> I've used MagicDraw on OS X. It's pretty terrible...but does work for
> >>> sequence diagrams. I'm not sure if they have a "free" version or not.
> >>> Doesn't OmniGraffle do some UML stuff too?
> >>
> >> Yeah I've used MagicDraw in the past. Unfortunately the free version
> >> doesn't generate sequence diagrams and that's the key for me. I want
> >> the ability to have the tool generate UML from the source and that's
> >> hard to find in a free tool.
> >
> > Yes, I agree. JUDE can generate UML from source, though it doesn't
> > support Java 1.5 annotations. It does make nice sequence diagrams and
> > is a nice tool to work with, in general.
> >
> >>
> >> Bruce
> >> --
> >> perl -e 'print
> >> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E >> );'
> >>
> >> Apache ActiveMQ - http://activemq.org/
> >> Apache ServiceMix - http://servicemix.org/
> >> Apache Geronimo - http://geronimo.apache.org/
> >> Castor - http://castor.org/
> >
> > --
> > Daryl
> > http://itsallsemantics.com
> >
> >
> >
>
>
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4.0
Not sure if this is the right forum to bring this up, but I was
wondering if this is a good opportunity to migrate some of servicemix's
infra to newer version.
i.e.
1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
I'm not sure if its a better option, but I did hear some good stuff
about it.
2. Upgrade to junit 4.x (Port the existing test cases maybe?)
and maybe others.
Just my 2 cents. :)
Daryl Richter wrote:
On Aug 23, 2007, at 4:21 PM, Bruce Snyder wrote:
On 8/23/07, Kit Plummer <[EMAIL PROTECTED]> wrote:
I've used MagicDraw on OS X. It's pretty terrible...but does work for
sequence diagrams. I'm not sure if they have a "free" version or not.
Doesn't OmniGraffle do some UML stuff too?
Yeah I've used MagicDraw in the past. Unfortunately the free version
doesn't generate sequence diagrams and that's the key for me. I want
the ability to have the tool generate UML from the source and that's
hard to find in a free tool.
Yes, I agree. JUDE can generate UML from source, though it doesn't
support Java 1.5 annotations. It does make nice sequence diagrams and
is a nice tool to work with, in general.
Bruce
--
perl -e 'print
unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
--
Daryl
http://itsallsemantics.com
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
I'm interested too. Brian O'Neill wrote: Yes. I'm in. -brian On 8/24/07, Gordon Dickens <[EMAIL PROTECTED]> wrote: I too would like to listen in. Regards, Gordon Daryl Richter wrote: On Aug 24, 2007, at 5:04 AM, Nodet Guillaume wrote: Any other people interested ? I wouldn't mind listening in. We are in the very early stages of a ServiceMix implementation, though, so I don't have a lot of opinions... yet. :) Cheers, Guillaume Nodet -- Daryl http://itsallsemantics.com "We want great men who, when fortune frowns, will not be discouraged." -- Colonel Henry Knox, 1776
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Yes. I'm in. -brian On 8/24/07, Gordon Dickens <[EMAIL PROTECTED]> wrote: > I too would like to listen in. > > Regards, > Gordon > > Daryl Richter wrote: > > On Aug 24, 2007, at 5:04 AM, Nodet Guillaume wrote: > > > > > >> Any other people interested ? > >> > >> > > > > I wouldn't mind listening in. We are in the very early stages of a > > ServiceMix implementation, though, so I don't have a lot of > > opinions... yet. :) > > > > > > > >> Cheers, > >> Guillaume Nodet > >> > >> > >> > > -- > > Daryl > > http://itsallsemantics.com > > > > "We want great men who, when fortune frowns, will not be discouraged." > > -- Colonel Henry Knox, 1776 > > > > > > > > > > > > > > > > > > -- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
I would like to attend this even. Please let me know the details. On 8/24/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > > Any other people interested ? > > Cheers, > Guillaume Nodet > > On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote: > > > I'd be up for a few chat sessions! > > > > On 8/23/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > >> > >> Btw, if there is sufficient interest, we could organize irc meetings > >> to discuss these topics and post the log to the dev list for > >> archiving > >> and later discussion. > >> > >> Cheers, > >> Guillaume Nodet > >> > >> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote: > >> > >>> As I explained in the other thread, I've been working on a new API > >>> for ServiceMix 4.0. > >>> Hopefully this will serve as an input for JBI 2.0. > >>> This API is available at https://svn.apache.org/repos/asf/ > >>> incubator/servicemix/branches/servicemix-4.0/api > >>> > >>> So here a few key changes: > >>> * clean integration with OSGi > >>> * the NormalizedMessage can contain not only XML > >>> * no more components > >>> * no more JBI packaging (just use OSGi bundles) > >>> * move the Channel to the Endpoint > >>> * use push delivery instead of pulling exchanges > >>> * introduce a single interface for identifying the Target of an > >>> Exchange > >>> > >>> As we remove components, everything goes down to the endpoint which > >>> become a key feature. > >>> > >>> The endpoint must implement the Endpoint interface. In OSGi, the > >>> NMR would listen to endpoints > >>> registered in the OSGi registry and call the registry to register / > >>> unregister the endpoints. > >>> As part of the endpoint registration, the NMR would inject a > >>> Channel into them, thus actually activating the > >>> endpoint. I guess I could write a sequence diagram for that > >>> (anybody knows a good tool for uml ?). > >>> In a non OSGI environment, the Endpoint will be registered in the > >>> Registry by calling the register method > >>> somehow. > >>> > >>> The Endpoint receives Exchange to be processed on the process > >>> method. > >>> I think we should keep the JBI 1.0 semantics and the endpoint use > >>> the same process as for JBI 1.0, which is > >>> send the exchange back using the Channel (with the response / > >>> fault / error / done). This will put the threading, > >>> transactions and security burden on the container itself. Which > >>> means it is easier to write JBI apps :-) > >>> > >>> Exchanges can be created using the Channel#createExchange method. > >>> The only change I'd like to > >>> integrate in the messaging API is to allow for non xml payloads and > >>> maybe untyped attachments. The body > >>> could be converted automatically to a given type if supported (I > >>> think Camel does it nicely, so I'm thinking of > >>> shamelessly copying the converter layer). I have added a few > >>> helper methods on the exchanges and > >>> messages (copy, copyFrom, ensureReReadable, display) to ease > >>> message management. > >>> > >>> For the deployment part, there is no packaging anymore. One would > >>> deploy an OSGi bundle that would > >>> register the needed endpoints in the OSGi registry. For certain > >>> types of endpoints, we may need an external > >>> activation process (such as creating a server socket for listening > >>> to HTTP requests) that may need to be shared > >>> across endpoints of a given type. In such a case, you would deploy > >>> a "component" that listens to new > >>> endpoints implementing HttpEndpoint for example. When a new > >>> endpoint is registered, the listener would > >>> activate a server socket that could be shared across all http > >>> endpoints. In a different way, if we have a BPEL > >>> engine, the bpel "component" would listen for new bundles and look > >>> for a specific file containing deployment > >>> information. The component would register new endpoints in the OSGi > >>> registry as needed (we could do that > >&
Re: ServiceMix 4.0 and type converters
On Aug 23, 2007, at 1:48 PM, James Strachan wrote: I thought I'd spin up another thread on this... On 8/23/07, Brian O'Neill <[EMAIL PROTECTED]> wrote: On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: Exchanges can be created using the Channel#createExchange method. The only change I'd like to integrate in the messaging API is to allow for non xml payloads and maybe untyped attachments. The body could be converted automatically to a given type if supported (I think Camel does it nicely, so I'm thinking of shamelessly copying the converter layer). I have added a few helper methods on the exchanges and messages (copy, copyFrom, ensureReReadable, display) to ease message management. I haven't looked at Camel converters, but would you consider adding a contentType and contentEncoding mimicing the headers of HTTP & SIP. The endpoint can then use the type and encoding to determine how to handle the content. Incidentally thats come up recently in Camel too; the type converter stuff is so useful, folks wanna use it for many different things when the Java class/interface is not enough to specify a conversion. e.g. convert to Java Object using JAXB2 versus serialization versus SOAP encoding I guess this is no longer type conversion, but more content conversion - so maybe a separate API is required. But certainly folks wanna be able to do things like // specify the required Java type and content type InputStream in = message.getBody(InputStream.class, "application/ xml"); But am wondering if for things like content type / content encoding stuff we need a separate kind of mechanism than the Java type conversion stuff; or if we could just extend the model to include content type as well? I agree. The type converter api is not necessarily the best suited for our needs here and may be more suited for converting properties rather than the body. There are lots of different things here. We need to be able to send xml documents, binary streams and POJOs: this would cover most of the needs I guess. Then, some content type may be able to be converted from one format to another: a jaxb2 pojo may be transformed to xml, a JSON stream may be converted to xml too using http://jettison.codehaus.org/), but I'm not sure how far we should go as there may be lots of different ways to convert data between different formats. Complex transformations may need to be more tightly controlled by using an endpoint. Cheers, Guillaume Nodet -- James --- http://macstrac.blogspot.com/
Re: ServiceMix 4.0
On Aug 22, 2007, at 10:59 AM, Nodet Guillaume wrote: [snip] (anybody knows a good tool for uml ?). Take a look at JUDE Community Edition. Works great for me. http://jude.change-vision.com/jude-web/product/community.html [snip] Cheers, Guillaume Nodet -- Daryl http://itsallsemantics.com "I see this as coming down to mutual respect. I want to respect the others I communicate with enough to tell them my truth without reservation and I want to respect them enough to listen to their truth. I want to respect their good intentions enough to believe that we can work past our disagreements." -- Kent Beck, 2006
Re: ServiceMix 4.0
On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > As I explained in the other thread, I've been working on a new API > for ServiceMix 4.0. > Hopefully this will serve as an input for JBI 2.0. > This API is available at https://svn.apache.org/repos/asf/incubator/ > servicemix/branches/servicemix-4.0/api > > So here a few key changes: >* clean integration with OSGi >* the NormalizedMessage can contain not only XML >* no more components >* no more JBI packaging (just use OSGi bundles) >* move the Channel to the Endpoint >* use push delivery instead of pulling exchanges >* introduce a single interface for identifying the Target of an > Exchange Sounds great! How far have you got implementing this? :) > As we remove components, everything goes down to the endpoint which > become a key feature. > > The endpoint must implement the Endpoint interface. In OSGi, the NMR > would listen to endpoints > registered in the OSGi registry and call the registry to register / > unregister the endpoints. > As part of the endpoint registration, the NMR would inject a Channel > into them, thus actually activating the > endpoint. I guess I could write a sequence diagram for that (anybody > knows a good tool for uml ?). > In a non OSGI environment, the Endpoint will be registered in the > Registry by calling the register method > somehow. > > The Endpoint receives Exchange to be processed on the process method. > I think we should keep the JBI 1.0 semantics and the endpoint use the > same process as for JBI 1.0, which is > send the exchange back using the Channel (with the response / fault / > error / done). This will put the threading, > transactions and security burden on the container itself. Which > means it is easier to write JBI apps :-) > > Exchanges can be created using the Channel#createExchange method. > The only change I'd like to > integrate in the messaging API is to allow for non xml payloads and > maybe untyped attachments. The body > could be converted automatically to a given type if supported (I > think Camel does it nicely, so I'm thinking of > shamelessly copying the converter layer). I'd hope we can easily just wire in camel-core as the default type converter layer implementation as we've got most common type conversions sorted now along with a simple extension mechanism to support any type conversions. i.e. you should be able to invoke the type conversion stuff without the SMX API having any hard dependency on Camel - let it be just an implementation detail. > I have added a few helper > methods on the exchanges and > messages (copy, copyFrom, ensureReReadable, display) to ease message > management. > > For the deployment part, there is no packaging anymore. One would > deploy an OSGi bundle that would > register the needed endpoints in the OSGi registry. For certain > types of endpoints, we may need an external > activation process (such as creating a server socket for listening to > HTTP requests) that may need to be shared > across endpoints of a given type. In such a case, you would deploy a > "component" that listens to new > endpoints implementing HttpEndpoint for example. When a new endpoint > is registered, the listener would > activate a server socket that could be shared across all http > endpoints. Interesting differentiation between component and endpoint; I like it. > In a different way, if we have a BPEL > engine, the bpel "component" would listen for new bundles and look > for a specific file containing deployment > information. The component would register new endpoints in the OSGi > registry as needed (we could do that > for jaxws pojos using cxf for example). I wonder should we come up with some standard OSGi metadata that components should try adopt to know when to auto-detect things like HttpEndpoint or BPEL. I guess component developers can do whatever they like but it might be nice to at least document some guidelines for nicely behaving components > So I said there is no more components, because this feature is not in > the api anymore, but we will certainly need > these components for some use cases. For simple endpoints, you > would not need any component at all. > Another benefit is that you can easily deploy a whole application > inside a single OSGi bundle. Using spring-osgi, > the bundle would just consist in a spring configuration file > containing the endpoints declaration and expose them > as OSGi services. > > Of course, we need to write a JBI 1.0 compatibility layer, and we > could have an intermediate layer where SAs and > JBI components could be OSGi bundles directly, thus leveraging the > OSGi classloading mech
Lifecycle and governance (was Re: ServiceMix 4.0)
Terry, I'm just starting a new thread here so that it will be easier to follow the discussions. Any ideas are welcome... Cheers, Guillaume Nodet On Aug 23, 2007, at 1:00 AM, Terry Cox wrote: Interesting. We need to have a very serious chat about application lifecycles and governance... Terry
ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Hi Kit, I'm quite sure you would have a very valuable input there, given your experience on ServiceMix. So I'm starting this new thread. Would you mind throwing a few ideas there ? Cheers, Guillaume Nodet On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote: On 8/22/07, Terry Cox <[EMAIL PROTECTED]> wrote: Interesting. We need to have a very serious chat about application lifecycles and governance... Terry And Federating...distribution of the NMR across n-platforms! -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
