Integration of Legacy Software in EJB

1. Integration of Legacy Software in EJB

2. Types of legacy systems Integrating legacy business logic Integrating legacy data Agenda

3. Data Mainframes Non-relational data bases File systems... Systems: Data + Logic (Niklaus Wirth) TP monitors, COBOL systems ERP systems CORBA and COM servers Types of “Legacy” Infraestructures

4. Keep and leverage investment Access our old system through a new interface (Internet…). Substitute the old code in an incremental way eliminating big-bang approach Integrating Legacy Business Logic

5. Traditional Approaches New, pretty and Internet aware System IT manager commits suicide. Internet server Legacy System Big- Bang Conversion Function 1 Function 2 Native comm. CGI extension Screen CGI Script Screen Scrapping Terminal emulation… HTML

6. Screen scrapping and terminal emulation fast and “cheap” plenty of support tools the new system is as inflexible and hard to maintain as the old one it is just a “make up” Big bang conversion definitive solution plenty of liberated IT resources are needed the EIS must be not vital, a period of adaptation to the new system must be admissible Traditional Approaches : Advantages & Problems

7. Application Server Approaches Internet server Legacy System Message Service EJB Server . Function 2 bean Applet Service Broker Native comm. Function 1 CGI or Servlets Function 2 Adapter Native comm. Screen Function 1 bean Wrapped functionality HTML

8. Green screen terminal Adapter Strategy: Details Text only Workflow model. If it involves more than one function then NOT_SUPPORTED Wrapper of Function 1 If The COBOL system enables rolling a function then NEW_REQUIRED Text only COBOL system no state between functions Function 1 EJB server Function 2 Func. 1 Stateless Session Adapter Stateless Session Workflow 1 Statefull Session Func. 2 Stateless Session Communication: error control, connection pooling,timing... NOT_SUPPORTED

9. Sometimes is very difficult to divide the old monolithic system in discrete functions Legacy interfaces can be very hard to use. Text based communication, for example, is error prone. Step by step approach Very good “effort / added-value” relation Straightforward approach with well defined steps. Application Server Approaches : Advantages & Problems

10. We cannot migrate the data legacy systems may still use it We don’t want to replicate data for coherence and maintenance Data needs to be accessed from EJB applications preferably in a transparent way, I.e. through Entity beans. Integrating Legacy Data: Why?

11. Legacy Data II: Present Approach JDBC JDBC Driver EJB Server XA “Regular” Container Mainframes, Relational DB, File systems, OO databases. Native Access Entity Bean JDBC-ODBC Bridge Transaction Manager ODBC Driver Native Access “Specialized” Container Native Access Entity Bean Native Access Custom Resource Manager XA CUSTOM

12. Legacy Data III: Future Approach Connector EJB Server Container Database Entity Bean Native Access Connector Transaction Processor Native Access Transactions Connector Standard interfaces Security ERP Native Access Resource management

13. Java SM Community Process Initiated • expert group being formed Schedule for specification release not yet defined not expected until at least 2000 implementations will follow More information contact: Rahul Sharma, Member of Technical Staff Sun Microsystems, Inc. Rahul.Sharma@sun.com Connectors

14. Standard connection EIS resources and application servers. No more proprietary and not portable solutions like specialized containers. It only covers the system level interfaces. Application level interfaces are still vendor specific. Connectors: Advantages

15. Application servers in general, and EJB in particular, are powerful and smart ways to integrate legacy systems in modern EIS. Every legacy integration effort has attached several risks, it is a difficult task that requires a great deal of expertise. Other options like big-bang migration or screen scraping are more expensive or do not fully solve the problem. Conclusions

16. Portability in EJB

17. Implementation Over-specification: every function, interface and behavior is defined Single vendor Standard Under-specification: different grades of imprecision compatibility test suites an reference implementations can help portability Multi-vendor brings competence and innovation. Implementation vs. Standard (MTS vs. EJB)

18. Portability Is Not EJB’s Only Target Product differentiation Compatibility With existing servers Portability

19. EJB Development Process 1 E.Beans Component Market Deployed application Enterprise Bean Provider Deployed Generic Specialized E. Beans E. Beans E. Beans 3 Server & container 2 Set of Application template Market assembled E. Beans EJB EJB Server Deployer Provider& Application ContainerProvider Assembler

20. Component vendors that want a broad-based market for their components. Application assemblers that want a large market of pre-built components for reuse. Application server providers that want to expand the number of third-party components available for their platforms. When Portability is Important

21. Enterprises that make a strategic decision to use a particular EJB server to take advantage of proprietary features. Organizations that custom develop beans to meet non-negotiable requirements or to differentiate their application. Application server providers that want to offer non-standard extensions as a business strategy. When Portability is Not Important

22. Basic Structure of an Enterprise Bean Server-Container Contract EJB Server EJB Container Client JNDI... • Enterprise Bean • Home • Remote interface • Bean • DD EB-Client Contract EB-Container Contract Portability Related

23. Source Code API definition Programming practices, rules and prohibitions Deployment descriptor XML based syntax Defined set of attributes Life cycle, transactional behavior…. The Enterprise Bean Contracts

24. Different flavors of JPE APIs JDK 1.1 vs. 1.2 RMI-CORBA mapping Additional and proprietary APIs XML Security Semantic differences Objects passed by value JNDI Source Code Incompatibility

25. Syntactic differences have disappeared with EJB 1.1’s XML-based descriptor There is a “standard core” set of deployment descriptor attributes Different servers add additional attributes to control specific capabilities difficult to use only standard attributes Compatibility problems in deployment descriptors can affect the source code Deployment Descriptor Incompatibility

26. Are EJB applications portable? we could say that it is possible to make portable EJB applications but it requires some workarounds and developer guidelines Portability will increase with future releases of the standard the holes in the standard will be gradually filled EJB servers will more closely meet the standard test suites and reference implementation will be soon released Conclusions

27. Portability in EJB is an inversion. Making portable EJB applications is harder than using proprietary capabilities. Is it worth in your case? Conclusions -2

28. Telephone 412 / 268-5800 Fax 412 / 268-5758 Email rcs@sei.cmu.edu kcw@sei.cmu.edu jer@sei.cmu.edu scd@sei.cmu.edu World Wide Web http://www.sei.cmu.edu U.S. mail Customer Relations Software Engineering Institute Carnegie Mellon Pittsburgh, PA 15213-3890 For More Information...

29. Additional Slides (I will only use them for specific questions)

30. They must provide: The XA interface to make them transactional aware A “custom” interface to access data JDBC is one of these “custom” interfaces Can be used by bean-managed persistence or container-managed if interface understood by container Pooling, concurrence and similar features implemented at this level Resource Managers

31. JDBC is a resource manager to access a special kind of legacy data: relational databases There are JDBC native drivers for plenty of databases: mainframes... If not native version available ==> an ODBC driver and a JDBC-ODBC bridge can be used. Developing JDBC drivers is complex but all EJB infrastructure can make transparent use of them. There are other resource managers to access other kinds of data e.g., OO, file system, SAP Resource Managers- 2

32. If we want to use CM persistence, the container must “know” the resource manager Normal containers know JDBC sources, sometimes plain file systems. There could be other containers that know other resources: ODMG sources, SAP R/3…. Versant Container to access the Versant ODBMS in Weblogic Websphere to CICS Specialized Containers

33. Different approaches: Traditional solutions: Screen scraping, CGI extensions, “magic converters”…. They meet only some objectives. Application server solutions Adapters Service brokers Middleware Legacy Programs