![Page 1: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/1.jpg)
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
![Page 2: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/2.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 2
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)
![Page 3: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/3.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 3
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?
![Page 4: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/4.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 4
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
![Page 5: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/5.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 5
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…
![Page 6: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/6.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 6
Brief History: Distributed Systems
IRBrowse …. Collaborative Dist processing….
Range
Reach
Dept
Intra-Enterprise
Anyone, anywhere…
Inter-Enterprise
Open Systems
Which…???
![Page 7: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/7.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 7
(I) An Introduction to ‘Software’ Architecture
Moh Ibrahim, Alex Fedorec, Keith Rennolls
University of Greenwich, London
![Page 8: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/8.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 8
Contents (I)
• What is Architecture?
• Current Practice in Software Architecture
• Why Software Architecture?
• Common Architecture Styles
http://www.utdallas.edu/~chung/SA/contents.html
![Page 9: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/9.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 9
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
![Page 10: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/10.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 10
What is Architecture?
– Architect starts thinking about architectural styles
• architectural styles: Victorian, Duplex, Condominium,
Townhouse, Catheral, Pyramidal,
floor plans & elevations for functional units
![Page 11: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/11.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 11
What is Architecture?
– 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.
![Page 12: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/12.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 12
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.
![Page 13: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/13.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 13
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
![Page 14: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/14.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 14
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
![Page 15: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/15.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 15
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
![Page 16: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/16.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 16
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
![Page 17: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/17.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 17
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
![Page 18: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/18.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 18
Common Architecture Styles
• Virtual machines– Interpreters– Rule-based systems
• Data-centered systems – Databases
– Hypertext systems– Blackboards
• Process-control paradigms
![Page 19: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/19.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 19
Interoperability
*With special thanks to Eric M. Dashofy from whom some of this material is blatantly stolen.
![Page 20: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/20.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 20
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??
![Page 21: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/21.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 21
Definitions
• Interoperability–The ability for two or more
(independently-developed) (software) components to interact meaningfully• Communicate meaningfully
• Exchange data or services
![Page 22: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/22.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 22
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
![Page 23: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/23.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 23
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
![Page 24: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/24.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 24
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
![Page 25: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/25.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 25
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
![Page 26: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/26.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 26
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)
![Page 27: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/27.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 27
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?
![Page 28: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/28.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 28
Classic Example
Enumerate the interoperability problems hereAre they essential or accidental?Are they syntactic or semantic?
American electrical plugEuropean electrical outlet
![Page 29: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/29.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 29
An example of an “essential” power problem
American electrical plugFlintstones Power Source
![Page 30: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/30.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 30
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.
![Page 31: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/31.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 31
Shaw’s Taxonomy
form = representation, communication, packaging, semantics
![Page 32: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/32.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 32
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)
![Page 33: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/33.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 33
Shaw’s Taxonomy, In Detail/2
• 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
![Page 34: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/34.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 34
Shaw’s Taxonomy, In Detail/3
• 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
![Page 35: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/35.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 35
Shaw’s Taxonomy, In Detail/4
• 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
![Page 36: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/36.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 36
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
![Page 37: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/37.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 37
The (??)“Solution” (as offered by industry)
• Middleware– Buzz: Industry will build you a connector
that makes interoperability magically appear
– Right?
• Hint: Not Exactly
![Page 38: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/38.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 38
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?)
![Page 39: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/39.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 39
Focus: CORBA
• Common Object Request Broker architecture
• A middleware standard – (not implementation)
– from the Object Management Group• Like the United Nations
of software organizations
![Page 40: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/40.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 40
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?
![Page 41: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/41.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 41
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.
![Page 42: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/42.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 42
Example
ComponentA
ObjectB
PublicInterface of B
How do we make this call (one way only, here)?
![Page 43: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/43.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 43
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?
![Page 44: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/44.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 44
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?
![Page 45: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/45.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 45
Example cont.
ComponentA
ObjectB
PublicInterface
of B
IDLCompiler for A-world
IDLCompiler for B-world
Are these the same?
![Page 46: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/46.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 46
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
![Page 47: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/47.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 47
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”
![Page 48: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/48.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 48
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:
![Page 49: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/49.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 49
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
![Page 50: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/50.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 50
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?
![Page 51: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/51.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 51
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)
![Page 52: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/52.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 52
Focus: XML
• XML: Extensible Markup Language– Buzz: Finally, a standard for encoding
data! XML will solve your interoperability problems!
– Right?
• Hint: Not exactly
![Page 53: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/53.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 53
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?
![Page 54: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/54.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 54
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
![Page 55: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/55.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 55
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.
![Page 56: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/56.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 56
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?
![Page 57: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/57.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 57
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?
![Page 58: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/58.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 58
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
![Page 59: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/59.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 59
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++?
![Page 60: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/60.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 60
Future Directions
• Interoperability over the Web– SOAP
• “XML for control instead of data”• Solves, introduces same issues as XML
– Web Services– “The Semantic Web”
![Page 61: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/61.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 61
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
![Page 62: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/62.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 62
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
![Page 63: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/63.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 63
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
![Page 64: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/64.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 64
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 !!
![Page 65: TR: Part 2 On Architecture & Interoperability](https://reader035.vdocuments.mx/reader035/viewer/2022062809/56815911550346895dc63c4d/html5/thumbnails/65.jpg)
Bonn // 6.11.03 NEFIS - Arch & Interop 65
Thank you