The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

dvorme (14) [Avatar] Offline
#1
The second paragraph in chapter 6 opens with, "Unsurprisingly, Mule supports its own component model".

Thinking as an architect, that actually is a _HUGE_ surprise. I mean:

* What's wrong with all the existing component models that MuleSoft had to invent yet another one?

* What are the benefits of Mule's new component model compared with all the other ones and why would I want to use it instead of those?

* How does Mule's new component model interoperate with the others? In particular, with JavaBeans and with Spring Beans, a Java programmer's bread and butter respectively?

Second, if Mule's component model is shiny and new, then what is it? How do I build a Mule component as distinct from a JavaBean or a Spring Bean or ....? I've gotten down "6.1.2 Resolving the entry point" and I still don't know.

I think you can assume that your readers are familiar enough with Java to at least know JavaBeans, and probably also be familiar with Spring Beans.

Please allow me to say the same thing a second way in order to spell out my expectations a bit more clearly:

After saying "Mule supports its own component model", this reader's next questions are (and probably a lot of other readers also):

1) Why yet another component model? How does it compare/contrast with other preexisting models?
2) What is it? What ingredients does it have? What rules must it follow?

Then, where you go next makes sense to me:

3) What sorts of things make sense to implement using Mule components?
4) How do I wire them up?

Or am I missing something?

Hope this helps.


Regards,

Dave
dvorme (14) [Avatar] Offline
#2
Re: "Unsurprisingly, Mule supports its own component model"
OK, a closer reading and I'd like to be sure I'm understanding.

A Mule component is:

1) A random Java object with zero dependencies on Mule. (Section 6.1.1 doesn't say how this can be useful but I'm imagining that Mule will use naming conventions to inject useful things into the object?)
2) A random Java object with annotations to help Mule know what/where to inject.
3) A class implementing Mule's Callable.

Suggestion: If I've got it right, you may want to start out the chapter just by listing these three things, then elaborating on each of them in turn. If I've got it wrong... well, then that probably means either I haven't read carefully enough or maybe it could be written a bit more clearly. smilie


Regards,

Dave
dvorme (14) [Avatar] Offline
#3
Re: "Unsurprisingly, Mule supports its own component model"
OK; I see what's confusing me here. Section 6.1, first paragraph advertises itself as being about when I would want to use Mule components. However, it also mixes in discussion about what a Mule component is to begin with. I suggest splitting those two topics out of section 6.1 and covering each in its own section.


Regards,

Dave