A Service Oriented Approach to Application Development

Document Sample
A Service Oriented Approach to Application Development Powered By Docstoc
					A Service-Oriented Approach to
   Application Development

     Robert Darneille & Gary Schorer

          WPI MQP Presentations
               ICS Group

              10 October 2007

                                   MIT Lincoln Laboratory

• WPI Faculty Advisors
    – Professor Ciaraldi

• Lincoln Laboratory Advisors
    – Peter Miller
    – Robert Nicholls
    – Kathy Carusone

• Lincoln Laboratory Testers
    – Peter Tecce

                                       MIT Lincoln Laboratory
                         Web Services

• Make applications available for access through the web
    – Maximize code reuse, minimize rewriting
    – Write one service to perform a task
    – Applications call service, no need to rewrite task logic

• Platform-independent, language-independent
    –   Clients can use any language
    –   Services can be implemented in any language
    –   Services communicate using SOAP
    –   Declare their functionality using WSDL

                                                       MIT Lincoln Laboratory
             Applications with Services
 Without Services                    With Services

Database                      Database

           Application 1
                             Web Service
                               Search logic in
                  logic in

           Application 2                   Application 1
                  Search                     Service call
                  logic in                   in C++

           Application 3                   Application 2
                                             Service call
                                             in Perl
                  logic in
                                            MIT Lincoln Laboratory

• Spring                                    Java Object
   – Framework which converts
     XML into Java objects and
     manages their relationships             Spring
• Service Framework
   – Exposes Java objects as          Service Framework
     web services
   – XML-based format used to      WSDL                Web Service
     describe service operations
• Acegi                                        Acegi
   – Security provider which
     restricts access to
     resources                       1: 1              2:      SOAP
   – XML-based message format
     used by services                        Client

                                                 MIT Lincoln Laboratory

• Services are desirable, but…
• Lack of standards
    – No consistent versioning technique
    – No consistent authentication protocol

• Everyone developing independently
    – Different platforms
    – Difficult to communicate

• Everyone conducting independent research
    – No shared research pool to draw on

                                              MIT Lincoln Laboratory
                         Our Solution

• Create a service skeleton
    –   Distributable file used as a development base
    –   Quick, easy creation of Java services
    –   Authenticating calling applications
    –   Consistency between service structures

• Document usage/recommendations
    – How to setup the skeleton
    – How to handle versioning
    – How to generate client stubs

                                                        MIT Lincoln Laboratory
               Skeleton Requirements

• Expose Java classes as services
• Run inside Apache Tomcat
• Authenticate other applications
• Use Acegi (Spring) Security for authentication
• Load Java objects via Spring

                                               MIT Lincoln Laboratory
                     Skeleton Creation

• Most components were              Apache Tomcat
• Server was Apache Tomcat
                                Services     Service
• Security provider was Acegi              Framework

• Needed a service framework
  to make Java objects
  accessible as services

• Needed Acegi to
  authenticate from SOAP
  messages, interact with
  service framework             - Required development
                                - Provided by users
                                               MIT Lincoln Laboratory
           Service Framework Selection

• 3 major candidates identified: Axis2, CXF, XFire
• Tested by making services out of the same Java objects
    – Ran same set of operations, passing and returning many
      different data types

• Tested for reliable retrieval of many data types
• Axis2‟s WSDL types differed from actual return types
• CXF failed to pass arrays/lists properly
• XFire properly passed and returned all data types

                                                  MIT Lincoln Laboratory
                     Acegi Configuration

• Needed to authenticate from
  SOAP messages                              Request

• Wrote a filter to retrieve token
  from SOAP headers                           Filter

• Authentication provider
  checks token against                  Auth. Provider
  authentication database

• If successful, passes request
  along to XFire
    – Makes use of Spring‟s Java     XFire          Error Message
      object management

                                              MIT Lincoln Laboratory
          Versioning Recommendations

• Backwards compatibility must be monitored closely
• Addition of operations, data maintains compatibility
• Removing/changing existing operations, data does not
• Developers must prevent people referencing an old version
  from using a new one
    – Changes in meaning, but not data type, could be dangerous
    – Example: operations which reference groups by name („11-
      05‟) changed to reference by ID

• Recommend major-minor versioning (e.g. 1.0, 1.1, 2.0)
    – Major version change means not backwards compatible
    – Minor version change means new features
    – Include major version in namespace

                                                  MIT Lincoln Laboratory
                Client Stub Generation

• Client generators take in a WSDL, generate a client “stub”
    – Automatically handles Java    XML conversions, networking

• Makes it easier for other people to use a service
• Compared XFire and Axis2 client generators
• Axis2 generates better clients
• XFire wraps Java types, doubles the layers used to access
   meaningful data

• Included instructions of generating clients with Axis2

Axis2   Person.getPhoneNumber().getAreaCode()

XFire   Person.getPhoneNumber().getValue().getAreaCode().getValue()

                                                    MIT Lincoln Laboratory
                         Future Work

• Integrate application authentication with existing directories
    – LDAP, SAP

• Create a web interface for managing application

• Reexamine CXF for possible fixes
    – Same developers as XFire
    – Should perform just as effectively

                                                  MIT Lincoln Laboratory

• Distributable base for new application development
• Easy means of creating services from Java objects
• Integrated authentication of remote applications
• “Best practices” for versioning services
• Recommendations, instructions for client generation
• Ease creation of services from new applications
• Ease adoption of services overall

                                               MIT Lincoln Laboratory

Shared By: