Presentation

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.
• Hasnt 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
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.
• Shouldnt 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 dont
  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 maynt be
  multi-user compliant. Need to refactor the
  database for an SOA architecture.
• Design maynt 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 doesnt 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
  maynt 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 maynt
  suit all the clients 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
• lt?xml version'1.0' ?gt
• ltxslstylesheet version"1.0" xmlnsxsl"http//ww
  w.w3.org/1999/XSL/Transform"gt
• ltxsloutput method"xml" indent"yes"/gt
• ltxsltemplate match"/"gt
• ltConsignmentResultgt
• ltNamegt
• ltxslvalue-of select"ConsignmentResult/Na
  me"/gt
• lt/Namegt
• lt/ConsignmentResultgt
• lt/xsltemplategt
• ltxsltemplate match"ConsignmentResult"/gt

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 doesnt! Use
  DIME or MTOM.
• SOAP Message encoding is NOT identical between
  Microsoft and Java technologies.
• Time Spent in resolving some issues in Legacy
  Application (Its 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 cant 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.