Presentation & Project Demonstration

1. Presentation & Project Demonstration CSE 622 – Computer Systems Theory Spring 2006 Under the guidance of Dr. Bina Ramamurthy Professor, Computer Science & Engineering Dept. SUNY Buffalo

2. Presentation by Narasimha Murthy H.N MS Student Computer Science & Engineering SUNY Buffalo.

3. Area of Study • Service Oriented Architecture An Emphasis on: • Legacy systems • Platform Interoperability • Web Services as the carrier • Architecture Design • Identification & Granularity of services

4. Motivation • Work Experience • Redundancy in Enterprise Applications. • Difficulty in Disparate application integration. • Code Reuse restricted to ‘Copy-Paste’ or Proprietary components ‘DLL Hell’. • Services/ business logic buried under complex procedures, SQL statements. • Failures in interdepartmental agreements (Our database is Highly-secured! Ex. Seibel and CPC Integration)

5. My Project SO CLOSE Service Oriented Container Loading SystEm An extension to CoLoSy, developed by CCE Software India.

6. What is a Container Loading System (CoLoSy)? A 3 Dimensional space optimizer VB6 based tool designed to optimize and speed up the loading of goods into rectangular cuboids. The product is based on a well-designed and tested 3D space-optimizing algorithm. CoLoSy optimizes spaces depending on the volume and weight of the goods and on last-in-first-out methods.

7. Why SO CLOSE ? • Currently, a Stand-alone product. • Hasn’t tapped the huge demand for Space Optimization in Transportation & Shipping industries. • Has the Potential to be an important part of an ERP system. • Legacy (10-Years old). Any extensibility requires new architecture. • A similar product ‘Truck Loading System’ can benefit from its SOA architecture.

8. Visual Basic Application (Executable) GUI Algorithm Graphics CLS MS Access Database Existing Architecture - A monolithic, Stand-Alone, Procedural, 2-Tier application.

9. SOA Architecture Stack Web Service Clients .Net Clients Proxy Objects WSDL Web Service Remoting BL/ Integration Layer – C#.Net Data Access Layer – VB.Net ADO.Net Database Legacy Component (VB6 DLL)

10. SOA Architecture • N-Tier, Extensible, Heterogeneous SOA Architecture

11. SOA Architecture (Contd.) Legacy Component • Created by extracting only the application logic code from the 2-tier legacy application. • Little/ No modification done to the application logic code it-self. • Procedural, Contains mostly application Logic. • No/ very minimal GUI Related code. • Shouldn’t contain any Message / dialogue boxes (No User interaction) • Introduce a Manager class to communicate with the BL/ Integration Layer. Contains methods to be invoked from this layer.

12. SOA Architecture (Contd.) BL/Integration Layer • Object-Oriented, Model Driven. • Provides a wrapper functionality to the legacy component through COM Interop. • Forms the crux of the application logic along with the legacy layer. • Provides Strong typing through XSD Schema, typed datasets (new in .Net). • Additional architectures (Web services, Remoting) can be built on top of this layer.

13. Class Diagram – BL Layer

14. SOA Architecture (Contd.) Data Access Layer • Contains utility functions to deal with the database objects (Make Connection, Create table, Get Dataset etc.). • All database related operations are performed only through this layer. • When the underlying database is changed, makes a very less impact on the code in other layers. • Helps debug and fine-tune database connectivity for any problems or performance.

15. SOA Architecture (Contd.) Web Services Layer • Provides platform independent access to the application logic as ‘Services’. • Uses XML as the data & message carrier. • Uses XSLT (Extensible Style Language Transformations) to create new XML, HTML documents based on the existing XML documents. • Interacts with other Web Services to provide messaging, additional functionality.

16. SOA Architecture (Contd.) Remoting/ DCOM Layer • A Future enhancement to this project. • A Microsoft implementation to be used Only with .Net Clients. • Uses Binary data & message transfer as opposed to Web Services XML. • Performance is better than Web Services, as it meant to be used with the .Net Clients Only. • Employs TCP/IP connection instead of HTTP.

