Hi Jonah,
This is quite comparable to micro-services - each service is an abstraction
or at least a facade and wants to play in a bigger system, but each
micro-service may itself have its own stateful graph to maintain.
I think I will explore my original direction of having a
AComponentWhichDrivesAnEntireSystem and see how far I get with that.
On Wednesday, 11 March 2015 20:53:45 UTC, jonah wrote:
>
> 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...@gmail.com
> <javascript:>> 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...@mail.yu.edu <javascript:>> 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 clo...@googlegroups.com
>> <javascript:>
>> > 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 <javascript:>
>> > 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 <javascript:>.
>> > 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 clo...@googlegroups.com
>> <javascript:>
>> 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 <javascript:>
>> 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 <javascript:>.
>> 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.
