Código de Defesa do Consumidor = Lei nº 8.078/1990 (Lei Ordinária) de 11/09/1990
http://www.planalto.gov.br/ccivil_03/Leis/L8078.htm
O Blog MulherTech.com.br é para mulheres que trabalham e amam tecnologia. Assuntos abordados neste Blog: Gestão de Projetos, Marketing Digital, Tecnologia da Informação, Ciência da Computação, Cloud Computing, Rede de Computadores Wireless, Rede TCP-IP (IPv4 e IPv6), Rede 5G, Linux, Windows Server, Windows 11, Data Science, Big Data, Inteligência Artificial, Linguagens de Programação Web, Frontend, Backend, etc.
Código de Defesa do Consumidor = Lei nº 8.078/1990 (Lei Ordinária) de 11/09/1990
http://www.planalto.gov.br/ccivil_03/Leis/L8078.htm
Código de Processo Penal (complemento) = Lei nº 3.689/1941 (Decreto-Lei) de 03/10/1941
http://www.planalto.gov.br/ccivil_03/decreto-lei/Del3689.htm
CPP - Código Penal Brasileiro = Lei nº 2.848/1940 (Decreto-Lei) de 07/12/1940)
http://www.planalto.gov.br/ccivil_03/decreto-lei/Del2848.htm
CLT - Consolidação das Leis de Trabalho = Lei nº 5.452/1943 (DECRETO-LEI) de 01/05/1943
http://www.planalto.gov.br/ccivil_03/decreto-lei/Del5452.htm
CPC 2015 - Novo Código de Processo Civil Brasileiro = Lei nº 13.105 de 16/03/2015
http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13105.htm
Código de Processo Civil Brasileiro (complemento) = Lei nº 5.869/1973 de 11/01/1973
http://www.planalto.gov.br/ccivil_03/leis/L5869.htm (Lei velha, não está em vigor)
Código Civil Brasileiro = (Lei nº 10.406, de 10/01/2002)
https://www.planalto.gov.br/ccivil_03/LEIS/2002/L10406.htm
Uma dúvida. A Lei da Liberdade Econômica (Lei 13.874/2019) alterou a Lei das empresas LTDA, equiparando ao MEI, para legalizar as pessoas poder abrir empresas LTDA com apenas um sócio?
Lei da Liberdade Econômica (Lei 13.874/2019)
https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2019/lei/L13874.htm
Lei das empresas LTDA (DECRETO No 3.708, DE 10 DE JANEIRO DE 1919)
https://www.planalto.gov.br/ccivil_03/decreto/antigos/d3708.htm
EU-US Privacy Shield
The United States and the European Commission have committed to a new Trans-Atlantic Data Privacy Framework, which will foster trans-Atlantic data flows and address the concerns raised by the Court of Justice of the European Union when it struck down in 2020 the Commission’s adequacy decision underlying the EU-U.S. Privacy Shield framework.
This Framework will reestablish an important legal mechanism for transfers of EU personal data to the United States. The United States has committed to implement new safeguards to ensure that signals intelligence activities are necessary and proportionate in the pursuit of defined national security objectives, which will ensure the privacy of EU personal data and to create a new mechanism for EU individuals to seek redress if they believe they are unlawfully targeted by signals intelligence activities. This deal in principle reflects the strength of the enduring U.S.-EU relationship, as we continue to deepen our partnership based on our shared democratic values.
This Framework will provide vital benefits to citizens on both sides of the Atlantic. For EU individuals, the deal includes new, high-standard commitments regarding the protection of personal data. For citizens and companies on both sides of the Atlantic, the deal will enable the continued flow of data that underpins more than $1 trillion in cross-border commerce every year, and will enable businesses of all sizes to compete in each other’s markets. It is the culmination of more than a year of detailed negotiations between the EU and the U.S. following the 2020 decision by the Court of Justice of the European Union ruling that the prior EU-U.S. framework , known as Privacy Shield, did not satisfy EU legal requirements.
The new Trans-Atlantic Data Privacy Framework underscores our shared commitment to privacy, data protection, the rule of law, and our collective security as well as our mutual recognition of the importance of trans-Atlantic data flows to our respective citizens, economies, and societies. Data flows are critical to the trans-Atlantic economic relationship and for all companies large and small across all sectors of the economy. In fact, more data flows between the United States and Europe than anywhere else in the world, enabling the $7.1 trillion U.S.-EU economic relationship.
Como anda a Proteção de Dados Pessoais nos Estados Unidos da América ?
#ProteçãoDeDados #PrivacidadeDeDados #DireitoDigital #GDPR
Eu amo esse vídeo, já vi uma tonelada de vezes ...
Já a segurança é assegurada pelo Comodo Web Filtering, que bloqueia o acesso a sites considerados arriscados ou de conteúdos impróprios. Não é compatível com IPv6.
O AdGuard foi criado com o objetivo de livrar o usuário de anúncios inconvenientes, seja ao navegar na internet ou jogar online. Os criadores prometem ainda proteger seus dados de qualquer rastreador e sistemas de análise de informações.
Se quiser manter a rede livre de conteúdos adultos e forçar a pesquisa segura no navegador, deve optar pelo servidor com modo de Proteção Familiar. Já a opção Sem filtro, não bloqueia anúncios, rastreadores ou qualquer tipo de conteúdo.
1) CleanBrowsing DNS Family Filter = Bloqueia o acesso a sites de conteúdo adulto e explícito, além de proxy e VPNs. Também configura páginas como Google e YouTube no modo de segurança.
2) CleanBrowsing DNS Adult Filter = permite acesso à Sites usando VPN e proxy
3) CleanBrowsing DNS Security Filter = Foca na questão da segurança de uso, sem filtros para conteúdos. Protege contra phishing, spam, malware e URL maliciosos.
O MX Linux é um servidor leve, ele executa os aplicativos que são compatíveis com o Debian Linux. Ele funciona muito bem instalado em um computador velho com pouca memória RAM. Ele por ser um sistema operacional muito leve, o computador não fica muito lento. O MX Linux já vem com diversos aplicativos instalados dentro dele.
Olhe esse vídeo = O que o MX Linux tem de bom ?
MX Linux download = https://mxlinux.org/download-links/
Instalando o MX Linux na configuração padrão:
user = demo e senha = demo
superuser = root e password = root
No MX Linux para desbloquear o modo de instalação dos aplicativos digita:
sudo password root
No MX Linux para atualizar o sistema operacional digita:
sudo apt upgrade
No MX Linux para instalar o que deseja utilizar digita:
sudo apt.get install vscode
sudo apt.get install git
sudo apt.get install html
sudo apt.get install css
sudo apt.get install javascript
sudo apt.get install node
sudo apt.get install react
sudo apt.get install angular
sudo apt.get install python
sudo apt.get install php
sudo apt.get install java
sudo apt.get install bootstrap
sudo apt.get update *.*
E para desinstalar algum aplicativo no MX Linux digita:
sudo apt remove nomedoaplicativo
sudo ppt purge nomedoaplicativo -y
Serviços podem assumir diferentes funções quando envolvidos em diversos cenários de interação. Dependendo do contexto pelo qual é visualizado, assim como o estado da tarefa rodando no momento, o mesmo web service pode trocar de papéis ou ser designado para múltiplos papéis simultâneos:
Agindo como um provedor de serviços, um web service expõe uma interface pública através da qual pode ser chamado por solicitantes do serviço. Um provedor de serviços disponibiliza esta interface publicando uma descrição do serviço. Num modelo cliente-servidor, o provedor de serviço pode ser comparado ao servidor.
O termo “provedor de serviço” pode também ser usado para descrever a organização ou ambiente que hospeda (provê) o web service.
Um provedor de serviço pode também agir como um solicitante de serviço. Por exemplo, um web service pode atuar como um provedor de serviço quando um solicitante de serviço lhe pede para executar uma função. Pode então atuar como um solicitante de serviço quando mais tarde contata o solicitante de serviço original (agora agindo como um provedor de serviço) para solicitar informação de status.
Um solicitante de serviço é o remetente de uma mensagem web service ou o programa de software solicitando um web service específico. O solicitante de serviço é comparável ao cliente dentro de um modelo cliente-servidor padrão. Solicitantes de serviços são às vezes chamados de consumidores de serviços.
Um solicitante de serviço pode também ser um provedor de serviço. Por exemplo, num modelo de solicitação e resposta, o web service iniciador primeiro age como um solicitante de serviço ao requerer informações do provedor de serviço. O mesmo web service então, faz o papel de um provedor de serviço ao responder à solicitação original.
O papel de intermediário é assumido pelo web service quando ele recebe a mensagem de um solicitante de serviço e a passa adiante para o provedor de serviço. Neste caso, ele pode também agir como um provedor de serviço (recebendo a mensagem) e como um solicitante de serviço (passando adiante a mensagem).
Intermediários podem existir em muitas formas diferentes. Alguns são passivos e simplesmente re-transmitem ou roteam as mensagens, enquanto outros processam ativamente uma mensagem antes de repassá-la. Tipicamente, aos intermediários só é permitido o processamento e modificação do cabeçalho da mensagem. Para preservar a integridade da mensagem, seus dados não devem ser alterados.
Como o web service responsável por iniciar a transmissão da mensagem, remetentes iniciais também podem ser considerados solicitantes de serviço. Este termo existe para ajudar a diferenciar o primeiro web service que envia uma mensagem, dos intermediários também qualificados como solicitantes de serviço.
O último Web service a receber uma mensagem é o receptor final. Estes serviços representam o destino final de uma mensagem e também podem ser considerados provedores de serviço.
Quando mensagens são passadas entre dois ou mais web services, uma variedade de cenários de interação pode acontecer. A seguir, termos comuns utilizados para identificar e etiquetar estes cenários serão apresentados.
A rota pela qual a mensagem viaja é o caminho da mensagem. Deve consistir de um remetente inicial e um receptor final e pode conter nenhum, um, ou mais de um intermediários. A Figura 5 ilustra um caminho de mensagem simples.
O caminho de transmissão atual percorrido por uma mensagem pode ser dinamicamente determinado por roteadores intermediários. A lógica de roteamento pode ser ativada em resposta à carga de requisitos de balanceamento, ou pode ser baseada nas características da mensagem e outras variáveis lidas e processadas pelo intermediário em tempo de execução.
A transmissão da mensagem é enviada via um ou dois caminhos possíveis, que é determinado pelo roteador que faz a intermediação da transmissão.
Utilize ferramentas de serviços Web para localizar, criar e publicar serviços Web criados a partir de beans Java™ beans empresariais e ficheiros WSDL. Pode criar serviços Web através de uma abordagem de cima para baixo (que começa com um ficheiro WSDL) ou de uma abordagem de baixo para cima (que começa com um bean Java ou com um EJB).
Nesta edição, o caminho de programação que normalmente seguiria ao criar e publicar um serviço Web é o seguinte:
Para mais instruções sobre a execução destas tarefas, consulte a lista de tópicos relacionados no final deste tópico.
As ferramentas da Web auxiliam o desenvolvimento de aplicações da Web que pode configurar como um serviço Web. As aplicações da Web são desenvolvidas num projecto Web e as ferramentas do Servidor permitem utilizar o ambiente de teste do servidor para testar e implementar os seus serviços Web.
Os serviços Web podem ser criados através de dois métodos: programação de cima para baixo e de baixo para cima. A programação dos serviços Web de cima para baixo implica a criação de um serviço Web a partir de um ficheiro WSDL.
Sempre que cria um serviço Web a partir de uma abordagem de cima para baixo, concebe primeiramente a implementação de um serviço Web através da criação de um ficheiro WSDL. Pode fazer isto utilizando o Editor de WSDL. Posteriormente poderá utilizar o assistente de serviços Web para criar o serviço Web e as classes de estrutura Java™ às quais pode adicionar o código exigido.
Embora a programação de serviços Web de baixo para cima seja mais fácil e rápido, sobretudo se o utilizador não tem experiência na programação de serviços Web, a abordagem de cima para baixo é a via aconselhável para criar um serviço Web. Criar o ficheiro WSDL em primeiro lugar permitir-lhe-á, finalmente, ter um maior controlo sobre o serviço Web e eliminar questões de interoperacionalidade que poderão surgir na criação de um serviço Web através do método de baixo para cima.
Os serviços Web podem ser criados através de dois métodos: programação de cima para baixo e de baixo para cima. A programação dos serviços Web de baixo para cima implica a criação de um serviço Web a partir de um bean Java™ ou bean empresarial.
Embora a programação de serviços Web de baixo para cima seja mais fácil e rápido, sobretudo se o utilizador não tem experiência na programação de serviços Web, a abordagem de cima para baixo é a via aconselhável para criar um serviço Web.
Se pretende criar um serviço Web através de uma abordagem de baixo para cima, deve, antes de mais, criar um bean Java ou um bean EJB e, em seguida, utilizar o assistente dos serviços Web para criar o ficheiro WSDL e o serviço Web.
Fonte: IBM Brasil
Um dos atributos chave dos padrões da Internet é o facto de se poderem concentrar em protocolos e não em implementações. A Internet é constituída por tecnologias heterogéneas que interoperam com êxito através de protocolos partilhados. Este facto evita a imposição de uma norma na Internet por parte dos revendedores individuais. O desenvolvimento de software em código aberto desempenha um papel crucial na preservação da interoperacionalidade das implementações de padrões pelo revendedor.
Os padrões que se seguem desempenham papéis fundamentais nos serviços Web: Descrição, Localização e Integração Universais (UDDI), Linguagem de Descrição de Serviços Web (WSDL- Web Services Description Language), Linguagem de Inspecção de Serviços Web (WSIL- Web Services Inspection Language), SOAP e Interoperacionalidade dos Serviços Web (WS-I). A relação entre estes padrões está descrita na Figura 2.
A especificação UDDI define padrões abertos e independentes de plataformas que permitem às empresas partilhar informações num registo de empresas global, localizar serviços nesse registo e definir o modo como interagem na Internet. Para obter mais informações sobre a UDDI, consulte www.uddi.org
A WSIL é uma especificação aberta baseada em XML que define um método de localização de serviços distribuído o qual fornece referências a descrições de serviços no ponto de oferta do fornecedor de serviços, especificando o modo de procurar serviços Web disponíveis um sítio da Web Relação entre o UDDI e a WSIL. Para obter mais informações sobre a WSIL, consulte www.ibm.com/developerworks/webservices/library/ws-wsilspec.html
A WSDL é uma especificação aberta baseada em XML que descreve as interfaces e instâncias dos serviços Web na rede. É uma especificação extensível, por isso os terminais podem ser descritos independentemente os formatos da mensagem ou dos protocolos de rede utilizados para comunicar. As empresas podem disponibilizar os documentos WSDL para os seus serviços Web através do UDDI, WSIL ou difundindo as URLs para o WSDL via e-mail ou através dos sítios da Web. A WSDL é descrita como um tópico diferente nesta documentação. Para obter mais informações sobre a WSDL, consulte www.w3.org/TR/wsdl
Figura 2. Relações entre SOAP, UDDI, WSIL e WSDL.
Um fornecedor de serviços aloja um serviço Web e torna acessível a utilização de protocolos, tais como SOAP/HTTP ou SOAP/JMS. O serviço Web é descrito por um documento WSDL armazenado no servidor do fornecedor ou num repositório especial. O documento WSDL pode ser referenciado pelo registo de empresa UDDI e os documentos WSIL. Estes contêm indicadores para os ficheiros WSDL dos serviços Web.
O WS-I Simple SOAP Binding Profile e o WS-I Attachments Profile são esquemas de requisitos com os quais a WSDL e o tráfego (SOAP/HTTP) do protocolo dos serviços Web e WSDL deverão estar de acordo de modo a poder declarar conformidade com a WS-I. As ferramentas de validação dos serviços Web WS-I suportam actualmente o SOAP Binding Profile 1.0 e o Attachment Profile 1.0. Para ver as especificações, consulte o sítio da Web da WS-I, e em Recursos seleccione Documentação: http://www.ws-i.org
As ferramentas dos serviços Web suportam as seguintes especificações:
Tecnologia ou especificação | Versão ou nível suportado |
---|---|
Transportes | |
HTTP/HTTPS | v1.0 e v1.1 |
JMS | |
Serviços de Mensagens | |
Especificação SOAP | v1.1 |
Anexos SOAP | |
Descrição | |
UDDI | v2.0 |
WSDL | v1.1 |
WSIL | v1.0 |
Segurança | |
WS-Security | OASIS Standard 1.0 |
Interoperacionalidade | |
WS-I Basic Profile | 1.1.2 |
WS-I Simple SOAP Binding Profile | 1.0.3 |
WS-I Attachments Profile | 1.0 |
Outros Padrões | |
JAX-RPC | v1.0 para J2EE 1.3, v1.1 para J2EE 1.4 e Java EE 1.5 |
JSR 109 |