1 / 15

A Service-Oriented Approach to Application Development

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

anika
Download Presentation

A Service-Oriented Approach to Application Development

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related