Workshop on Compositional Software Architectures

Monday, January 5, 1998

• 7:00 pm - 8:00 pm - Registration desk open

Tuesday, January 6, 1998

• 7:00 - 8:00 am - Registration and Continental Breakfast

 
• 8:00 - 8:30 - Problem Domain and Workshop Goals - San Carlos Ballroom
• Dave Curtis, Object Management Group, Workshop Sponsor
• Todd Carrico, DARPA, Workshop Sponsor
• Ted Linden, Microelectronics and Computer Technology Corporation, Workshop Co-Organizer
• Craig Thompson, Object Services and Consulting, Inc., Workshop Co-Organizer
 
• 8:30 - 10:10 - Presentations - San Carlos Ballroom
• David Garlan, Higher Order Connectors, Carnegie Mellon University (cancelled due to illness)
• Umesh Bellur, The Role of Components & Standards in Software Reuse, Oracle
• Richard  Schantz, Distributed Objects with Quality of Service, BBN
• Stephen Milligan, Large-Scale Agent Architectures, GTE/BBN Technologies
• Michael Pizzo, OLE DB, Microsoft

 
• 10:30 - 11:50 - Presentations - San Carlos Ballroom
• Bill Janssen, W3C HTTP-NG, Xerox PARC
• Rohit Khare, Protocol Extensions Protocol, University of California at Irvine
• Ora Lassila, Resource Description Framework, Nokia Research Center and W3C
• Jay M. Tenenbaum, Eco System: An Internet Commerce Architecture, CommerceNet
 
• 11:50 - 12:00 - Breakout Session Instructions

 
• 12:00 - 1:00 - Lunch - provided - Three Flags Cafe

 
• 1:00 - 1:50 - Dave Curtis, A Comparison of Component Models, OMG

 
• 2:00 - 4:30 - Breakout Sessions I  (see descriptions below)
• I-1 Problem Definition by Application Architects - From the large application builder's perspective, component software is an enticing vision but there are roadblocks in the way of realizing the benefits.
• I-2 Extending Current Middleware Architectures - From the viewpoint of middleware architects, where are the critical shortcomings in current technology, what kinds of component-based development can be supported in the future, and what are the additional key architectural concepts, tools, and processes needed to realize this vision.
• I-3 Challenging Problems in Middleware Development - This session views component composition from the point of view of middleware developers and system programmers.  The approach is to select one or two interesting system software component composition challenge problems that can be used to identify component software strengths and weaknesses.
• I-4 Software Architecture and Composition - What is the vision of component composition from the software architecture theorists' perspective?  What does software architecture explain about architecture composition and what does it not yet address?
 
• 5:00 - 6:00 - Summary - Plenary Session in San Carlos Ballroom
 
• 6:30 - 8:00 - Reception - cash bar - Salon 207 & 209

Wednesday, January 7, 1998

• 7:30 - 8:30 Continental Breakfast

 
• 8:30 - 10:30 - Breakout Sessions II  (see descriptions below)
• II-1 Economy of Component Software - The purpose of this session is to develop a framework for thinking about what it will take to build an economy of component software to accelerate a coming economy of components.
• II-2 Component Model Representation and Composition - Component models expose information about how a thing is constructed, which is needed for replacing parts and for providing higher order services.  What information should be exposed?  What is the nature of the glue?
• II-3 System-wide Properties or Ilities - How does one achieve system-wide properties when composing components. How can we separate application logic from ility implementation?
• II-4 How do these fit in? - Few position papers directly covered views, managing inconsistency, optimization versus modularity, or APIs versus protocols.  But we'll need to understand these topics to fully understand architectures and component technology.

 
• 11:00 - 12:00 - Summary - Plenary Session in San Carlos Ballroom

 
• 12:00 - 1:00 - Lunch - provided - Three Flags Cafe

 
• 1:00 - 1:50 - Gregor Kiczales, Aspect-Oriented Programming, Xerox PARC

 
• 2:00 - 4:30 - Breakout Sessions III  (see descriptions below)
• III-1 Scaling component software architectures - What family of design patterns can be used to scale component software -- federation, decentralized or autonomous control, metadata, caching, traders, repositories, negotiation, etc. in this environment.
• III-2 Adaptivity of component software architectures - Is there a common component software framework that allows us to build software that is adaptable, customizable, evolvable, secure, and survivable?
• III-3 Quality of Service - What are the main concepts?  How do you insert QoS into an environment.  What are the tradeoffs if applications are QoS-unaware versus QoS-aware.
• III-4 ORB and Web Integration Architectures - ORB and web architectures will increasingly overlap in function.  How can we avoid recreating the same set of services like versioning for both architectures?
 
