A Service-Oriented Approach to Application Development

1. A Service-Oriented Approach to Application Development Robert Darneille & Gary Schorer WPI MQP PresentationsICS Group 10 October 2007

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

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

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

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

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

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

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

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