bonn // 6.11.03nefis - arch & interop1 tr: part 2 on architecture & interoperability...

Bonn // 6.11.03 NEFIS - Arch & Interop 1

TR: Part 2On Architecture

& Interoperability Relevance to NEFIS: is there a need?

Moh Ibrahim, Keith Rennolls & Alex

FedorecUniversity of Greenwich


Outline (plan?)• Brief History (Peter G. W. Keen – Range &

Reach) • Architecture – superstructure, infrastructure

– Quality of architecture - ODP– Kinds of architecture – s/w, h/w, web-services, …

appl, b usiness, data, information, technology, – OR taxonomise as: Operation, development,

execution– Enterprise, Information, etc (ODP)


Outline (plan?)• Open systems: Interoperability & portability

– Definitions of each – Portability – kinds of – Levels of interoperability– Examples from Andreas Schuck & Peter

Holmgren talk in Quebec, other examples – from grids/e-science

• Web services & Grids?


Postulates (Axioms/assumptions)

• Change & changeability - the norm

• Diversity – everywhere• One problem : zero, one or many

solutions• No one solution is perfect …

For all seasons/situations

• Perfection? 100% - impossible?• Heterogeneity galore


Postulates (Axioms/assumptions) /cont• Functions – (more) stable than

tools, techniques & technology (innovations)

• Resources (EU,…) are scarce, limited

• Hard but possible (?) to achieve a quality product, within budget, and on-time (e.g. Scottish parliament)

• Add you own favourite…


Brief History: Distributed Systems

IRBrowse …. Collaborative Dist processing….

Range

Reach

Dept

Intra-Enterprise

Anyone, anywhere…

Inter-Enterprise

Open Systems

Which…???


(I) An Introduction to ‘Software’ Architecture

Moh Ibrahim, Alex Fedorec, Keith Rennolls

University of Greenwich, London


Contents (I)

• What is Architecture?

• Current Practice in Software Architecture

• Why Software Architecture?

• Common Architecture Styles

http://www.utdallas.edu/~chung/SA/contents.html


What is Architecture?

• Architecture: the underlying structure of things

• An example of civil engineering– Customer engineer gets customer requirements – functional units: 3 bedrooms, 2+1/2 bathrooms, 1 living & 1 dining rooms, 2-

car garage, kitchen, backyard, gardens

• other considerations: cost, esthetics, workmanship, neighborhood,

maintainability, economics



– Architect starts thinking about architectural styles

• architectural styles: Victorian, Duplex, Condominium,

Townhouse, Catheral, Pyramidal,

floor plans & elevations for functional units



– Designers/Contractors think about detailed design considerations

• electrical wiring, plumbing, heating, air-conditioning, carpeting, etc.

– Sub-contractors/Construction Workers:• electricians, plumbers, CH installers,

carpenters, locksmith, brick layers, bathtub technicians, etc.


Current Practice in Software Architecture

• Architecture Descriptions:– Many systems are based on the client-

server model and use remote procedure calls both locally and remotely to provide communication among client applications and servers.

– use a distributed, object-oriented approach to managing information.


Current Practice in Software Architecture

• Observations:– software architectures are indeed

used, very often but without even knowing it

– A SA carries some, and more often than not a lot of, information

– no explicit description of the structure


Software Architecture Description

• elements (components/parts):– from which systems are built,e.g., process, data,

object, agent

• interactions (connections/connectors/glues/relationships):– between the elements,e.g., PCs, RPCs, MOMs,

events

• patterns:– describe layout of elements and interactions, guiding

their composition, e.g., # of elements, # of connectors, order, topology, directionality


Software Architecture Description

• constraints:– on the patterns (i.e., on components, connectors,

layout),e.g., temporal, cardinality, concurrency, (a)synchronous, etc.

• styles:– abstraction of architectural components from