• 5:00 - 6:00 - Summary - Plenary Session in San Carlos Ballroom

Thursday, January 8, 1998

• 7:30 - 8:30 Continental Breakfast

 
• 8:30 - 10:30 - Breakout Sessions IV  (see descriptions below)
• IV-1 Working Toward Common Solutions - The database, middleware, Web, and other communities are expanding their territories and are coming up with their unique solutions to problems already addressed in other communities. How do we prevent a proliferation of incompatible standards from developing out of these separate communities.
• IV-2 Towards Web Object Models - How do XML, DOM, PICS-NG, RDF, and the many metadata proposals relate to object models and agents?
• IV-3 Standardized Domain Object Models - What criteria should be used to partition and package domain spaces?
• IV-4 Reifying Communication Paths - Several workshop papers indicate that one inserts ilities into architectures by reifying communication paths and inserting ility behaviors there. But many questions remain.
 
• 11:00 - 12:00 - Summary - Plenary Session in San Carlos Ballroom
• Final comments from OMG, DARPA, MCC, and OBJS
 

There will be four parallel breakout sessions to choose from plus a fifth room is available for birds-of-a-feather sessions or continuations of earlier breakouts that are productive and need to continue.  We'll do the actual assignment of breakout topic to meeting room at the workshop by polling the participants.   Rooms in descending size are San Carlos Ballroom, Ferrante I, Ferrante II, Salon 201, and Salon 205.

Rationale for workshop sessions.  Breakout Sessions are organized to encourage effective discussions in a cross-disciplinary workshop where the attendees are coming in with very different backgrounds, viewpoints, terminology and interests.

• Breakout Session I allows people with relatively similar interests to establish terminology for communication and develop an understanding of their requirements, vision, and key problem areas for compositional architectures. Separate sessions will deal with problem definition from the viewpoints of large application architects, middleware architects, middleware system developers, and architecture theorists.
• Breakout Session II uses an orthogonal breakout to focus on various aspects of solutions with separate sessions dealing with the economics of components, composing components, achieving system-wide properties or "ilities" with components, and ORB and Web integration architectures.
• Breakout Session III examines the central issues involved in achieving various ilities within the context of component-based development. Individual sessions cover similar technical issues but focus on specific ilities including scalability, adaptability, quality of service, views and managed inconsistency.
• Breakout Session IV examines various dimensions of propagating compositional architectures into common practice. There are separate sessions on the problem of engineering common solutions to problems that are being independently addressed in diverse standards and product development activities, on moving toward Web object models, on standardizing domain object models, and on technical details of reifying communications.

• understanding the problem from the points of view of large application developers and middleware architects and developers,
• software architecture, then components, composition, and ilities, then specific ilities including scaling, adaptivity, QoS, and specific mechanisms for inserting ilities,
• web and object integration, and

transferring technology to industry and standards to create a component software economy.

Breakout Session I - 2:00 - 4:30 p.m., Tuesday, January 6, 1998

I-1 Problem Definition by Application Architects