17. Design Approach • Study the existing Legacy Application. • Identify and Model the Services using Use Case Diagram. • Determine the Scope & list Features. • Design the Deployment model. • Evaluate the existing database design. • Design the BL/ Integration Layer. • Design the Data Access Layer. • Determine the various client platforms the Services will be utilized.

18. Design Approach (contd.) • Evaluate the need for Various other technologies such as .Net Remoting, RMI, COM/DCOM based on the client platforms identified. • Design and implement additional features and functionality. • Test the implemented Services in incremental steps.

19. Design Approach (contd.) • Study the existing Legacy Application. • Evaluate your (organization) knowledge on the Legacy application. Decide whether you can treat this as a Black box or a White box (In this project, it was a ‘Gray Box’!) • Refactor the code to separate it from the GUI tier. • Identify the methods (group) that can be exposed as a service. Create an interface to provide a contract to the BL Integration layer containing all these methods. • Test these methods through a simple client (same technology as the legacy application). In this project, it is a VB6 application.

20. Design Approach (contd.) • Identify and Model the Services using Use Case Diagram. • Has Major impact on the entire system design. • Determine the granularity of services (Every method in OO Application is NOT a Service!). • Remember, a Service is referred to a visible, mostly result-oriented action. • Ex. ValidateCreditCard, CreateConsignment, CreateInvoice etc are Services. • Ex. CloseScreen, ConvertIntToString are unlikely to be called as Services. • Create a Use Case Diagram to depict services.

21. Design Approach (contd.) • Determine the Scope & list Features. • Extremely important to scope the project. Drives the requirements of various technologies. • Ex. If your Service clients are always Non-Microsoft platform, XML Web Services is your choice. Otherwise, you might even think of ‘Remoting’ technology. • List all the features that you ever want to implement in your application. Even if you don’t implement it in your early phases, it helps in future implementations.

22. Design Approach (contd.) • Design the Deployment model. • Helps in determining the deployment technology specific features. • Ex. IIS 6.0 Works great for Microsoft based Web Services, where as Apache could be better solution for a Java based counterpart.