various specific architectures, (Sometimes interchangeably used with patterns,e.g., Unix OS, OSI protocol layer, Onion ring IS structure -> layering

• rationale:– describe why the particular architecture is chosen


Why Software Architecture?

• abstract solution to handle/conquer complexity (problem solving strategy)

• supports reuse• facilitates (integration) testing• parallel development • system evolvability • … many other conceptual reasons


Common Architecture Styles

• Dataflow systems – Batch sequential– Pipe & Filter

• Call-and-return systems– Main program & subroutine– OO systems– Hierarchical layers

• Independent components– Communicating processes– Event systems


Common Architecture Styles

• Virtual machines– Interpreters– Rule-based systems

• Data-centered systems – Databases

– Hypertext systems– Blackboards

• Process-control paradigms


Interoperability

*With special thanks to Eric M. Dashofy from whom some of this material is blatantly stolen.


Contents (II)• Characterization of the Problem

– With an attempt to taxonomize

• Taxonomy of Solutions

• Investigation of Specific Solutions– CORBA, J2EE, DCOM, .Net, and other

middleware– UML, xUML, XML, …– Web services ??– Grid Services??


Definitions

• Interoperability–The ability for two or more

(independently-developed) (software) components to interact meaningfully• Communicate meaningfully

• Exchange data or services


Why is Interoperability Important?

• We need it to maintain the living we do now– We are burdened with un-rebuildable

legacy systems• cf. SABRE, Air Traffic Control

– It is induced by the state of computing now• Increasing connectivity of computers through

the Internet


Why is Interoperability Important?

• One (perhaps the) dominant challenge in software engineering– We can’t live without it

• Large systems are no longer built from first principles (nor can they be) - e.g. NEFIS, EFIS

– We shouldn’t live without it• Component reuse has the potential for

enormous cost savings– Cited by Brooks as a potential silver bullet


Is Interoperability the Problem?

• Interoperability is not a problem, it’s a software quality.

• The problem in achieving this quality is…

• Heterogeneity! Components are:– written in different programming

languages– running on different hardware platforms


Is Interoperability the Problem?

Heterogeneity! Components are /cont:– running on different operating systems– using different data representations– using different control models– implementing different semantics or

semantic interpretations– implementing duplicate functionality– implementing conflicting functionality


Another Characterization• Architectural Mismatch [GAO95]

– Components have difficulty interoperating because of mismatching assumptions

• About the world they run in• About who is in control, and when• About data formats and how they’re manipulated

– Also assumptions about connectors• About protocols (who says what when)• About data models (what is said)

– Also assumptions about the global configuration (topology)

– …and the construction process (mostly instantiation)


Syntactic vs. Semantic• Syntactic compatibility only guarantees that

data will pass through a connector properly• Semantic compatibility is achieved only

when components agree on the meaning of the data they exchange

• Example: UNIX pipes– Syntactic compatibility established by making

all data ASCII– Semantic compatibility is not addressed

• Line-oriented data?• Field-oriented lines?• Field separators?


Classic Example

Enumerate the interoperability problems hereAre they essential or accidental?Are they syntactic or semantic?

American electrical plugEuropean electrical outlet


An example of an “essential” power problem

American electrical plugFlintstones Power Source


Achieving Interoperability

ComponentA

ComponentB?

? ?

Given two components and an arbitrary connector in between,

how can we make them interoperate?

Give some examples of components for A and B.


Shaw’s Taxonomy

form = representation, communication, packaging, semantics


Shaw’s Taxonomy, In Detail/1

• Change A’s form to B’s form– Usually involves a complete rewrite

– Expensive but do-able

• Publish an abstraction of A’s form– API’s (open or standardized)

– Projections or Views (common in databases)



• Transform on the fly– Big-endian to little-endian translations in

the connector– Use an architectural style

• Negotiate a common form– Requires that one or both components

support multiple forms– Classic example is modem protocol

negotiation



• Make B multilingual– Macintosh “fat binaries”

– “Portable code” that uses #ifdefs

• Import/Export Converters– May be part of A or B, may be developed

by a 3rd party

– Classic example: word processors, Alchemy Mindworks’ Graphics Workshop



• Intermediate form– Agree on a common form, usually involves

some sort of standardization– IDL data definitions– XML schema– RTF, PostScript, PDF

• Wrap Component A– Machine emulator

• (cf. Playstation emulators, StellaX, SABRE)

– Piece of code that translates APIs


Shaw’s Taxonomy, In Detail /5• Maintain parallel consistent versions

– Constrain both A and B such that they have matching assumptions

– Whenever one changes assumptions, make the corresponding change in the other component

– Delicate, often impractical

• Separate essence from packaging– Research topic– “A service without an interface”– Interfaces are provided by “system integrators”– Variant: exposing multiple interfaces from A– Variant: A generic interface that can be transformed into

many interfaces automatically


The (??)“Solution” (as offered by industry)

• Middleware– Buzz: Industry will build you a connector

that makes interoperability magically appear

– Right?

• Hint: Not Exactly


Middleware

• Popular middleware offerings– CORBA– COM– RMI– JMS– DCE RPC (aka Xerox Courier, SunRPC, ARPC)– Microsoft Message Queue– MQ Series– Siena– KnowNow SOAP Routing

• SOAP (is this middleware?)


Focus: CORBA

• Common Object Request Broker architecture

• A middleware standard – (not implementation)

– from the Object Management Group• Like the United Nations

of software organizations


Focus: CORBA• From the spec:

– Object Request Broker, which enables objects to transparently make and receive requests and responses in a distributed environment. It is the foundation for building applications from distributed objects and for interoperability between applications in hetero- and homogeneous environments. The architecture and specifications of the Object Request Broker are described in this manual.

• Standard for middleware that enables interoperability among components with different assumptions about:– Platform– Language (type system)

What assumptions are implicit in the OMG definition?


What is CORBA?• At its core:

– It is RPC with objects– Along with a fairly competent IDL (interface

definition language)– Plus some pre-defined services provided by the

middleware and exposed through the RPC+Objects mechanism (CORBAServices)

• Naming• Trading• “Events”• Etc.


Example

ComponentA

ObjectB

PublicInterface of B

How do we make this call (one way only, here)?


Example

ComponentA

ObjectB

PublicInterface of

B

First, we mustturn this interfaceinto something thatis comprehensible in A’s world

Solution: define the interface in a platform-neutralinterface definition language (IDL)

Why might this be harder than it looks?


Exercise: Convert this Java signature to be called from C++

• public int foo(int p1, Vector v);

• public int start(Thread t);

What do we need to know about the source and target language to do this

effectively?

Can I do this for any arbitrary function?


Example cont.

ComponentA

ObjectB

PublicInterface

of B

IDLCompiler for A-world

IDLCompiler for B-world

Are these the same?


Example cont.

ComponentA

ObjectB

PublicInterface of

B

StubCompiler for A-world

(or maybe…)

B’sStub forA-world

SkeletonCompiler for B-world

(or maybe…)

Skeleton forB-world


Example cont.

ComponentA

ObjectB

PublicInterface of

B

B’sStub forA-world

Skeleton forB-world

Via proprietaryprotocol, probably TCP-basedif a network is involved, maybethrough some more efficientOS-based mechanism likenamed-pipes if the call is allbeing made on one machine.

NB: B is oftencalled the “trueobject”


Semantic Sugar: CORBAservices

• CORBAservices are basically standardized APIs for doing common tasks.

• The True Objects providing the services are usually provided by your ORB vendor.

void bind(in Name n, in Object obj) raises(NotFound, CannotProceed, InvalidName,AlreadyBound);

void rebind(in Name n, in Object obj) raises(NotFound, CannotProceed, InvalidName);

A snippet of the IDL for the Naming service:


Funny Side-note: IIOP• It turns out that the proprietary protocols

between stubs and skeletons caused interoperability problems between ORBS– Solution: standardize yet another protocol for

Inter-ORB Interoperability• This became IIOP—the Internet Inter-Orb Protocol


For Discussion• What kinds of heterogeneity/interoperability

issues are solved by CORBA• Which are not?• Are the problems that are addressed syntactic

or semantic?• Does CORBA induce any additional

assumptions (i.e. does it worsen interoperability)?– What assumptions?– How?

• Where does CORBA fit in Shaw’s taxonomy?


Can we taxonomize middlewares?

RPC with Objects - CORBA - COM - RMI - SOAP-RPC

Oneway Messages (low multicast) - JMS - MSMQ - MQ Series - SOAP (at core) - CORBA oneway calls

RPC with Services - DCE RPC - “Q” (U. Colorado) - Corba w/C binding

Oneway Messages (high multicast) - Siena - KnowNow SOAP routing - Precache Secret Project (presumably)


Focus: XML

• XML: Extensible Markup Language– Buzz: Finally, a standard for encoding

data! XML will solve your interoperability problems!

– Right?

• Hint: Not exactly


What is XML?

• From the spec:– Extensible Markup Language, abbreviated XML, describes a class of

data objects called XML documents and partially describes the behavior of computer programs which process them. XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [ISO 8879]. By construction, XML documents are conforming SGML documents.

– XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure.

What assumptions are implicit in the W3C discussion?


What is XML, really?

• A way of organizing and decorating textual data

• Blatantly hierarchical, but works well in the context of a running document

• Supported by meta-languages that define allowable constructs in the hierarchy


Example

Eric’s Personal Information,unstructured.

Eric M. Dashofy, b. 1977 tofather Mark and motherSusan, currently acomputer scientist at UCIrvine, hobbies includeplaying guitar and makingStar Wars fan-films.


With XML<person> <name> <first>Eric</first> <mi>M</mi> <last>Dashofy</last> </name> <dob> <year>1977</year> </dob> <father>Mark</father> <mother>Susan</mother> <occupation> <title>Computer Scientist</title> <location>UC Irvine<location> </occupation> <hobby name=“guitar” /> <hobby name=“star-wars-fanfilms” /></person>

Is this better or worsethan the bio on the previous slide? Howso?

What can we do with this bio that we couldn’t with the previous one?

What assumptions are being made in this biography?

What agreement(s) do two components have to come to to make use of this bio?


Open Q’s: For Discussion• What kinds of heterogeneity/interoperability

issues are solved by XML?• Which are not?• Are the problems that are addressed syntactic or

semantic?• Does XML induce any additional assumptions

(i.e. does it worsen interoperability)?– What assumptions?– How?

• Where does XML fit in Shaw’s taxonomy?


So, onto NEFIS

• Relevance to NEFIS?• Are they …. (A & I) – how, where, …?• Yes – we suggest• Can we build a future-proof, technology-

independent, architecture-centric, model-driven architecture?

• We do not want to throw the baby with the bath water!! Leverage legacy

• Yes – – but perhaps not 100% - 80/20 will do


So, onto NEFIS

• Relevance to NEFIS?• Are they …. (A & I) relevant – what,

how, where, …?• Yes – we suggest they are …• Can we build a future-proof,

technology-independent, architecture-centric, model-driven NEFIS/EFIS++?


Future Directions

• Interoperability over the Web– SOAP

• “XML for control instead of data”• Solves, introduces same issues as XML

– Web Services– “The Semantic Web”


Future Directions

• 2nd Generation Middleware– Which is largely geared toward

interoperability between 1st generation middleware packages

• Enterprise Application Integration (EAI)– A whole market driven by people with

experience making systems interoperate


Conclusions /1• NEFIS / EFIS ++ are ISs

• All ISs have architectures – by default, or by design

• Architecture need to be flexible, robust, resilient, extensible, …technology-proof, … to preserve legacy and enable progress / integration of future advance


Conclusions /2

• 100% Perfection is almost impossible

• 80/20 rule or better

• Achievable – but need planning & management & designed into NEFIS early; not bolted onto it at the middle/end


Conclusions /3• Many levels of interoperability, not just access,

not just data – semantic interop not just syntax• Design to an interface – not to an implementation• Plan for change / preserve legacy / allow for

future • Hard work – but doable, the earlier in a product

life-cycle the better• Standards are CSF• More study/research needed / team-work &

collaboration &&&& more interoperability between partners !!


Thank you

bonn // 6.11.03nefis - arch & interop1 tr: part 2 on architecture & interoperability...

Documents

nefis arch interop7

nefis arch interop16

nefis arch interop9

nefis arch interop10

nefis arch interop11

particular architecture

structure slide

odp slide