• Moderator/Scribe:  Craig Thompson, Object Services and Consulting (OBJS)
• Papers
• paper069.doc - Louis Coker, Rick Hayes-Roth, Services First, Components Second!, Teknowledge
• paper035.html - Colin Ashford, The TINA Service Composition Architecture, TINA Consortium
• paper106.html - Gabor Seymour, Compositional Software Architecture "ilities" for Wireless Networks, Motorola, Inc.
• Topics - Large application architects and enterprise software architects will identify the critical shortcomings they see in current technology, develop a vision for future component-based development of enterprise-wide applications, and identify key architectural concepts, tools, and processes needed to realize their vision.
• Characterizing the problem.  What do large application developers and enterprise software architects want? How do they avoid building more unmaintainable legacy applications? How do they build applications with fifteen year life cycles on middleware products that change annually? How do they architect systems so that both functionality and architectural -ilities can be upgraded over the application's life cycle?  Outcome is a characterization of the problem, requirements, and list of R&D issues.
• The vision.  What do we hope to achieve?  rapid application development, understandability, reliability, ...  Might there be unexpected benefits or results?
• Sample componentwhere* roadblocks - what are they, how to remove them, assumptions limiting reuse
• the same infrastructure for component software is needed for deployment, debugging, microlicensing, ilities, fault tolerance, ... and the community will have to agree -- its all interconnected!  how can small teams end up with interoperable frameworks for all these capabilities?
• choice of infrastructure foundation as irrevocable commitment
• are monolithic stovepipes always bad? are we there yet with respect to plug and play?
• design for reuse requires thinking, too much knowledge required, complexity, too many interfaces, jungles of specs, finding your way, much less the feel of a single architecture.
• expensive to retrofit, difficult to predict
• uncontrolled evolution, in multi-vendor development, if many product vendors evolve a component x.dll, how do we keep from breaking the other user applications, managing many fielded versions
• distributed systems are less secure, rogue components,
• large footprint
• IDL mappings create complexity, harden boundaries
• need library, not executables
• closed DBMS, compiler, workflow, etc. products need to be more open
• legacy constraints on solution
• component compatibility
• initial architecture clean but warts inevitably appear during evolution - can we avoid this?
• * Note: Componentware is a Registered Trademark of I-Kinetics.
• Roles - in session descriptions, terms like "users" and "we" are used covering different roles, like architect designer, component developer, system assembler, customer.  How do these different roles vary in motivation, objectives, and value models?

I-2 Extending Current Middleware Architectures

• Moderator:  Ted Linden, Microelectronics and Computer Technology Corporation
• Scribe: Diana Lee, Microelectronics and Computer Technology Corporation
• Papers
• paper082.html - K. Mani Chandy, Adam Rifkin, and the Infospheres Group, Caltech Infospheres Project, California Institute of Technology
• paper058.html - Jeff Rees, Intermetrics' OWatch Debugging Technology for Distributed, Component-Based Systems, Intermetrics, Inc.
• paper104.html - Ted Linden, Component-based Development of Complex Applications, Microelectronics and Computer Technology Corporation
• Topics - Current middleware architectures like CORBA and COM+ are a step toward compositional architectures, but they do not fully support component-based development and maintenance of large applications. Are current middleware architectures from OMG and Microsoft steps in the right directions? What are the roadblocks in the way of realizing greater benefits?  Problem areas for discussion may include:
• Current middleware products are becoming huge, monolithic systems that are themselves almost the antithesis of a component-based system.
• Is there any hope if you build your application on the wrong middleware product and later need to move it to a different product?
• When middleware products have a life cycle of six months to a few years, how does one build applications with fifteen year life cycles?How do you even migrate an application to new releases of the same middleware product.
• What about services as components? If you build on an OMG compliant security service from one vendor, you currently cannot expect to switch to a similar service from another vendor. It is similarly hard to build services that port across multiple vendor's ORBs.  Is it feasible to specify services so they become replaceable components?
• How can middleware help applications achieve system-wide properties or ilities when the application is built from components?
• How does middleware help one build applications in which both functionality and architectural ilities can be upgraded over the application's life cycle?
• What can middleware do to help with debugging and fault isolation?

