Author Topic: Best practice for design patterns  (Read 195 times)


  • EA Novice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Best practice for design patterns
« on: September 07, 2011, 07:47:27 pm »

For an integration project, we want to design re-usable integration patterns in a way that you only specify behaviour and structure once and then "reference" the result in several ocurrences (actual integrations).

The idea is that such an integration always has to perform the same sequence of steps for converting from incoming format/protocol to outgoing format/protocol, with only a fixed set of properties (like the actual WSDL to use, or certain configurations for the flow) varying between the different occurrences.
I'd like these to be configurable on the instance, whereas the "inner doings" of the integration patterns would be the same for all.

As we're still in the design phase, changes and updates to both behaviour and structure are likely. I'm looking for a best practice of how I can achieve the desired behaviour.

Options I've been looking at (in EA 9.0):
- Actual design patterns: ... instantiate the corresponding elements. However, the reference to the original pattern is lost once instantiated, at least I didn't see how to get back to it.
- Collaboration: "A Collaboration defines a set of cooperating roles and their connectors." That would be an ideal match, but when I do a role-binding, the role-binding connector seems to accept free-text values but is not limited to a defined role.
- Components and component instances: Specifying integration patterns as components with named (not typed - typing leads to huge port sizes) ports providing/requiring interfaces. Ports are connected to parts. "Inner doings" are modelled as composite diagrams. However, when I delete or add ports in the original component, the removal/adding is not propagated (though updates of existing ports are). Besides, it basically obliges to model everything as a type of interface.

For the moment, I'll stick to the last idea. But as removals/adding of ports are not propagated, it is still sub-optimal.

Do you have any other suggestions for modeling the desired behaviour?
Is there a way of propagating removals/addings of ports?

Ciao, Philipp