1. MIT Lincoln Laboratory A Service-Oriented Approach to Application Development Robert Darneille & Gary Schorer WPI MQP Presentations ICS Group 10 October 2007

2. MIT Lincoln Laboratory Acknowledgements WPI Faculty Advisors –Professor Ciaraldi Lincoln Laboratory Advisors –Peter Miller –Robert Nicholls –Kathy Carusone Lincoln Laboratory Testers –Peter Tecce

3. 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

4. MIT Lincoln Laboratory Applications with Services Without Services With Services Database Application 1 Search logic in C++ Application 2 Search logic in Java Application 3 Search logic in Perl Database Application 1 Service call in C++ Application 2 Service call in Perl Search logic in Java Web Service

5. MIT Lincoln Laboratory Technologies 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 Web Service Java Object Service Framework Spring WSDL Client SOAP Acegi 1 1:2:

6. 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

7. 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

8. 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

9. MIT Lincoln Laboratory 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 - Required development Acegi Services Java Service Framework - Provided by users

10. 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 Axis2s WSDL types differed from actual return types CXF failed to pass arrays/lists properly XFire properly passed and returned all data types

11. MIT Lincoln Laboratory 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 Springs Java object management Request Filter Auth. Provider XFire Error Message

12. 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

13. 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 Person.getPhoneNumber().getAreaCode() Person.getPhoneNumber().getValue().getAreaCode().getValue() Axis2 XFire

14. 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

15. 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