Xem mẫu
Case Study
Figure 12. Deployment view of EAS
(a) Deployment view of all subsystems of EAS
(b) Deployment view of the recognition subsystem of EAS
1154
Case Study
Figure 13. Deployment of 3S
PDLQ¿QGLQJVRIWKLVSURMHFWWKDWFRQFHUQWKHHI-fectiveness of SODI using SOA. The three systems being built for this project were each developed in similar fashion overall, using similar modeling strategies and development schedules. However, the main difference between these projects is the extent that Web services were used.
The Role of Web Services
Using Web services for the EAS project was EHQH¿FLDOEXWOHVVVRWKDQIRUWKH6SURMHFW With the EAS project, Web services were used in a fashion similar to traditional middleware, whereas the 3S project used Web services in new and interesting ways: Some functions that do not
have to be changed very often are designed as a class library. Only functions that may be changed very often and need to be shared are designed as :HEVHUYLFHV7KH326SURMHFWDOVREHQH¿WHG from the use of Web services.
When building the EAS project, Web services were used for virtually all core functionality, on both the input and output side. In addition to the standard Windows forms classes and the Web services being used, a small class library was developed that contained a few helper classes. Since the main interface for EAS was written in Visual Basic (VB) .NET, and some client-side functionality was written in C#, this additional client-side functionality was stored in a class li-brary as a proxy. A class library is just a collection
1155
Case Study
of classes and interfaces bundled together into a VLQJOH¿OH7KHXVHRIWKLVOLEUDU\ZDVPDLQO\IRU communicating with the Web service as a proxy and reusing existing code built in C# that would take too much time to convert to VB .NET. How-ever, for the most part, EAS was a true wrapper for various Web service methods.
In relation to the EAS project, 3S used around 50% less Web service calls and 75% more func-tionality stored in class libraries. Since the 3S project was supposed to be used remotely, making long Web service calls frequently could have a VLJQL¿FDQWSHUIRUPDQFHLPSDFW,QVWHDGVRPHRI this prior Web service functionality was moved into a class library. Then, instead of using this class library on just the client side as in EAS, this new library was used by both the Web services and the Windows client. Using the class library in this fashion allowed the two main system com-ponents to share functionality without the worry RIYHUVLRQLQJFRQÀLFWVRUWKHQHHGWRPDQXDOO\ copy classes from project to project. In a vein similar to Web services that are useful for sharing application logic between different systems, class libraries can also be used similarly. For example, in the EAS project, scheduling components were built directly into classes in the application. In the 3S project, the scheduling components were built to be more general and were stored in the class library. If developers wanted to build an extension to EAS that used scheduling, they would have to copy the scheduling classes and manually rewrite DQGUHQDPHWKHPWR¿WLQWRWKHQHZSURMHFW%\ including the scheduling functions in a class li-EUDU\DOO\RXQHHGWRGRLVUHIHUHQFHWKHGOO¿OH DQGVWDUWGHYHORSLQJ7KLVLVYHU\HI¿FLHQWDQG a great way to increase productivity while Web services are being used as the main integration interfaces.
The POS project relied on Web services for even less than the 3S project. Since the POS system is used heavily for input purposes, it is unlikely to be used from outside your local area QHWZRUNOHVVEHQH¿WLVJDLQHGIURPXVLQJ:HE
services. However, Web services are still useful for logging in cashiers and authorizing them to use the POS system, and reporting on items sold and cashier activity. Without using a Web service, a rewrite of the EAS recognition system would be required. Since this functionality already ex-LVWVLQD:HEVHUYLFHRQO\PLQRUPRGL¿FDWLRQV QHHGWREHPDGHEHIRUHWKH¿QJHUSULQWLQJ:HE services are ready to be consumed in the POS application. Instead of depending on class librar-ies so much, the system interfaced directly with the SQL server being used as the data store by adopting a tightly coupled approach so as not to lose performance. This direct interface provided better transactional support then a series of Web services could provide and allowed the interface to react much more quickly to user input.
Lessons Learned
First of all, software developers and integrators can easily transition from object-oriented analysis and design to service-oriented analysis and design since the valuable experiences of the develop-ers in object-oriented architectures and design methodology are naturally streamlined with the service-oriented architecture and design meth-odology supporting loose couplings of software components. Both three-layered and multitier architectural patterns have been used to design and deploy object-oriented applications. The service-oriented architecture simply enhances the interoperability of some components that may be integrated with other remote components within organizations or across organizations by allowing standard interfaces and interaction protocols. Also, one of the design methods that have been adopted in object-oriented software developments, RUP, can be applied to service-oriented software developments with the revised 4+1 view.
Secondly, SODI goes much smoother without having to rewrite the same code you had writ-ten before on previous projects. This is possible
1156
Case Study
because the Web service technology brings a BIS in which software components can easily be integrated with others (they are loosely coupled through Web services). You could just change your external interface for each situation, and then convert data into the formats supported by the system’s Web services.
SODI allows developers to separate the pre-sentation logic from the business logic in applica-tions. A Windows desktop application or a Web application is located on the platforms of service consumers. The Web services are deployed onto the Web service platforms of service producers. The presentation tier, a Windows desktop appli-cation or a Web application, interacts with Web services that are located at remote Web service platforms. The Web services interact with vari-ous business objects. Also, the Web service can interact with other Web services that located at other platforms recursively.
Using Web services can explicitly represent the process view, which describes dynamic features of a software system. If only atomic services are used (like this project), the services are considered special classes, that is, interfaces. The objects of the interfaces are deployed onto a tier on which a Web service engine resides. Class and deployment diagrams are used to show the process view of the atomic services. If several atomic services can be composed to a composite service, the composite service can be described in an activity diagram to show the process view.
FUTURE WORK
:HEVHUYLFHVDOORZHGWKHYLVLRQRIÀH[LEOHLQWHU-faces to become reality rather than remain in the world of fantasy. The customization of business LQIRUPDWLRQV\VWHPVWRUHÀHFWWKHEUDQGRIDEXVL-QHVVZLOOEHRIJUHDWEHQH¿WWRDQ\RQHZKRUXQVD business. Web services hold strong promise in the future of business and the future of our daily lives
as development on services progresses, taking us one step closer to a totally connected world.
Future work on improving the SOA architec-ture can progress as soon as new technologies are in place. As semantic description languages for services become commonplace, people can start describing the services with meaningful semantic descriptions. Once service orchestration languages start becoming feasible to implement, RUFKHVWUDWLRQWRRONLWVFRXOGEHGHYHORSHGVSHFL¿-cally for SODI systems. The composition of Web services will bring more explicit process views to the 4+1 view, and the dynamics of the integrated system can be understood in terms of business SURFHVVZRUNÀRZ
REFERENCES
Alonso, G., Casati, F., Kuno, H., & Machiraju, V. (2004). Web services concepts, architectures and applications. Springer Verlag.
Association for Retail Technology Standards (ARTS). (2003). Data model. Retrieved from http://www.nrf-arts.org
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). 7KHXQL¿HGPRGHOLQJODQJXDJHXVHUJXLGH Ad-dison Wesley.
Connolly, T., & Begg, C. (2005). Database systems: A practical approach to design, implementation, and management (4th ed.). Addison-Wesley.
Coulouris, G., Dollimore, J., & Kindberg, T. (2002).Distributed systems: Concepts and design. Addison Wesley.
Erl, T. (2004). Service-oriented architecture: A ¿HOGJXLGHWRLQWHJUDWLQJ;0/DQG:HEVHUYLFHV Upper Saddle River, NJ:Prentice Hall Professional Technical Reference.
IBM. (2006a). 5DWLRQDOXQL¿HGSURFHVV583 Retrieved from http://www-306.ibm.com/soft-ware/awdtools/rup/index.html
1157
Case Study
IBM. (2006b). Web services policy framework (WS-Policy). Retrieved from http://www-128. LEPFRPGHYHORSHUZRUNVOLEUDU\VSHFL¿FDWLRQ ws-polfram/
Jacobson, I., Booch, G., & Rumbaugh. J. (n.d.). 7KHXQL¿HGVRIWZDUHGHYHORSPHQWSURFHVV Ad-dison Wesley.
Kerner, L. (2000). Biometrics and time & at-tendance. Integrated Solutions. Retrieved from http://www.integratedsolutionsmag.com/Ar-ticles/2000_11/001109.htm
Kruchten, P. B. (1995). The 4+1 view model of architecture. IEEE Software, 12(6), 42-50.
Linthicum, D. S. (2003a). Next generation ap-plication integration. Addison-Wesley.
Linthicum, D.S (2003b). Where enterprise ap-SOLFDWLRQ LQWHJUDWLRQ ¿WV ZLWK :HE VHUYLFHs. Software Magazine. Retrieved from http://www. softwaremag.com/L.cfm?Doc=2003-April/Web-Services
Object Management Group (OMG). (2007). Uni-¿HGPRGHOLQJODQJXDJH80/ Retrieved from http://www.uml.org/
Organization for the Advancement of Structured Information Standards (OASIS). (n.d.). Universal description, discovery and integration (UDDI). Retrieved from http://www.uddi.org/
Organization for the Advancement of Structured Information Standards (OASIS). (2006). Web services security (WS-Security). Retrieved from http://www.oasis-open.org/committees/tc_cat. php?cat=security
World Wide Web Consortium Extensible Markup Language (W3C XML) Protocol Working Group. (2006). Simple object access protocol (SIAP). Retrieved from http://www.w3.org/2000/xp/ Group/
World Wide Web Consortium (W3C) Semantic Web Services Interest Group. (2006a). Semantic Web services framework (SWSF). Retrieved from http://www.w3.org/Submission/2004/07/
World Wide Web Consortium (W3C) Semantic Web Services Interest Group. (2006b). Web on-tology language for services (OWL-S). Retrieved from http://www.w3.org/Submission/2004/07/
World Wide Web Consortium (W3C) Semantic Web Services Interest Group. (2006c). Web ser-vices modeling ontology (WSMO). Retrieved from http://www.w3.org/Submission/2005/06/
World Wide Web Consortium (W3C) Semantic Web Services Interest Group. (2006d). Web services semantic (WSDL-S). Retrieved from http://www.w3.org/Submission/2005/10/
World Wide Web Consortium (W3C) Web Ser-vices Addressing Working Group. (n.d.). Web services addressing (WS-Addressing). Retrieved from http://www.w3.org/Submission/ws-address-ing/
World Wide Web Consortium (W3C) Web Ser-vices Description Working Group. (2006). Web services description language (WSDL). Retrieved from http://www.w3.org/2002/ws/desc/
This work was previously published in Enterprise Architecture and Integration: Methods, Implementation and Technologies, edited by W. Lam and V. Shankararaman, pp. 292-305, copyright 2007 by Information Science Reference (an imprint of IGI Global).
1158
...
- tailieumienphi.vn
nguon tai.lieu . vn