Bonn // 6.11.03 NEFIS - Arch & Interop 1 TR: Part 2 On Architecture & Interoperability Relevance to NEFIS: is there a need? Moh Ibrahim, Keith Rennolls & Alex Fedorec University of Greenwich
Mar 27, 2015
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
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)
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?
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
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…
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…???
Bonn // 6.11.03 NEFIS - Arch & Interop 7
(I) An Introduction to ‘Software’ Architecture
Moh Ibrahim, Alex Fedorec, Keith Rennolls
University of Greenwich, London
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
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
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
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.
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.
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
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
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
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
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
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
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.
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??
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
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
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
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
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
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)
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?
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
Bonn // 6.11.03 NEFIS - Arch & Interop 29
An example of an “essential” power problem
American electrical plugFlintstones Power Source
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.
Bonn // 6.11.03 NEFIS - Arch & Interop 31
Shaw’s Taxonomy
form = representation, communication, packaging, semantics
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)
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
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
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
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
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
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?)
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
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?
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.
Bonn // 6.11.03 NEFIS - Arch & Interop 42
Example
ComponentA
ObjectB
PublicInterface of B
How do we make this call (one way only, here)?
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?
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?
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?
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
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”
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:
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
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?
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)
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
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?
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
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.
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?
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?
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
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++?
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”
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
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
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
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 !!
Bonn // 6.11.03 NEFIS - Arch & Interop 65
Thank you