I-3 Challenging Problems in Middleware Development

• Moderator: Bob Balzer, USC/ISI
• Scribe: Kevin Sullivan, University of Virginia
• Papers
• paper063.html - Dennis Heimbigner, Alexander Wolf, Richard Hall, Andre van der Hoek, Deploying Component Software Systems, Department of Computer Science, University of Colorado, Boulder
• paper015.html - Sung-Wook Ryu, B. Clifford Neuman, Garbage Collection for Distributed Persistent Objects, University of Southern California/Information Sciences Institute
• Topics - The purpose of this session is to view component composition from the point of view of middleware developers and system programmers.  The approach is to select one or two interesting systems software component composition challenge problems that can be examined, expanded on, and used to identify component software strengths and weaknesses.  Hopefully the challenge problem can be reconsidered from other perspectives in later sessions of the workshop.  Sample challenge problems:
• validating the component approach -- can you construct a workflow system (or OODB) from component services like persistence, transactions, and queries?  Will the result be as good as a conventional workflow system?  If not, why not?
• new architectures from components -- if we compose web, DBMS, and ORB architectures, can we identify novel new productive architectures?  e.g., a DBMS where the software lives in the web or network, smart spaces where a spatial metaphor replaces a compound document page-based web metaphor
• scaling ORBs - if all the ORBs were connected to be one ORB, what a great ORB that would be.  If all the services were replicated and federated to become one suite of services what a great service that would be.  If all the users were connected to become one user ... nope, we don't compose people together to become huge people though we do to become organizations.  So how are we really going to compose all the ORBs and services if they really become available on all desktops?  How do you fit ilities into this picture? How do you make the resulting system of systems survivable?
• Why can't I combine my system with yours?  A implements fault tolerance via replication; B implements cross-system debugging; C implements distributed garbage collection.  What prior agreements do A, B, and C need to make to be able to compose these functionalities?  do they have to agree on object model?  ORB vendor? component model?  what else?  is just the design pattern portable or are APIs and implementations composable?

I-4 Software Architecture and Composition

• Moderator:  Gul Agha, University of Illinois at Urbana Champaign
• Scribe: Adam Rifkin, CALTECH
• Papers
• paper023.ps - Gul Agha, Compositional Development from Reusable Components Requires Connectors for Managing Both Protocols and Resources, University of Illinois at Urbana-Champaign
• paper050.html - Cristina Gacek and Barry Boehm, Composing Components: How Does One Detect Potential Architectural Mismatches?, Center for Software Engineering, University of Southern California
• Topics - What is the vision of component composition from the software architecture perspective?  What does software architecture explain and what does it not yet address?
• architecture, design patterns, and frameworks
• are the approaches from the architecture, design patterns, OA&D, and frameworks communities different or the same using different words?  how much do architecture description languages help us in building large-scale systems?
• define architecture - components, connections, constraints.  Is this good enough?  How do ilities fit in this definition?  OMG does not have a standard way to specify connections, constraints, or patterns of interaction though the current Component Model RFP submissions begin to address composition.  What is needed beyond a Component Model?
• casting the problem of system design as an AI search problem -- if the problem is underconstrained and not unique then which solution should we choose?  which is most stable?
• operations on architectures.  Here are some operators on architectures?  Is this a useful way to proceed?
• assembly - composing components to form a new component.  Can we talk about algebra-like operations on architectures or are scripting languages destined to be the glue that binds most components?
• decomposition, deconstruct operator
• instantiating a general architecture, customization, subsetting an architecture, specializing a component.
• will frameworks that are customized still interoperate?  if FW1 = FW2 except that they vary wrt service X then are they interoperable modulo service X?
• composing two heterogeneous architectures (e.g., web and ORB)
• replication of components, federation of (homogeneous, heterogeneous) replicated components to achieve scaling
• are services like persistence, query, ... object model independent?
• deploying
• locating gaps and stress points
• architecture alignment and mismatch
• validation - does the component-based solution do what you want it to.  Does it do it as well as the traditional monolithic solution?

