DOC PREVIEW
USF CS 682 - Integration and Interoperation

This preview shows page 1-2-24-25 out of 25 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 25 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

{small lecturenumber - hepage :} Integration and Interoperation{small lecturenumber - hepage :} Enterprise Integration{small lecturenumber - hepage :} Enterprise Archtectures - J2EE{small lecturenumber - hepage :} Enterprise Architectures - .NET{small lecturenumber - hepage :} Integrating Legacy Systems{small lecturenumber - hepage :} How Legacy Systems Arise{small lecturenumber - hepage :} Legacy Systems: Negative{small lecturenumber - hepage :} Legacy Systems: Positive{small lecturenumber - hepage :} Legacy Systems - example{small lecturenumber - hepage :} Legacy Systems - example{small lecturenumber - hepage :} Accomodating Legacy Systems{small lecturenumber - hepage :} Accomodating Legacy Systems{small lecturenumber - hepage :} Migration{small lecturenumber - hepage :} Migrating - Converters{small lecturenumber - hepage :} Using Converters for Interoperation{small lecturenumber - hepage :} Use cases for SOC{small lecturenumber - hepage :} Interoperation within an Enterprise{small lecturenumber - hepage :} Interoperation between enterprises{small lecturenumber - hepage :} Dynamic software configuration{small lecturenumber - hepage :} Service Composition{small lecturenumber - hepage :} Service Composition{small lecturenumber - hepage :} Example{small lecturenumber - hepage :} Challenges of composition{small lecturenumber - hepage :} SummaryDistributed Software DevelopmentIntegration and InteroperationChris BrooksDepartment of Computer ScienceUniversity of San FranciscoDepartment of Computer Science — University of San Francisco – p. 1/??12-2: Integration and Interoperation•A primary argument for service-oriented computing is to easethe burden of getting heterogenous components to play nicelytogether.•Integration is used to refer to pulling together several resourcesinto a single logical resource.•Interoperation is used to refer to a layer that allows existingcomponents to work together.•In practice, the concepts are often blurred.Department of Computer Science — University of San Francisco – p. 2/??12-3: Enterprise Integration•Enterprise Integration refers to the problems surroundingheterogeneous enviroments and data representations.•Enterprise Application Integration refers to the problemsinvolved in allowing heterogeneous environments andapplications to communicate.◦J2EE, .NET•Enterprise Information Integration refers to the problem ofresolving inconsistencies and semantic differences betweendata sources.Department of Computer Science — University of San Francisco – p. 3/??12-4: Enterprise Archtectures - J2EEDepartment of Computer Science — University of San Francisco – p. 4/??12-5: Enterprise Architectures - .NETDepartment of Computer Science — University of San Francisco – p. 5/??12-6: Integrating Legacy Systems•A challenge to integration is the presence of legacy systems.•A pejorative term for computing systems that◦run on obsolete hardware and nonstandard communicationnetworks◦run poorly documented, unmaintainable software◦consist of poorly modeled databases on hierarchical ornetwork DBMSs◦support rigid user interfacesDepartment of Computer Science — University of San Francisco – p. 6/??12-7: How Legacy Systems Arise•Proprietary software◦not documented◦not supporting industry standards (vendors who hope tolock in the market through incompatibility)◦No standards developed.•Semantics embedded procedurally in the code•Ad hoc changes to software in response to◦changing requirements, because of changes in laws,regulations, competition, or other business needs◦bugsDepartment of Computer Science — University of San Francisco – p. 7/??12-8: Legacy Systems: Negative•Difficulties in reuse and sharing of data and programs causeredundancy, wasted effort, and integrity violations•Closed: typically, use a vendor’s proprietary software, andcannot cooperate with other systemsDepartment of Computer Science — University of San Francisco – p. 8/??12-9: Legacy Systems: Positive•Fulfill crucial business functions•Work, albeit suboptimally•Run the world’s airline reservation systems•Run most air traffic control programs•Have dedicated users•Perform critical functions•Represent huge investments in time and moneyDepartment of Computer Science — University of San Francisco – p. 9/??12-10: Legacy Systems - example•USF’s Data Management systems are all legacy systems◦Development◦Financial Aid/Bursar◦Registrar◦Payroll/HR•Out-of-date, proprietary systems (they run on VMS!)•Difficult to maintain•Poor user interface.•Why are they still in use?Department of Computer Science — University of San Francisco – p. 10/??12-11: Legacy Systems - example•Why are they still in use?•Continual usage. Many of these systems cannot be unavailablefor extended periods.◦Periods of heavy usage may not align•Data transfer is a big, complex job•Money◦Expense devoted to current system◦New systems are very expensive.•Institutional inertia◦New systems require retraining, change in a large numberof places.•USF is currently transitioning away from its legacy systems.Department of Computer Science — University of San Francisco – p. 11/??12-12: Accomodating Legacy Systems•Introduce new technology as needed•Integrate legacy systems with new components•Integrate the legacy systems with each other•But don’t spoil existing applications◦Is this even possible?◦If not, why not?◦If so, how might one achieve this?Department of Computer Science — University of San Francisco – p. 12/??12-13: Accomodating Legacy Systems•Consider the effort per legacy system one is willing to invest in◦modifying existing applications◦Acquiring knowledge about, i.e., models of, the existingapplications•The limits on the ranges of the new applications•Whether improvements to legacy applications are soughtDepartment of Computer Science — University of San Francisco – p. 13/??12-14: Migration•Updating technology is◦Essential◦A continual process•All at once?◦Expensive◦Risky◦Brittle◦Frustrating for users•Gradual change: dismantle legacy and build desired systemhand-in-hand◦Install and test piecemeal◦Need to ensure that compositional functionality remainscorrect.Department of Computer Science — University of San Francisco – p. 14/??12-15: Migrating - Converters•A converter is a wrapper that translates data or interfacesbetween applications.•An old-to-new


View Full Document

USF CS 682 - Integration and Interoperation

Documents in this Course
Load more
Download Integration and Interoperation
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Integration and Interoperation and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Integration and Interoperation 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?