a service oriented approach to application development n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
A Service-Oriented Approach to Application Development PowerPoint Presentation
Download Presentation
A Service-Oriented Approach to Application Development

Loading in 2 Seconds...

play fullscreen
1 / 15

A Service-Oriented Approach to Application Development - PowerPoint PPT Presentation


  • 117 Views
  • Uploaded on

A Service-Oriented Approach to Application Development. Robert Darneille & Gary Schorer WPI MQP Presentations ICS Group 10 October 2007. Acknowledgements. WPI Faculty Advisors Professor Ciaraldi Lincoln Laboratory Advisors Peter Miller Robert Nicholls Kathy Carusone

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A Service-Oriented Approach to Application Development' - anika


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a service oriented approach to application development

A Service-Oriented Approach to Application Development

Robert Darneille & Gary Schorer

WPI MQP PresentationsICS Group

10 October 2007

acknowledgements
Acknowledgements
  • WPI Faculty Advisors
    • Professor Ciaraldi
  • Lincoln Laboratory Advisors
    • Peter Miller
    • Robert Nicholls
    • Kathy Carusone
  • Lincoln Laboratory Testers
    • Peter Tecce
web services
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
applications with services
Applications with Services

With Services

Without Services

Database

Database

Application 1

Web Service

Search logic in C++

Search logic in Java

Application 2

Application 1

Search logic in Java

Service call in C++

Application 2

Application 3

Service call in Perl

Search logic in Perl

technologies
Technologies

Java Object

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

Spring

Service Framework

WSDL

Web Service

Acegi

SOAP

1:

2:

1

Client

problem
Problem
  • 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
our solution
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
skeleton requirements
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
skeleton creation
Skeleton Creation
  • Most components were given
  • Server was Apache Tomcat
  • Security provider was Acegi
  • Needed a service framework to make Java objects accessible as services
  • Needed Acegi to authenticate from SOAP messages, interact with service framework

Apache Tomcat

Acegi

Service Framework

Services

Java

- Required development

- Provided by users

service framework selection
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
acegi configuration
Acegi Configuration
  • Needed to authenticate from SOAP messages
  • Wrote a filter to retrieve token from SOAP headers
  • Authentication provider checks token against authentication database
  • If successful, passes request along to XFire
    • Makes use of Spring’s Java object management

Request

Filter

Auth. Provider

XFire

Error Message

versioning recommendations
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
client stub generation
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()

future work
Future Work
  • Integrate application authentication with existing directories
    • LDAP, SAP
  • Create a web interface for managing application authorizations
  • Reexamine CXF for possible fixes
    • Same developers as XFire
    • Should perform just as effectively
summary
Summary
  • 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