1 / 8

A comparison of DADL Conversations and CORBA’s Interface Definition Language

A comparison of DADL Conversations and CORBA’s Interface Definition Language. Cheng Tan chengtan@cs 12/2/98. Project Goals. See how conversations in DADL are different from CORBA IDL To explore the architectural implications of an early focus on conversations

evania
Download Presentation

A comparison of DADL Conversations and CORBA’s Interface Definition Language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A comparison ofDADL Conversationsand CORBA’sInterface Definition Language Cheng Tan chengtan@cs 12/2/98

  2. Project Goals • See how conversations in DADL are different from CORBA IDL • To explore the architectural implications of an early focus on conversations • Look at good conversation design

  3. CORBA IDL • Language for interface description • Adornments for parameters • Adornments for function synchronicity • Using IDL is not much different from declaring a class’s public interface in C++ • Fundamentally, no new paradigm

  4. DADL Conversations • Conversations add a temporal dimension to component interactions • Glue that binds components together • Reusable unit of interaction that is independent of the things that interact • Conversations maintain the abstraction of the components • Different from traditional programming where connection mechanisms are chosen very early on

  5. Architectural Implications • Postpone object or component level commitments during design time • Traditionally, conversation is the by product of functionality • Object commitments tend to be of the sort that make reuse or change more difficult • Early in design, it is often easier and more productive to deal with component interactions without committing to objects that support them

  6. Conversational Patterns • We’re most familiar with decomposition to the level of simple transactions - interrogation, delegation • Look for fundamental qualities imparted to systems by various interconnection strategies • Look at more complex conversational models and draw from them - SMTP, HTTP • Types • Goal oriented • Negotiated / deal making / bidding • Collaborative, multiway • Good conversational patterns may drive or suggest architectural choices

  7. Conclusions thus far • Productive to focus on conversational aspect of design from the start • Nice way to encapsulate features, services and responsibilities without knowing, caring about, committing to, revealing or representing particular objects • Promising avenue for component reuse

  8. References • Burback, R. – A Distributed Architecture Definition Language, 1997. • Buschmann, F. (ed) – Pattern Oriented Software Architecture: A System of Patterns, John Wiley, 1996. • Knapik, M. and Johnson, J. – Developing Intelligent Agents for Distributed Systems, McGraw Hill, 1998. • Orfali, Harkey and Edwards – The Essential Distributed Objects Survival Guide, Van Nostrand Reinhold, 1994. • Szyperski, C. – Component Software, ACM Press, 1998. • Wong, C. – Web Client Programming, O’Reilly & Associates, 1997. • DARPA EDCS – http://www.sei.cmu.edu/community/edcs

More Related