Breakout Session II - Wednesday, January 7, 1998

II-1 Economy of Component Software

• Moderator: Jay M. Tenenbaum, CommerceNet
• Scribe: Catherine Tornabene, Stanford
• Papers
• paper077.html - Arie Segev, Carrie Beam, Martin Bichler, Object Frameworks for Electronic Commerce Using Distributed Objects for Brokerage on the Web, Fisher Center for Management & Information Technology, Haas School of Business, UC Berkeley
• paper001.html - Anup Ghosh, Certifying Security of Components used in Electronic Commerce, Reliable Software Technologies
• paper027.html - Robert Seacord, Duke ORB Walker, Software Engineering Institute, Carnegie Mellon University
• Topics - The purpose of this session is to develop a framework for thinking about what it will take to build an economy of component software.  Why?  to accelerate coming economy of components and possibly to level the playing field for multiple vendors [avoid CORBA vs. DCOM as the central debate]
• what is the state of practice?  what are the roadblocks? (from Breakout I-1)
• choice of infrastructure as irrevocable commitment ...
• will intellectual property legal barriers become the real barriers?  will microlicenses evolve?
• what if all products were open and free, would that solve all our problems?
• winning the architecture wars
• is a consistent architecture needed for component composition, complete with standards like OMG services - if so, is there an 80% solution that most will adopt?  Can it be grown to a 95% solution with openness addons?
• does marketplace favor one dominant vendor, many middle tier vendors, millions of micro vendors
• is there an analogy to many varieties of Unix fragmenting the Unix marketplace
• is there an analogy to many varieties of object model forcing application builders to select one, which then locks in many or most other choices and also obsoletes the technology when that object model falls from favor?
• is OMG behind? can it become more Java-friendly?
• is there a danger of too few/many independent ORB vendors?
• discontinuities - what might change in the future affecting a component economy?
• will O/S absorb word processors, ORBs and middleware, dbms, workflow, ... like file systems and TCP/IP?
• will middleware component software become free like the highway system?
• will there be a few domant McDonald's of software or Mom and Pop diners?
• will density of available solutions on the Internet increase - everything you can think of is out there.  But how to sum the results?

II-2 Component Model Representation and Composition

• Moderator: Umesh Bellur, Oracle
• Scribe:  Kevin Sullivan, University of Virginia
• Papers
• paper070.html - Guido van Rossum, Glue It All Together With Python, CNRI
• paper061.html - Jack Wileden (1), Alan Kaplan (2), Middleware as Underwear:  Toward a More Mature Approach to Compositional Software Development, (1) Department of Computer Science, University of Massachusetts, (2) Department of Computer Science, Clemson University
• Topics - We are not there yet with respect to mix-and-match, plug-and-play, or best-of-breed.  Give technical reasons why not?  One is that encapsulation hides implementations (which components need to do) but component models expose some information about how a thing is constructed, which is needed for replacing parts.  Component models are just now coming on the scene.
• component models
• What metadata do we need to collect to represent components.  Is this an open-ended collection of information, that is, will we need other metadata for unforeseen purposes?  How should we represent the metadata?  Are we assuming black-box assembly or translucent components? How will this be done in Java, OMG, the web, ...
• composition
• Scripting.  Scripting is the likely composition glue for many purposes.  What criteria do we use in selecting a good scripting language?  see recent OMG Scripting RFP submissions.
• Visual Assembly.  How far can this take us?  important successes?  are compound documents a variant of this?
• algebras of composition
• What are alternatives?  self-assembly as when agents might cooperate, ..., others?
• binding
• what are the main binding concepts and mechanisms?  tight versus loose coupling, static versus dynamic, events, detection, notification, triggers, aperiodic, subscribe, push, pull, traders, mediation, negotiation, wrappers, POA, interceptors, before-after methods, rules.  Do we need all of these to succeed?  Do we need more?  is there a minimal set?  is there a big book of bindings? how can we simplify all this to make systems easier to build and maintain?
• puzzles
• Composing object services.  Can we really compose object services like persistence and queries just by knowing their APIs?  could you make a competitive OODB from naming, persistence, transactions, queries, etc.?  Could we remove one vendors persistence service and replace it with another?
• what don't we know yet?  should we learn from agents? patterns? ...