23. Design Approach (contd.) • Evaluate the existing database design. • Databases in some Legacy applications mayn’t be multi-user compliant. Need to refactor the database for an SOA architecture. • Design mayn’t be good enough to support the Heavy Load transactions (Now that your application will have more users, client applications). • Consider a ‘wrapper’ database (though it degrades` the system performance) , if your legacy application operates directly on the database rather than objects. • Minimal upgrades such as adding Primary, foreign keys and providing Referential Integrity, Indexes should help increase the performance (This will be very critical with Web Service based SOA).

24. Design Approach (contd.) • Design the BL/ Integration Layer. • Probably the most important layer in the design. • Identify the missing methods and properties from the legacy application and incorporate them here. In this project, ‘Create’, ‘Read’, ‘Update’, ‘Delete’ methods are provided for Container and Good entities. • Provide wrapper methods for the existing legacy application methods available through ‘Contract’ classes. • Design an OO model as if it is a new application. • Chose the most recent and advanced technology such as Java, .Net to implement this layer.

25. Design Approach (contd.) • Design the Data Access Layer. • Optional, but really helpful in migrating to new database technologies. • Further abstracts the data access mechanism. • Identify the various Data Access Objects you would need in your system (Datasets, Table Objects, Connection Objects etc.) • Manage connection pooling mechanism here (Especially, if your DB Engine doesn’t provide one). • Extensible enough to provide the same level of access to various Database Formats.

26. Design & Implementation Details • Web Services • CreateContainer – Creates a new container into the database based on the I/P XML String with Container Details. • CreateGood – Creates a new Cube/Cylinder into the database based on the I/P XML String with Good Details. • CreateConsignment – Creates a new consignment into the database based on the I/P XML String with consignment Details. • Optimze – Optimizes the given consignment bythe specified method (LIFO, Weight or volume) and returns an XML string with the consignment results. • GetConsignmentImages – Returns the images of the 3D graphics generated by the legacy application during the optimized loading simulation of a consignment. • GetGoodList – Returns a list of goods available in the database. • GetContainerList – Returns a list of containers available in the database.

27. Design & Implementation Details (contd.) • Web Services • GetConsignmentList – Returns a list of consignments available in the database. • GetContainerInfo – Returns the details of a container in the form of XML string. • GetGoodInfo – Returns the details of a good in the form of XML string.

28. Design & Implementation Details (contd.) • Collaboration of Services • New Services are created by combining or collaborating multiple services. This helps in achieving the desired granularity of services for a specific requirement. • In SO CLOSE, the service ‘CreateConsignment’ is a collaboration of two existing services: • CreateContainer – Creates a new container. • CreateGood – Creates a new good. When the ‘CreateConsignment’ service is invoked, the Service layer checks to see if the container and goods corresponding to the given consignment exists. If so, it only creates the consignment, otherwise, it first creates the container and the good and then creates the consignment. This mayn’t be a desired functionality in the BL/ Integ. Layer, but in Web Service layer, it is desirable.

29. Design & Implementation Details (contd.) Use of XSLT in SOA • XML Output generated by an SOA application mayn’t suit all the client’s requirements. Data format may differ, amount of information required may vary in size, or may need to generate styled documents such as HTML etc. XSLT provides just that. • An XSLT maps one XML into another form XML or HTML. It is an XML based language to define the mapping. When an XML document is applied this XSLT, it generates a new XML or HTML document based on this definition. • Change of business vocabulary is very common in enterprise systems. What one department calls as an ‘Item’, may be called as a ‘Product’ in another department. These transformations are not just restricted to names, but even the values. Ex. A field in the original XML document may appear as ‘boolean’, but it may be required in ‘Yes’ ‘No’ format (As a ‘string’ in another XML document.

30. Design & Implementation Details (contd.) Use of XSLT in SOA (contd.) XSLT Sample from the project <?xml version='1.0' ?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="xml" indent="yes"/> <xsl:template match="/"> <ConsignmentResult> <Name> <xsl:value-of select="ConsignmentResult/Name"/> </Name> </ConsignmentResult> </xsl:template> <xsl:template match="ConsignmentResult"/>

31. Future Enhancements • SOAP Security & authentication. • Data Caching (useful, especially while generating the 3D images of the loading process). • Remoting for .Net Clients • Directory service using UDDI. • SLU (Service Level Usage) – New concept of mine (At least, new to me), which provides detailed information about the usage of services by various service consumers. This is particularly useful for ‘Billing Purposes’ and can be used in general in any SOA solution. • Client activated ‘Goods Loading’ 3D graphics implementation.

32. Problems Faced • COM Interoperability is difficult to achieve. • Incompatibility in Standardization • Java supports SOAP with attachments; SAAJ (SOAP API Attachments Java), but .Net doesn’t! Use DIME or MTOM. • SOAP Message encoding is NOT identical between Microsoft and Java technologies. • Time Spent in resolving some issues in Legacy Application (It’s 10+ years old!). • Developed using the very new Visual Studio 2005 and NetBeans 5.0 (Learning curve!). • XML to XML, XML to HTML using XSLT is good but, a bit time consuming for implementing.

33. Problems Faced (contd.) • Implementing Goods Loading 3D graphics as a Service was (still is !) a Big challenge. • Sending Binary data as a 2-dimensional byte array results in incompatible data types between .Net and Java. • The legacy Database is NOT very well designed. Had to overcome few problems posed by .Net XSD.

34. Acknowledgements • I can’t emphasize enough the help and guidance I obtained from Dr. Bina. I never felt as a distant student, as I could reach to her through phone/e-mail whenever I had a question. I Thank You Very Much for all that. • CCE India, my company, gave me all the support and opportunity to use their product for my research. I thank Mr. Ashis Dutta, Director and Syed Javed Akthar, HR Manager for all their support. • Last, but not the least, my wife Pratima and daughter Neha for their enduring support and understanding.