Your SlideShare is downloading. ×
Modular Enterprise Systems - An Introduction
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Modular Enterprise Systems - An Introduction

256
views

Published on

Modularity in Enterprise Systems - a neglected topic.

Modularity in Enterprise Systems - a neglected topic.

Published in: Software

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
256
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Integrating Architecture Apps for the Enterprise A unified Modulesystem For Distributed Enterprise Applications An Introduction
  • 2. Just any point in time in any company e.g. at com.my.company © 2014 Andreas Weidinger at Integrating Architecture de Seite: 2
  • 3. The IT landscape of com.my.company Frontends FTP Server HOST CRM SCM UNIX Server IRX CMG VCX HR FI Backend SAP MQ Standalone AS-1.0 + AS-3.2 CRM-OV KM-UX W F M CRX PM-UX SFE CM DOC KM KTDB DWDB IDB KMX-DB Service Bus (ESB) AFR AMS E X T E R N A L S = com.my.XML1 © 2014 Andreas Weidinger at Integrating Architecture de Seite: 3
  • 4. A department has a new requirement and the IT is asked to implement it e.g. a function: to adjust customer data © 2014 Andreas Weidinger at Integrating Architecture de Seite: 4
  • 5. Where and How is the new requirement implemented? Frontends FTP Server HOST CRM SCM UNIX Server IRX CMG VCX HR FI Backend SAP MQ Standalone AS-1.0 + AS-3.2 CRM-OV KM-UX W F M CRX PM-UX SFE CM DOC KM KTDB DWDB IDB KMX-DB Service Bus (ESB) AFR AMS E X T E R N A L S = com.my.XML1 © 2014 Andreas Weidinger at Integrating Architecture de Seite: 5
  • 6. Where and How is the new requirement implemented? © 2014 Andreas Weidinger at Integrating Architecture de Seite: 6
  • 7. Where and How is the new requirement implemented? Some possible scenarios are the function is part of a dedicated system is part of a dedicated system but with interfaces affects the interna of several systems is an independent service is a linked service … etc. © 2014 Andreas Weidinger at Integrating Architecture de Seite: 7
  • 8. However in a modular world the answer is completely different © 2014 Andreas Weidinger at Integrating Architecture de Seite: 8
  • 9. In a modular world the answer is: A Module or a Moduleversion in a Modulerepository © 2014 Andreas Weidinger at Integrating Architecture de Seite: 9
  • 10. In a modular system there are two universal, central elements Module – and – Repository 1 - of course there might be more than one Repository 1 © 2014 Andreas Weidinger at Integrating Architecture de Seite: 10
  • 11. What is a Module? And what is a Module Repository? a central directory with subdirectories a Modulefile with a unique Modulenamen A module is a defined business or technical functionality Module Repository (/var/myrepoXY/) System 1 com.my.CustomerAdjustment-1.0.0 com.my.ModuleXY-2.0.1 … etc. com.my.xy.ServiceZ-3.5.0 System N … etc. © 2014 Andreas Weidinger at Integrating Architecture de Seite: 11
  • 12. The unique Module(name) identifies all necessary artefacts in all areas com.my.CustomerAdjustment-1.0.0 budgets und controlling jobs or tasks in planning specification and requirementlist softwareproject repository in a version control system executable module test, acceptance, operation, …, … etc. everything targets the same Module © 2014 Andreas Weidinger at Integrating Architecture de Seite: 12
  • 13. In a modular systemlandscape modules are the unified view of all participants © 2014 Andreas Weidinger at Integrating Architecture de Seite: 13
  • 14. Modules may represent any part or requirement of a system landscape - Modules are able to scale free – from a whole system to a single function © 2014 Andreas Weidinger at Integrating Architecture de Seite: 14
  • 15. That's nice - but until now it is no usable software in an application landscape! © 2014 Andreas Weidinger at Integrating Architecture de Seite: 15
  • 16. Just two things are missing for usable software a Manager that makes modules available and Middlware on which this manager runs Module Repository Service Broker dynamic JEE Server Manager Clients manager.getModule( „com.my.ServiceXY“ ) module.doBizzMethod © 2014 Andreas Weidinger at Integrating Architecture de Seite: 16
  • 17. That looks mutch like a usual, but proprietary JEE Bus/Broker System with all the problems of an JEE application!?! But it isn‘t! © 2014 Andreas Weidinger at Integrating Architecture de Seite: 17
  • 18. The Broker is NOT a usual JEE application and therefore also without its problems because … the broker does NOT contain any business logic it never has to be changed or extended it can be integrated in any system it is just about 60 KB (Kilobyte) small it is just Middleware – NOT an application the actual application software are only the Modules and they are technology and platform independent © 2014 Andreas Weidinger at Integrating Architecture de Seite: 18
  • 19. The Broker is NOT a usual JEE application and therefore also without its problems The Broker just realises the internal middleware adapter of the dynamic Module Manager Service Broker als Modul Repository Clients neutrale Middleware API manager.getModule( „com.my.ServiceXY“ ) module.doBizzMethod Session Services Web Services … etc. a client just knows a manager that transparently provides modules © 2014 Andreas Weidinger at Integrating Architecture de Seite: 19
  • 20. The advantages of this design no Deployment or special Packaging no complex designs or transformations no software version proplematics no binding to JEE processes or technologies ideal for agile, continuous processes unbound system-, technology- and cross platform Functions and Services and at the same time neutral, clearly encapsulated and defined modules that are versioned and exchangeable © 2014 Andreas Weidinger at Integrating Architecture de Seite: 20
  • 21. Which protocols and data formats are supported? Client Server communication RMI - resp. all protocols supported by EJBs JMS, HTTP, WebService, WebSocket, REST,AJAX … every protocol that is available in JEE or JSE or for which an adapter exsists Dataformats … any format that can be processed in java © 2014 Andreas Weidinger at Integrating Architecture de Seite: 21
  • 22. And the client side? © 2014 Andreas Weidinger at Integrating Architecture de Seite: 22
  • 23. And the client side? Modules are the same for Client and Server The Modulesystem does NOT distinguish between client and server A Repository directory with Modules and a Modulemanager are a modular system tha's all - on a client or on a server © 2014 Andreas Weidinger at Integrating Architecture de Seite: 23
  • 24. Integrating Architecture IT Consulting Andreas Weidinger Mobile: 0160 97627398 Mail: info@integrating-architecture.de Home: www.integrating-architecture.de
  • 25. 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 Smart Client Modules Web Client Modules Apps for the Enterprise Mobile Client Modules Rich Internet Application Server Modules Java SE + EE HTML / JavaScript Windows Linux / Unix Mobile 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: 25
  • 26. Backup – Traceability Transparency, reliable Management and Governance through Unique linking and mapping of all parts of an IT Landscape Arbitrary patrs and functional requirements for Services and Systems … …are represented and realized by unique Modules in a central Repository Module Repository System-CRM CRM ModuleXY-1.0.0 CRM ModuleXY-2.0.0 CRM Module4711-1.0.0 Module SAP Service- 2.1.0 Module Messaging-1.0.5 Module KT-DB-3.0.0 … etc. IT Systemlandscape Management and the Service Broker (both free of business logic) provide the Modules On-Demand Projects 1 1 -That means project structures in development like IDE or SCM projects – not organizational management projects, they stay independent © 2014 Integrating Architecture Seite: 26
  • 27. Backup – Client Server Architecture Entire separation of business logic from platform and technology Server Server oder File Server JEE Application Server ISA Service Broker Application ISA Module System calls knows ISA JEE Adapter SF Session SL Session Servlet MDB/JMS WebService 4 delegates central Repository : Module resp. App : Object : Call 1 3 2 Web Client network uses Manager http Connector multi protocol Connector multi protocol automated, system- and user specific configuration und replication Rich Internet Application Service Consumer Any Application Smart Client ISA Modul System local 1‘ Repository Manager calls knows - 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 5 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 : optional 5 - The ISA Smart Client is not mandatory. Any application can access the broke © 2014 Integrating Architecture Seite: 27
  • 28. Backup – JEE Vulnerabilities JEE based systems are monoliths by specification because the deployment model only knows closed applications JEE violates the SoC princip 1 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 © 2014 Integrating Architecture Seite: 28