Connectors

1. Connectors Mads Ingstrup Week 39

2. References • Shaw, Mary. Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status. Proceedings of the Workshop on Studies of Software Design, LNCS, Springer-Verlag, 1994. • Mehta, Nikunj R., Medvidovic, Nenad and Phadke, Sandeep. Towards a Taxonomy of Software Connectors. Proceedings of ICSE 2000. • Aldrich, J., Sazawal, V., Chambers, C., and Notkin, D. Language support for Connector Abstractions.

3. [Shaw]: Current Practise • There is a mismatch between how relations among components are described using sophisticated abstract patterns, and the vocabulary available to implement them in programming languages: • information about interactions is distributed • abstractions are poor (boxes and lines) • Lack of structure on interface definitions (abstractions for connections & Segmentation of interfaces). • Mixed concerns in progr. lang. : designed to express algorithms >> lack of expressiveness wrt. system topology; capabilities of components; interactions between them. (ex: Interactions are encoded as sequences of procedure calls.

4. [Shaw]: Current Practise • Poor support for multi-language/paradigme systems: often connections between components depend directly on programming languages. • Poor support for legacy systems: over half of system maintenance effort goes into deciphering what the software already does; this is (partly) because there is not mechanism for recording and retaining the designers higher-level intentions about component interactions.

5. [Shaw]: A Fresh View on SW Interconnection • Components roughly correspond to compilation units of conventional prog. lang. • ”Connectors mediate interactions among components, that is, they establish the rules that govern component interaction and specify any auxiliary mechanisms required.” • A Connector has a protocol specification, a type, and a set of roles: • A protocol specifies rules about types of interfaces that can be mediated for, rules about the order of things to happend, and commitments about the interactions e.g. performance. • A connector is of a type or subtype. (rpc, pipeline, broadcast, event). • The roles of a connector are the named entities in its protocol.

6. [Shaw]: A Fresh View on SW Interconnection • Connectors should be treated differently from components because: • They may be quite sophisticated • The definition of a connector should be localized • Some kinds of information does not properly belong in any component. • Connectors are potentially abstract • Components should be independent, and so should connectors • Relations among components are not fixed.

7. [Shaw]: Arch Lang. w. first-class Connectors • An AL with first-class connectors must: • Define semantics for conn. & comp. • Establish type structures for system organizations, components, connnectors and the primitive units of association between these elements. • Set out appropriate rules for architectural abstractions • Generalize the import/export rules to address assymetry, multiplicity, locality, abstraction and naming. • ”An AL must support … high-level compositions that involve a number of connectors in specific relations to one another. For example a language must be capable of capturing the hith-level architectural idioms such as blackboards etc.” • QUESTION: Do ADL’s adhere to these requirements ? • AL needs separate (but parallel) constructs for components and connectors • Connectors are less obviously objects of design than are components; they do not have code.

8. [Mehta et al.] • The underlying primitive building blocks of every connector are: • the primitives for changing the processor program counter (control transfer) • performing memory access (data transfer). • In addition, every connector mainitains one or more ducts (Synonyms for duct: tube, channel, canal, passage)

9. In the taxonomy each connector is characterized byService Category, Type, Dimension, Sub-dimension, and Value: • The Service Category is the broad interaction category the connector fulfills. • Different types of connectors realize interaction services (example types: procedure call, event, stream) • Dimensions and sub-dimensions of a connector captures the architecturally relevant details of that type of connector. • A set of values that a dimension can take. (e.g. the dimension synchronicity can have values {synchronous, asynchronous})

10. Sample: Communication/Coordination

11. Service Categories • Coordination (transfer of control) • Conversion (convert interactions) • Facilitation (e.g. load balancing, links between compile-time components that enable/faciliatat e.g. communciation) • Communication (transmission of data)

12. Types • Procedure Call • Event • Data Access • Linkage • Stream • Arbitrator (decide/negotiate) • Adaptor • Distributor (e.g routing and other network services) • QUESTION: The Distributor connector-type in a sense specifies a type of connection that is at a level below the application layer (in ISO’s OSI model). Is e.g. a physical wire then also relevant to consider as a connector type ? (RS232?)

13. [Aldrich et al.] • A component is a special kind of object that communicates with other components in a structured way. • Components communicate through ports • A port declares provided and required methods. • A port interface declares the type of a port; used when there may be several instances of that port.

15. public component class PoemPeer { public port search { provides PoemDesc[] search(PoemDesc partialDesc) throws IOException; provides void downloadPoem(PoemDesc desc) throws IOException; } public port poems { requires PoemDesc[] getPoemDescs(); requires Poem getPoem(PoemDesc desc); requires void addPoem(Poem poem); } public port interface client { requires client(InetAddress address) throws IOException; requires PoemDesc[] search(PoemDesc partialDesc, int hops, Nonce n); requires Poem download(PoemDesc desc); } public port interface server { provides PoemDesc[] search(PoemDesc partialDesc, int hops, Nonce n); provides Poem download(PoemDesc desc); } void downloadPoem(PoemDesc desc) throws IOException { client peer = new client(desc.getAddress()); Poem newPoem = peer.download(desc); if (newPoem != null) { poems.addPoem(newPoem); } } // other method definitions... }

16. public component class PoemSwap { private final SwapUI ui = new SwapUI(); private final PoemStore store = new PoemStore(); private final PoemPeer peer = new PoemPeer(); connect pattern SwapUI.poems, PoemStore.poems; connect pattern PoemPeer.poems, PoemStore.poems; connect pattern SwapUI.search, PoemPeer.search; public PoemSwap() { TCPConnector.registerObject(peer, POEM_PORT, “server”); connect(ui.poems, store.poems); connect(peer.poems, store.poems); connect(ui.search, peer.search); } connect pattern PoemPeer.client, PoemPeer.server with TCPConnector { client(PoemPeer sender, InetAddress address) throws IOException { connect(sender.client, PoemPeer.server) with new TCPConnector(address, POEM_PORT, “server”); } }; }

17. public class TCPConnector extends Connector { // data members protected TCPEndpoint endpoint; // public interface public TCPConnector(InetAddress host, int prt, String objName) throws IOException { endpoint = new TCPEndpoint(this, host, prt, objName); } public Object invoke(Call call) throws Throwable { Method meth = call.getMethod(); return endpoint.sendMethod(meth.getName(), meth.getParameterTypes(), call.getArguments()); } public static void registerObject(Object o, int prt, String objName) throws IOException { TCPDaemon.createDaemon(prt).register(objName, o); } // interface used by TCPDaemon TCPConnector(TCPEndpoint endpoint, Object receiver, String portName) { super(new Object[] { receiver }, new String[] { portName }); this.endpoint = endpoint; endpoint.setConnector(this); } Object invokeLocalMethod(String name, Type parameterTypes[], Object arguments[]) throws Throwable { // find method with parameters that match parameterTypes Method meth = findMethod(name, parameterTypes); return meth.invoke(arguments); } // typechecking semantics defined in Figure 5 }