II-3 System-wide Properties or Ilities

• Moderator:  Robert Filman, Microelectronics and Computer Technology Corporation
• Scribe:  Diana Lee, Microelectronics and Computer Technology Corporation
• Papers
• paper080.ps - Zhenyu Wang, Separate Application Logic from Architectural Concerns -- Beyond Object Services and Frameworks, Department of Computer Science, Carnegie Mellon University
• paper046.doc - Bob Filman, Achieving Ilities, Lockheed Martin Missiles and Space and Microelectronics and Computer Technology Corporation
• Topics - How does one achieve system-wide properties when composing components. How can we separate application logic from ility implementation
• identify and define selected ilities
• Ilities are system-wide properties like performance, affordability, usability, understandability, simplicity, stability, reliability, availability, fault tolerant, scalability, evolvability, continuous evolution, openness, seamlessness, flexibility, configurable, adaptable, security, safety, trust, high confidence, information assurance, survivability, timeliness, real-time, mobility, QoS, system monitoring.  Are there an open number of ilities?
• Are some kinds of ilities harder to achieve than others?
• architectural properties
• How to insert ilities into component software architectures?  Say you had a system doing something.  How would it look different if ility X was added or removed?  Is there some kind of architectural level where the boundary between the visibility/hiddeness of the ility changes?  What is needed in the architecture in order to add ilities? what mechanisms might be aids?
• Concepts for achieving system-wide ilities:  end-to-end composition, top-to-bottom composition, X-unaware vs. X-aware components, centralized or de-centralized control,  policies, boundaries
• managing ility trade-offs
• infrastructure for ilities
• how to install ilities?  is a common infrastructure needed for some or all?  metadata repository, policy manager, boundary manager, ...?

II-4 How do these fit in?

• Moderator: Gio Wiederhold, Stanford
• Scribe: Craig Thompson, OBJS
• Papers
• paper037.ps - Aloysius Mok, The Objectization Problem - What It Is and What Can be Done About It, Department of Computer Science,

University of Texas at Austin
• Topics - Few position papers covered these topics directly but they are challenging and we'll need to understand them to fully understand architectures and component technology.
• views - different views of views:  DBMS views, different views or abstractions of an architecture, multiple interfaces
• managing inconsistency - how can systems operate with data that is incomplete, inconsistent, or of bounded accuracy; how can you make use of and propagate such information while keeping track of information pedigree and quality? are there architectural patterns for adding this ability to a system?
• optimization versus modularity - there is a tradeoff, how can we have the best of both worlds
• relation of wire protocols, APIs and grammars - IETF favors protocols, OMG APIs.  What is the relationship between APIs and protocols?  when should you use one and when the other?
• agents - if we view objects as degenerate agents that are less mobile, less intelligent, and less autonomous and agents needing similar infrastructure for security, replication, and the ilities, then can that point of view help unify the object and agent technical stories, or is there good reason to keep them separate?

Breakout Sessions III - 2:00 - 4:30 p.m., Wednesday, January 7, 1998

III-1 Scaling component software architectures

