A Service-Oriented Approach to
Application Development
Robert Darneille & Gary Schorer
WPI MQP Presentations
ICS Group
10 October 2007
MIT Lincoln Laboratory
Acknowledgements
• 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
Database
With Services
Database
Application 1
Search
logic in
C++
Application 2
Search
logic in
Java
Application 3
Search
logic in
Perl
Web Service
Search logic in
Java
Application 1
Service call
in C++
Application 2
Service call
in Perl
MIT Lincoln Laboratory
Technologies
• Spring
Java Object
– Framework which converts
XML into Java objects and
manages their relationships
Spring
• Service Framework
– Exposes Java objects as
web services
Service Framework
• WSDL
– XML-based format used to
describe service operations
WSDL
• Acegi
– Security provider which
restricts access to
resources
• SOAP
– XML-based message format
used by services
Web Service
Acegi
1: 1
2:
SOAP
Client
MIT Lincoln Laboratory
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
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
given
Apache Tomcat
Acegi
• Server was Apache Tomcat
• Security provider was Acegi
Services
Service
Framework
Java
• 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
Request
SOAP messages
• Wrote a filter to retrieve token
from SOAP headers
Filter
• Authentication provider
checks token against
authentication database
Auth. Provider
• If successful, passes request
along to XFire
– Makes use of Spring’s Java
object management
XFire
Error Message
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 (‘1105’) 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
authorizations
• Reexamine CXF for possible fixes
– Same developers as XFire
– Should perform just as effectively
MIT Lincoln Laboratory
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
MIT Lincoln Laboratory