View
229
Download
1
Category
Preview:
DESCRIPTION
Apps for the enterprise - A uniform Modulesystem for Distributed Enterprise Applications Motivation and basic Concept
Citation preview
A uniform Modulesystem
for Distributed Enterprise Applications
Motivation and basic Concept
Integrating ArchitectureApps for the Enterprise
© 2014 Integrating Architecture Seite: 2
Content
� Problem
� Reason
� Challenge
� Basic Idea
� Architecture
� Implementation
� Kontakt
� Backup
� Unification
� Traceability
� Client Server Architecture
� JEE Vulnerabilities
© 2014 Integrating Architecture Seite: 3
The Problem
� Enterprise development and maintenance is
� elaborated, risky and expensive
� Costs for new features and changes increase exponentially with the scope of the systems
� Business driven development is getting constantly slower, more error prone and increasingly restrictive
� Iterative and agile processes are more and more hindered and slowed down with increasing system size
© 2014 Integrating Architecture Seite: 4
The Reason
� Over the decades, although software architectures, processes and technologies have continuously improved
� … but the problem has remained !?!
� Because one thing has not changed over time
� that complex monoliths are built
� That is, as if one uses continuous improving technologies to build square wheels – always wonderingthat they do not roll. Monoliths are for continuance - NOT for evolution!
© 2014 Integrating Architecture Seite: 5
The Challenge
� Enterprise Systems are much more than a piece of software!
� They reflect the challenges of a company and have to constantly evolve with these
� But they can only do so –if they are constructed like companies
� from individual units with responsibilities and limitations
� achieving common goals
� by cooperation and management
© 2014 Integrating Architecture Seite: 6
The basic Idea
� “Individual units with responsibilities and limitations,
driven by a management to achieve common goals
by cooperation” ? – that
� is a modular System!
� Modules are unique, self sufficient units
� with clearly defined functions, a protected inside
� and public interfaces for cooperation
� Systems consist of any number of modules
� combined under one name
� which together realize a bigger task driven by a management
� Development is change of modules over versions
� Functional size is the number of modules
© 2014 Integrating Architecture Seite: 7
� Everything is a unique, versioned Module – everyone just
works with modules – and a module may be “anything” needede.g. subject for: business requirements, specification, modeling, planning, controlling, operation etc. and at the same time neutral software artifact like service, database, technology, external system, GUI, interface etc.At last a module is a unique name (e.g. com.ModuleXY-1.0) and a file with this name in a central repository. Everything else is usage and technical automatism.
The Architecture
© 2014 Integrating Architecture Seite: 8
The Implementation
� Enterprise Apps provide without effort
- platform independent Modularity
- and technology independent Communication
In this way they enable the construction of Enterprise Systems from easily to
handle, versioned service modules, that are located in a central repository and
provided by an On Demand management as modular applications and central
services of a service broker.
� Enterprise Apps free from middleware technology, from deployment, from complex designs and transformations and
aslo from versioning- and update problematics – just simple modules
JEE Server+Brokerestablished
andpowerful
Modulemanagerdynamic
andautomated
Platform baseIndividual, modular and
automated systemesCentral Repository
including all Modules
Andreas Weidinger
Mobile: 0160 97627398Mail: info@integrating-architecture.deHome: www.integrating-architecture.de
Integrating ArchitectureIT Consulting
© 2014 Integrating Architecture Seite: 10
Backup – Unification
� Enterprise Apps modules are the same from the specification to
operation. In this way they unify all technologies and platforms
in one evolving architecture.
Unification of Technologies and Platforms
Windows Linux / Unix
Apps for the Enterprise
Rich Internet Application
Mobile
Java SE + EE HTML / JavaScript
ServerModules
Smart ClientModules
Web ClientModules
Mobile ClientModules
Central Module
Repository
- Modules
- Services
- Rules
1 - The presentation as a layer is just vor illustration purpose. Enterprise Apps are NO technical layer
and also NO technical object types.
1
© 2014 Integrating Architecture Seite: 11
Backup – Traceability
� Transparency, reliable Management and Governance through
Arbitrary patrs and functional requirementsfor Services and Systems …
…are represented and realizedby unique Modules in a central Repository
Module Repository
CRM ModuleXY-1.0.0
CRM ModuleXY-2.0.0
Module KT-DB-3.0.0
Module Messaging-1.0.5
Management and the Service Broker (both free of business logic) provide the Modules On-Demand
Projects
Unique linking and mapping of all parts of an IT Landscape
CRM Module4711-1.0.0
System-CRM
… etc.
Module SAP Service-2.1.0
1
1 -That means project structures in development like IDE or SCM projects – not organizational management projects, they stay independent
IT Systemlandscape
© 2014 Integrating Architecture Seite: 12
Backup – Client Server Architecture
� Entire separation of business logic from platform and technology
JEE Application Server
ISA Service Broker Application
ISA Module System
knows
calls
SF Session
SL Session
Servlet
MDB/JMS
WebService
ISA JEE Adapter
delegates
centralRepository
: Object
: Module resp. App
: Call
automated, system- and user specific configuration und replication
- Business implementation only resides in modules resp. apps
- The central repository is a Single Point of Access, it contains
all versions of all modules divided into systems – for clients and server
1
2 - The JEE Adapters are generic. They contain NO business code and always delegate to the module management
3 - The Service Broker resp. the corresponding JEE application(.ear) is only about 50 KB in size
4 - The module system is totally encapsulated an runs in its own classloader context
1
4
3
2
: optional
usesManager
5 - The ISA Smart Client is not mandatory. Any application can access the broke
localRepository
ISA Modul System
Manager
1‘
calls
knows
5
Connector
multi
protocol
Server Server oder File Server
Smart Client
networkWeb Client
Rich Internet Applicationhttp
Service Consumer
Any ApplicationConnector
multi
protocol
© 2014 Integrating Architecture Seite: 13
Backup – JEE Vulnerabilities
� JEE based systems are monoliths by specification
� because the deployment model only knows closed applications
� JEE violates the SoC princip
� because JEE forces the implementation of business requirements as platform components (e.g. as WebService, EJB etc.)
� JEE components are bind to distinct distributed communication
technologies (e.g. RMI, HTTP, JMS etc.)
� JEE does not provide a usable module system and its container
structure hinders the use of external module systems
� The problem with JEE is NOT the concept of an application server providing a
distributed infrastructure – the problem is, that JEE tries to claim any purpose and binds applications to its monolithic platform and its technologies.
1 - Separation of Concerns – at this point separation of business logic and technology
1
Recommended