• Moderator: Stephen Milligan, GTE/BBN Technologies
• Scribe: John Sebes, Trusted Information Systems
• Papers
• paper107.doc - E. John Sebes, Terry C. Vickers Benzel, Collaborative Computing, Virtual Enterprises, and Component Software, Trusted Information Systems, Inc.
• paper041.html - Venu Vasudevan, Trading-Based Composition for Component-Based Systems, Object Services and Consulting, Inc.
• Topics - What are the scaling mechanisms for component software?  What will break as we move from ORBs in LANs to ORBs on 40M desktops?  We'll have to replicate services and connect 1000's of data sources, cache at intermediate nodes, federate services, federate schemas, and worry about end-to-end QoS.  What can we say about federation, decentralized or autonomous control, metadata, caching, traders, repositories, negotiation, etc. in this environment.  And don't forget that when we scale across organization boundaries, we have security and firewalls to contend with.

III-2 Adaptivity of component software architectures

• Moderator: Bob Balzer, USC/ISI
• Scribe:  Kevin Sullivan, University of Virginia
• Papers
• paper014.html - David Wells, David Langworthy, Survivability in Object Services Architectures
• paper034.ps - L.E. Moser, P.M. Melliar-Smith, P. Narasimhan, V. Kalogeraki, L. Tewksbury, The Eternal System, Department of Electrical and Computer Engineering, University of California, Santa Barbara
• Topics - Is there a common component software framework that allows us to build software that is
• adaptable, dynamically configurable
• tailorable, customizable
• evolvable
• secure
• survivable
• graceful degradation

III-3 Quality of Service

• Moderator: Richard  Schantz, BBN
• Scribe: Joseph Loyall, BBN Technologies
• Papers
• paper081.ps - Nalini Venkatasubramanian (1), Gul Agha (1), Carolyn Talcott (2), Composable QoS-Based Distributed Resource Management, (1) University of Illinois at Urbana-Champaign, (2) Stanford University
• Topics
• The broad definition of QoS is the same as ilities, the narrow definition is bandwidth limited.
• What are the main concepts?  timeliness, precision, accuracy, resource limited situation, policy, reservations, scheduling, trading, control, region-based QoS management, ...
• How do you insert QoS into an environment
• Tradeoffs if applications are QoS-unaware versus QoS-aware.  Do QoS wrappers help make a QoS unaware component QoS aware?
• Relation to other ilities like security and system management.  Are the same mechanisms useful?

III-4 ORB and Web Integration Architectures

• Moderator:  Rohit Khare, University of California at Irvine
• Scribe:  Adam Rifkin, CALTECH
• Papers
• paper103.html - Craig Thompson, Intermediary Architecture, Object Services and Consulting, Inc.
• Topics - How are ORB and web architectures alike and how are they different?  are the differences accidental and historical?  will the two architectures increasingly overlap each other's turf or will we find ways to neatly splice them together.  How can we avoid recreating the same set of services like versioning for both architectures.
• Do we need the same openness extension mechanisms for both architectures?  PEP, filters, caching, dispatch, interceptors, ..., what else?
• Do we need the same object models for each?
• Do we need the same services for each?
• Do we need the same service support infrastructure for each? e.g., common way to handle metadata

Should they both take the same approach to ilities?

Breakout Sessions IV - 8:30 - 10:30 a.m., Thursday, January 8, 1998

IV-1 Working Toward Common Solutions

• Moderator:  Dave Curtis, Object Management Group
• Scribe: Craig Thompson, OBJS
• Papers
• paper017.doc - Craig Thompson (1), Ted Linden (2), Bob Filman (2), Thoughts on OMA-NG:  The Next Generation OMG Object Management Architecture, (1) Object Services and Consulting, Inc. and (2) Microelectronics and Computer Technology Corporation
• Topics - The database, middleware, Web, and other communities are expanding their territories and are coming up with their unique solutions to problems already addressed in other communities. How do we prevent a proliferation of incompatible standards from developing out of these separate communities.
• Is component software a silver bullet, a nightmare, or yet-another-technology?
• What's missing to build an object/component software economy? (breakout I-1)
• What can we do to accelerate mass value from components?
• Avoiding surprise - What are alternatives to objects and components?  agents, XML, ...
• Directions for OMG, W3C, JavaSoft, RM-ODP, ...  What have we learned from this workshop that would benefit the communities involved?
• What communities might get benefit from working more closely?  how should they proceed?
• middleware and web, e.g., OMG and W3C, OMG and Java, XML/DOM and Java
• middleware and agents, e.g., OMG and FIPA
• middleware and middleware, e.g., DCOM and OMG
• DBMS and middleware, e.g., OMG and ODMG
• enterprise and middleware, e.g., RM-ODP and OMG
• research and development, e.g., OMG and DARPA (e.g., encourage DARPA to use OMG as a place to pin its research results and OMG to use DARPA as a research arm, generally encourage closer industry-research ties)
• How important is it that convergence occurs in these areas?  what is the downside if it does not?  what steps could be taken to make one community more friendly to another?
• How can we use the web to build a component marketplace?  for DoD COE? for everyone?  should we build web repositories for components?  web spiders for finding components?  microlicensing and zero-cost maintenance deployment technologies?

