Made available in DSpace on 2014-06-12T17:39:55Z (GMT). No. of bitstreams: 2 arquivo6987_1.pdf: 1570719 bytes, checksum: eadf1c2c3a3411ae9aceddab6ec811a4 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2004 / A complexidade e o crescimento da Internet fizeram com que vários modelos e propostas para a comunicação entre aplicações fossem apresentados como opção de computação distribuída neste ambiente. Porém, em todos estes faz-se necessário a introdução de requisitos próprios de cada modelo, a serem adotados por aqueles que desejam utilizá-los. Como alternativa, apresenta-se a tecnologia de Web Services, caracterizada pelo baixo acoplamento entre as partes e fundamentada em XML, HTTP e outros padrões já estabelecidos na Internet. Para aderir a esta tecnologia, a plataforma de desenvolvimento Java apresenta o software Java WSDP(Java Web Services Development Package) que possibilita o fornecimento e o consumo de Web Services a partir de programação Java. Nas redes metropolitanas do poder executivo brasileiro, ocorre situação semelhante a heterogeneidade de linguagens e plataformas, como encontramos na Internet. Neste contexto, este trabalho propõe a implementação de Web Service em Java para a divulgação do orçamento público, como solução para integrar órgãos participantes das redes metropolitanas e disponibilizar tais informações para acesso público. Apresentamos estudo de caso relativo ao contexto anteriormente citado e implementamos protótipo para fornecimento de Web Services, bem como aplicação web para consumo e divulgação das informações obtidas

Service oriented architecture (SOA) and web services make it possible to construct rich and complex distributed systems which operate at internet scales. However, the underlying design principles of SOA can lead to management problems for processes over web services.<p> This thesis identifies several potential problems with the management of processes over web services, and proposes the use of explicit context as a possible solution. The available options are explored, and the WS-Context specification is implemented and evaluated.<p> The SOA design principles of loose coupling, interaction at an interface, autonomy, and composablity can lead to management problems for processes over web services. Processes over web services where one composite service invokes other composite services which in turn invoke other composite services can lead to complex invocation trees. These invocation trees may be different at different times due to the shifting effect of loose coupling, as new services are swapped in to replace those in previous invocations. In such an environment how well can we define the interface of the top level service in a static document such as a WSDL? Because there is a separation between the ultimate service consumer, and the ultimate service provider how can the service consumer correctly assign fault when a service fails? When concurrency is used, and encouraged, how can we deal with the inevitable race conditions and deadlock? In distributed systems where portions of processes execute on systems beyond our organizational control, how can we pause, or kill these processes? Many of these systems model long-running business processes. How do we communicate changes in process requirements?<p> The use of an explicit context is a potential solution to these types of problems. The abstraction context provides an environment in which the process participants can describe their requirements, query those of other process participants, and react to changes in the environment.<p> A sample context server, based on the WS-Context specification, was implemented using the Erlang language. The sample context server provides the basic operations required to manage and store contextual information about a process.<p> The sample context server was evaluated to determine the cost of employing a context as part of a web service based software system. The performance of the sample server was also evaluated.<p> Test were conducted on the time costs of the basic operations of the context server, and they were found to have a constant time cost. The operations for getting and setting the contents of the context were found to have a time cost dependant on the size of the context. The cost of propagating the context along a chain of service invocations was tested and found to have an overhead which increased linearly with the length of the service invocation chain.<p> The context server was stress tested using a closed loop test which simulated the interaction of a number of concurrent clients, and an open loop test which simulated bursts of arriving requests. The open loop testing showed that the context server could handle 75 concurrent clients. Beyond 75 concurrent clients, the response times of the context server began to slowly increase. The closed loop testing showed that the context server had a maximum throughput of 190 requests per second for bursts of 200 requests with an interarrival time of 4 milliseconds.

Service oriented architecture (SOA) and web services make it possible to construct rich and complex distributed systems which operate at internet scales. However, the underlying design principles of SOA can lead to management problems for processes over web services.<p> This thesis identifies several potential problems with the management of processes over web services, and proposes the use of explicit context as a possible solution. The available options are explored, and the WS-Context specification is implemented and evaluated.<p> The SOA design principles of loose coupling, interaction at an interface, autonomy, and composablity can lead to management problems for processes over web services. Processes over web services where one composite service invokes other composite services which in turn invoke other composite services can lead to complex invocation trees. These invocation trees may be different at different times due to the shifting effect of loose coupling, as new services are swapped in to replace those in previous invocations. In such an environment how well can we define the interface of the top level service in a static document such as a WSDL? Because there is a separation between the ultimate service consumer, and the ultimate service provider how can the service consumer correctly assign fault when a service fails? When concurrency is used, and encouraged, how can we deal with the inevitable race conditions and deadlock? In distributed systems where portions of processes execute on systems beyond our organizational control, how can we pause, or kill these processes? Many of these systems model long-running business processes. How do we communicate changes in process requirements?<p> The use of an explicit context is a potential solution to these types of problems. The abstraction context provides an environment in which the process participants can describe their requirements, query those of other process participants, and react to changes in the environment.<p> A sample context server, based on the WS-Context specification, was implemented using the Erlang language. The sample context server provides the basic operations required to manage and store contextual information about a process.<p> The sample context server was evaluated to determine the cost of employing a context as part of a web service based software system. The performance of the sample server was also evaluated.<p> Test were conducted on the time costs of the basic operations of the context server, and they were found to have a constant time cost. The operations for getting and setting the contents of the context were found to have a time cost dependant on the size of the context. The cost of propagating the context along a chain of service invocations was tested and found to have an overhead which increased linearly with the length of the service invocation chain.<p> The context server was stress tested using a closed loop test which simulated the interaction of a number of concurrent clients, and an open loop test which simulated bursts of arriving requests. The open loop testing showed that the context server could handle 75 concurrent clients. Beyond 75 concurrent clients, the response times of the context server began to slowly increase. The closed loop testing showed that the context server had a maximum throughput of 190 requests per second for bursts of 200 requests with an interarrival time of 4 milliseconds.

Thesis (M.S. in Software Engineering)--Naval Postgraduate School, December 2009. / Thesis Advisor(s): Shing, Man-Tak; Michael, Bret. "December 2009." Description based on title screen as viewed on January 26, 2010. Author(s) subject terms: SOA, web services, open architecture, command and control, sensor management. Includes bibliographical references (p. 76-78). Also available in print.

Diss. (sammanfattning) Luleå : Luleå tekniska universitet, 2009. / Härtill 6 uppsatser.

Not available / text

Huge growth of the Internet is due to the large number of websites and web services through which information is easily accessible. E-commerce and e-services obtain much private data from users for various reasons such as advertising, marketing, etc. Collection, storage, and usage of private data are subject to various standards, privacy laws, and regulations. To adhere to these legal requirements, many privacy services, such as secure data transmission, authentication, notice, and consent, are required. Inclusion of these required privacy services early in the life cycle of the software development is preferred and advocated, but not fully adhered to. Inclusion of privacy services in legacy software and currently developed software is required. We describe software architecture and a system for automatic inclusion of privacy services, under the supervision of privacy expert, into web pages after the development phase of the Software Development Life Cycle. This will help organizations to adhere to standards, privacy laws, and regulations when collecting private data online from its clients. We also describe a prototype that we have developed as a proof-of-concept to demonstrate the feasibility of our approach.

Zugl.: Magdeburg, Univ., Diplomarbeit, 2005

Techn. University, Diss., 2005--Darmstadt.

Stuttgart, Univ., Diplomarbeit, 2006.