Hey Colin, it sounds like:
* if the 2 systems really can't function without each other, and their
start/stop lifecycles are tightly bound, then somehow they have to be
merged into a single system
or
* if the 2 systems can't be merged into a single system because of true
functional or lifecycle independence and non-overlapping dependencies, then
semantics for what it means for each system to not have the other available
at lifecycle event times have to be established
It smells like the latter may be the way to go. So in pseudocode, the
reusable-component-system that "owns" the reusable-component would not
receive an instance of the external-collaborator at creation time. Instead,
the reusable-component would have a somewhat weaker definition of its start
semantics, and perhaps would have a way to refer to the
external-collaborator only by name.
That is, perhaps the external-collaborator provided to the
reusable-component is really an external-collaborator-client that is
configured to know the name of the external-collaborator- which is owned by
larger-system- and shields the reusable-component in cases where the larger
system has not been started or the collaborator isn't available.
And perhaps similarly the larger-system has a reusable-component-client or
reusable-client-proxy that is able to bridge appropriately from
larger-system to the reusable-component.
And maybe both client components are configured with the same :bus for
cross-system communication (and perhaps the cross-system bus is owned by a
bridge system). Just riffing, as it's not precisely clear what the
semantics of the systems are.
Stuart's comment that he hasn't run into a need for systems of systems is
coming to mind. Perhaps it makes sense to break these apart more explicitly
in accordance with guidelines around managing micro-services. Easy to say,
of course. :)
Not sure if that's helpful....
Jonah
On Wed, Mar 11, 2015 at 3:01 PM, Colin Yates <colin.ya...@gmail.com> wrote:
> merge won't help as there will be name space clashes.
>
> I wonder if a more elegant approach would be to construct the 'inner'
> system and then assoc onto it the external dependencies it needs
> before calling start.
>
> On 11 March 2015 at 18:49, <adrian.med...@mail.yu.edu> wrote:
> > I believe I misunderstood your question; I didn't realize it was system
> (as
> > opposed to any general component) specific. I think systems can be merged
> > together (via 'merge'). Would that help?
> >
> > On Wednesday, March 11, 2015 at 2:40:14 PM UTC-4, Colin Yates wrote:
> >>
> >> Hi Adrian - I don't follow how that helps integrate two different
> >> systems - I wonder if my question was unclear or I am missing
> >> something in your answer. Would you mind posting some pseudo code to
> >> clarify please?
> >>
> >> On 11 March 2015 at 18:32, <adrian...@mail.yu.edu> wrote:
> >> > You can specify component dependencies using the 'using' function as
> you
> >> > know. As long as you know the key of the component in the system you
> can
> >> > specify this dependency wherever you construct the component. If you
> >> > want to
> >> > parameterize dependencies, write a constructor function which takes
> the
> >> > external dependency as a value.
> >> >
> >> > On Wednesday, March 11, 2015 at 2:17:12 PM UTC-4, Colin Yates wrote:
> >> >>
> >> >> I have a non-trivial component which requires a bunch of internal and
> >> >> external collaborators to work. This component is itself re-usable.
> >> >>
> >> >> What I really want to do is have ReusableComponent be a component in
> a
> >> >> system so it can pull its external collaborators. However,
> >> >> ReusableComponent
> >> >> constructs its own services etc. so it really want to be (or at least
> >> >> have
> >> >> access to) a system.
> >> >>
> >> >> For example, let's say I have the following:
> >> >>
> >> >> (defrecord InternalToReusableComponent [bus]
> >> >> (component/Lifecycle
> >> >> (start [this]...))
> >> >>
> >> >> (defrecord ReusableComponent [bus logger]
> >> >> (component/Lifecycle
> >> >> (start [this]
> >> >>
> >> >> this)
> >> >> ....))
> >> >>
> >> >> (defn reusable-component-system [external-collaborator]
> >> >> (component/system-map
> >> >> :bus (....)
> >> >> :logger (....)
> >> >> :reusable-component (component/using (map->ReusableComponent {})
> >> >> [:bus
> >> >> :logger external-collaborator]))
> >> >>
> >> >> Fine - I now have a system from which I can pull the reusable
> >> >> component.
> >> >> However, where does 'external-collaborator' come from? Obviously
> there
> >> >> is a
> >> >> larger system which I want this component to be part of so I can do:
> >> >>
> >> >> (defn larger-system []
> >> >> (component/system-map
> >> >> :external-collaborator (...)
> >> >> :reusable-component (component/using (some-magic-glue)
> >> >> [:external-collaborator])))
> >> >>
> >> >> I am struggling to see what (some-magic-glue) should be. I imagine it
> >> >> needs to be something like:
> >> >>
> >> >> (defrecord SystemAdaptor [external-collaborator internal-system]
> >> >> component/Lifecycle
> >> >> (start [this]
> >> >> (let [internal-system (or internal-system
> >> >> (reusable-component-system
> >> >> external-collaborator))
> >> >> internal-system (component/start internal-system)]
> >> >> (assoc this :internal-system internal-system)))
> >> >> (stop [this]
> >> >> (let [internal-system (:internal-system this)
> >> >> internal-system (component/stop internal-system]
> >> >> (assoc this :internal-system internal-system)))
> >> >>
> >> >> but it all feels a bit yuck.
> >> >>
> >> >> I can't merge the two systems because the reusable component is
> chocka
> >> >> full of very fine grained command handlers and both the internal and
> >> >> external systems will have their own 'bus' for example. I could
> >> >> namespace
> >> >> the keys but that again feels painful...
> >> >>
> >> >> Hope that is clear - and I look forward to your thoughts :).
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Clojure" group.
> >> > To post to this group, send email to clo...@googlegroups.com
> >> > Note that posts from new members are moderated - please be patient
> with
> >> > your
> >> > first post.
> >> > To unsubscribe from this group, send email to
> >> > clojure+u...@googlegroups.com
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/clojure?hl=en
> >> > ---
> >> > You received this message because you are subscribed to the Google
> >> > Groups
> >> > "Clojure" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send
> >> > an
> >> > email to clojure+u...@googlegroups.com.
> >> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