IV-2 Towards Web Object Models

• Moderator: Ora Lassila, Nokia Research Center and W3C
• Scribe: Andre Goforth, NASA Ames Research Center
• Papers
• paper022.html - Frank Manola, Towards a Web Object Model, Object Services and Consulting
• Topics
• How do XML, DOM, PICS-NG, RDF, and the many metadata proposals relate to object models, IDL, Java, and agent definition languages?  Just what are all these representations?  do we need them all?  will some converge? will we need the cross-product of mappings?
• Metadata is useful for many purposes.  Are the representations useful for the web similar to those that are useful for component models?
• Objects might be viewed as degenerate agents.  Can we expect XML structural representations, objects, and agents all to be popular web and middleware representations or do we expect some convergence?

IV-3 Standardized Domain Object Models

• Moderator: Fred Waskiewicz, SEMATECH
• Scribe: Gio Wiederhold, Stanford
• Papers
• paper013.html - Bob Hodges, Component Specification and Conformance: What Components must Expose to Compose, Texas Instruments and SEMATECH (Bob had to attend an OMG meeting instead)
• Topics
• OMG, STEP, SEMATECH, and others are working on defining standard object models for domains like business, manufacturing, transportation, electronic commerce, finance, healthcare, and many others.  What criteria should be used to partition and package domain spaces?  There seems to be no best scheme for factoring.  So how do we agree when it comes to componentizing or packaging domain data.
• Many large applications require representing an open collection of attributes per entity (different scientific experiments collect different observable data about entities under study).  This situation is not modeled well by objects. Is it the right solution to mixin a property list or invent a new data model that handles property lists as first class objects?  How do you mixin the methods?

IV-4 Reifying Communication Paths

• Moderator: David Wells, OBJS
• Scribe:  Kevin Sullivan, University of Virginia
• Papers
• paper101.doc - Roger Le and Sharma Chakravarthy, Support for Composite Events and Rules in Distributed  Heterogeneous Environments, Computer and Information Science and Engineering Department, University of Florida, Gainesville
• Topics - Several workshop papers indicate that one inserts ilities into architectures by reifying communication paths and inserting ility behaviors there.
• What behavioral extensions can be added implicitly, transparently, seamlessly to a system?
• What are the mechanisms involved?  expansion joints, interceptors, proxies, injectors, higher-order connectors, program managers, mediators, wrappers, filters, before-after methods, rules, ...
• Are all ilities the same complexity and handled by insertion into communication paths?
• Do we have what we need to do this in today's ORBs, web, Java.  The need for before-after methods or rules or ... that third parties can define.  ORBs have filters but not all web clients or servers do and Java does not support before-after methods, especially not ones programmed by third parties.  Should it?
• What are the domain and scoping mechanisms that affect boundaries for ility insertion?
• Enforcement -- if an object is made persistent, plays a role in a transaction, is versioned, ... then how do we guard it so all these possibly implicit operations occur in some reasonable order and there are no backdoors?
• Composing multiple ilities, handling ility tradeoffs