Docker – parte 2

Execute:

sudo docker run -t -i -p 8080:80 wsgi-stack bin/bash

#iniciando nginx
/etc/init.d/nginx start

verifique a execução com: ps -ef

Saia do container utiliando ctrl + p + q para que ele continue em execução. Agora, fora do container, execute um comando em um container com:

sudo docker exec id_do_container ps -ef

abra o navegador e veja que nginx esta rodando localhost:8080

Para voltar ao seu container pode rodar:

sudo docker attach id_do_container

Saia do container e vamos criar um segundo container com nginx rodando em outra porta.

sudo docker -i -t -p 6660:80 wsgi-stack bin/bash
#iniciando nginx
/etc/init.d/nginx start

Saia do container comctrl + p + q e verifique no seu navegador na porta 6660 se aparece nginx.

obs: Crtl + d, mata o container.

 

Docker – parte 1

Instalando Docker

 sudo apt-get install docker.io

obs: Para utilizar o Docker é necessário acesso de root. Pode configurar para não precisar digitar sudo sempre.

verifique se esta tudo ok:

sudo docker version

Vamos criar um container com Unbutu. As imagens dos containers do docker são armazenadas no Docker Hub e podem ser baixadas através do comando docker pull (veremos mais sobre o docker hub). Para baixar a imagem do ubuntu, basta executar o comando a seguir.

sudo docker pull ubuntu:14.04

teste se esta tudo ok:

sudo docker run ubuntu:14.04 cat /etc/lsb-release

Para que as alterações sejam efetivadas é necessário realizar um commit dessas alterações Para iniciar o bash do container, execute o comando:

sudo docker run -t -i ubuntu:14.04 /bin/bash

obs: verifique o terminal indica visualmente o container pelo id.

Começaremos pelos aplicativos que são instalados através do apt-get (python, pip e nginx).

apt-get update
apt-get install -y python python-pip nginx

Com o python e o pip instalado, agora podemos instalar o virtualenv, o gunicorn e o supervisor.

pip install virtualenv supervisor gunicorn

asas

Com o comando exit, vamos sair do container e com o comando sudo docker ps -l vamos verificar o id do ultimo container que utilizamos. Para que essa alterações sejam efetivadas em nosso container (gerando assim uma nova imagem), devemos executar commit. O comando docker commit possui a seguinte sintaxe.

docker commit OPÇÕES CONTAINER REPOSITORIO

#em nosso caso:
docker commit id_do_container wsgi-stack

Teste ativando novamente o container:

docker run -t -i wsgi-stack
python --version

Ou seja, tudo que foi instalado esta presente.

Referências: 

1- http://www.diego-garcia.info/2015/02/15/docker-por-onde-comecar/

2- https://www.youtube.com/watch?v=0cDj7citEjE

3- … muito na web sobre o assunto.

Cocoapods and Swift

O Cocoapods é uma plataforma de gestão de depêndencias para projetos feitos em Cocoa e Cocoa Touch (basicamente OSX e iOS), equivalente ao NuGet para a Microsoft/Visual Studio e o Maven no Android. Criada e mantida pela comunidade, ela tornou-se tão fundamental e importante que dedicamos um módulo exclusivamente a ela em nosso treinamento Introdutório de iOS+Swfit.

Quando a Apple introduziu a linguagem Swift em junho de 2014, ela apresentou uma oportunidade única para os desenvolvedores de componentes, ao trazer recursos de linguagem que permitiam produzir bibliotecas de uso mais simples e conveniente, como o CoreDataContext que eu criei para trabalhar com o Core Data e que com o uso de Generics tornou o manuseio das entidades de dados muito mais simples, ou o AlamoFire, um componente para comunicação Web feito pelos mesmos criadores do AFNetworking, porém totalmente pensando na perspectiva da linguagem Swift.

Um mundo novo de possibilidades se abria, porém como todo novo recurso que surge, ele enfrenta algumas dificuldades em lidar com o legado. Componentes que tivessem código Swift não eram suportados até pouco tempo atrás pelo Cocoapods, e mesmo a inclusão desse suporte tem suas limitações. Nesse artigo vamos entender um pouco melhor sobre isso.

Apresentando o App Countries

Nesse artigo vamos usar como base o App Countries, criado pela Ravero para exemplificar a comunicação com Web Services em iOS, ele apresenta uma listagem dos países do mundo obtidas através de um Web Service público.

 

O código do App esta disponível neste repositório do GitHub. O App utiliza 3 bibliotecas:

• MBProgressHUD: componente muito popular para apresentar um indicador de status e inibir o input do usuário.
• SBWebImage: componente para carregar um UIImageView com uma imagem baixada pela Internet de maneira assíncrona, ou seja, sem congelar o App.
• SwiftyJSON: um parser de JSON criado totalmente em Swift e tirando proveito de todos os recursos da linguagem.

No projeto original os 2 primeiros componentes são integrados usando o CocoaPods, enquanto o terceiro é inserido manualmente.

O problema

Para entender as limitações que o Cocoapods tem com o Swift, é necessário compreender um pouco da sua arquitetura. Quando incluímos um componente (ou Pod) em nosso projeto, o Cocoapods baixa o código desse componente e de todas as suas dependências. Esses códigos são agrupados em um projeto separado, que é compilado em uma Static Library e depois incorporado ao projeto.

No App de exemplo temos os Pods dos dois componentes citados anteriormente, e abrindo o Project Navigator podemos verificar o projeto específico para eles e sua estrutura:

Abra o as configurações do projeto e selecione o Target do App. Na aba General no final da página podemos verificar uma seção chamada Linked Frameworks and Libraries. Lá nós podemos incluir bibliotecas para serem utilizadas pelo App. Note a existência de um arquivo com o nome libPods-Countries.a. Essa é a Static Library que o CocoaPods gera automaticamente e que contém todos os componentes que incluímos no Podfile.

Dessa maneira o CocoaPods consegue incluir os códigos dos componentes sem bagunçar com o seu projeto. Esse mecanismo é muito eficiente não fosse um pequeno detalhe: Códigos em Swift não podem ser compilados em Static Libraries. Entram os Frameworks…

Static Libraries vs. Cocoa Touch Frameworks

Vamos entender um pouco sobre o que são e quais as diferenças entre esses recursos disponíveis no SDK da Apple:

Static Libraries ou bibliotecas estáticas, é um dos mecanismos mais antigos de re-aproveitando de código, datando da década de 70 quando a linguagem C era uma das mais populares. Quando você usa uma biblioteca estática em seu projeto, o que o compilador faz é incorpoar seu código binário no próprio binário do App. Isso faz com que o código do seu App fique maior, e tende a ter um maior tempo de carga e utilziação de memória. Sua principal restrição é não suportar que códigos escritos em Swift sejam compilados nesse formato.

Cocoa Touch Frameworks são bibliotecas dinâmicas (ou DLL’s: Dynamic Link Libaries). Diferente da anterior, o código de um Framework é carregado dinamicamente durante a execução de um programa e somente quando necessário. Apesar de existirem no Mac a muito tempo só foram introduzidos ao iOS a partir da versão 8, e são fundamentais para suportar recursos como as Extensões, e deve ser usado sempre que possível no lugar das Static Libraries a partir de agora, já que são mais modernos e eficientes. Sua principal restrição é não ser suportada em versões anteriores do iOS.

A Solução

Com base no problema, a solução mais simples que o pessoal do CocoaPods chegou foi, usar Frameworks no lugar de Static Libraries. Vamos ver como isso funciona na prática. No nosso projeto exemplo vamos substituir a inclusão manual que fizemos do componente SwiftyJSON pela integração via CocoaPods.

Se desejar refazer os passos desse exemplo, baixe o repositório e de um Checkout na Tag pre-cocoapods.

Esse componente encontra-se no grupo do projeto Libs. Exclua esse grupo do projeto. Ao tentar compilar novamente o Xcode apresentará um erro, já que não encontra mais a classe da biblioteca.

O suporte para Pods com código em Swift esta disponível no Cocoapods a partir da versão 0.36. Para manter o Cocoapods atualizado com a versão mais recente utilize o comando sudo gem install cocoapods.

Vamos atualizar o Podfile do projeto para incluir o SwiftyJSON:

# Uncomment this line to define a global platform for your project
# platform :ios, ‘8.0’

target 'Countries' do
    pod 'MBProgressHUD', '~> 0.8'
    pod 'SDWebImage', '~> 3.7'
    pod 'SwiftyJSON', '~> 2.1'
end

E execute o comando pod install para atualizar os componentes. Veja que recebemos o seguinte erro:

Analyzing dependencies
Downloading dependencies
Using MBProgressHUD (0.9)
Using SDWebImage (3.7.1)
Installing SwiftyJSON (2.1.3)
[!] Pods written in Swift can only be integrated as frameworks; this feature is still in beta. Add `use_frameworks!` to your Podfile or target to opt into using it.

Apesar do CocoaPods ter incluído o suporte a bibliotecas Swift, é necessário declararmos explicitamente o uso de Frameworks para inclui-las no target. Isso acontece porque os Cocoa Touch Frameworks só estão disponíveis a partir do iOS 8, dessa forma a inclusão de qualquer biblioteca que dependa desse recurso faz com que o projeto automaticamente se torne incompatível com o iOS 7.

Vamos atualizar o Podfile conforme as instruções para entender o que acontece:

# Uncomment this line to define a global platform for your project
platform :ios, '8.0'
use_frameworks!

target 'Countries' do
    pod 'MBProgressHUD', '~> 0.8'
    pod 'SDWebImage', '~> 3.7'
    pod 'SwiftyJSON', '~> 2.1'
end

Executando novamente o comando pod install a instalação acontece normalmente. Note também que eu inclui a instruçãoplatform que estava comentado anteriormente, isso não é obrigatório mas recomendável. Abra o projeto e tente compilar o código.

Abra o projeto e verifique no Project Navigator como o SwiftyJSON foi incluido no projeto dos Pods.

Abra as propriedades do projeto, e verifique que no lugar da referência para libPods-Countries.a temos agoraPods_Countries.framework.

A referência foi substituída! Mas se tentarmos compilar o projeto continuamos com o mesmo erro. O que aconteceu? Quando usamos o Objective-C, antes de usar as bibliotecas era necessário importar o cabeçalho delas. Por conta dessa mecânica o Cocoapods inclua os cabeçalhos de todos os Pods do projeto para usarmos conforme a necessidade. Em Swift não existem arquivos de cabeçalho, mas então como usamos uma classe declarada em uma biblioteca?

Em Swift seu código em compilado em binários, chamados de módulos, que contém metadados descrevendo suas classes e funções públicas. De maneira semelhante aos cabeçalhos do Objective-C, é necessário usar o comando import para incluir um módulo em seu código fonte.

Uma coisa muito conveniente que o CocoaPods faz quando declaramos no Podfile o uso de Frameworks é, compilar cada componente em seu próprio módulo. Ué, mas na seção Linked Frameworks and Libraries? Trata-se apenas de umplaceholder. O segredo esta escondido nas configurações do projeto. Abra a aba Build Phases e verifique que foi criado uma fase chamada Copy Pods Resources, que executa um Shell Script:

Se tiver curiosidade pode abrir esse Script, ele é um pouco extenso mas o que ele faz em resumo é copiar cada um dos Frameworks gerados no projeto Pods. Abra as propriedades desse projeto, e verifique que além do Target placeholder há mais 1 target para cada pod instalado. Note como esses targets são do tipo Framework (é fácil visualizar pelo ícone amarelo).

Vamos finalmente atualizar o código do projeto para eliminar os erros. Abra o arquivo CountryList.swift e inclua no cabeçalho a seguinte declaração:

import SwiftyJSON

Isso resolve o error anterior, mas agora temos um novo erro.

O compilador esta reclamando não encontrar a classe MBProgressHUD. Ela faz parte do componente homônimo. Anteriormente ela ficava disponível em nosso código através do Bridging-Header, mas agora que ele esta incorporado ao projeto como um Framework, esse cabeçalho já não serve mais para encontrar a referência a classe contida no módulo. A correção é feita da mesma forma, no arquivo CountriesViewController.swift inclua a declaração no cabeçalho:

import MBProgressHUD

E por fim atualize o arquivo CountryDetailsViewController.swift. Ele faz uso do componente SDWebImage, então vamos importa-lo no cabeçalho:

import SDWebImage

Agora não precisamos mais do arquivo Bridging-Header, fique a vontade para excluí-lo se desejar. Compile e execute o App, e agora tudo deverá funcionar normalmente!

Atenção: Em alguns casos identifique ser necessário dar um clean ou até mesmo excluir a pasta DerivedData para que a compilação ocorresse normalmente após a inclusão de um Pod Swift.

Conclusão

Com o Cocoapods a partir da versão 0.36 é possível incluir Pods com código Swift em nossos projetos. Isso fará com que esses componentes sejam incorporados ao projeto com Frameworks ao invés de Static Libraries, entretanto perdemos o suporte para o iOS 7.* (lembrando que o próprio Swift não é suportado em versões do iOS anteriores a 7).

Dessa forma é importante verificar se os componentes que você vai utilizar contém códigos em Swift, e nesse caso você precisa avaliar a necessidade de suporte retroativo em seu projeto. Se não for necessário suportar o iOS 7, use esses componentes tranquilamente, do contrário será necessário incluir manualmente as bibliotecas em seu projeto.

fonte: http://ravero.net/2015/03/23/cocoapods-swift-s3/

Gerenciador de Pacotes OSX (Brew)

1- Abra o terminal e verifique se esta instalado o Command Line Tools for Xcode:

xcode-select -p

Se não estiver instalado então execute: xcode-select –install

2- Se já estiver instalado:

ruby -e “$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)”

3-Depois disso, faça o download e a instalação do XQuartz, pois o brew irá precisar dele uma vez que já não vem instalado como parte integrante da versão 10.9 do OS X e do Xcode.

Depois de instalada e tal como sugerido no Terminal, antes mesmo de instalar qualquer coisa, devemos verificar se está tudo bem rodando o seguinte comando:

brew doctor

Comando para procurar por uma aplicação:

brew search

Comando para instalar uma aplicação:

brew install <NOME_DA_APLICAÇÃO>

Comando para listar todas aplicações instaladas pelo Homebrew:

brew list

Remover uma aplicação instalada:

brew remove <NOME_DA_APLICAÇÃO>

Para actualizar o Homebrew:

brew update

Para saber mais sobre o Homebrew, basta consultar o manual:

man brew

ou visitar a Wiki online:

https://github.com/Homebrew/homebrew/wiki

NOTA: Homebrew instala as aplicações no seu próprio directório (/usr/local/Cellar) e cria symlinks em “/usr/local”.

Em caso de problemas com versão:

–

cd /usr/local/Library
git pull origin master
mais ajuda em:
http://apple.stackexchange.com/questions/153790/how-to-fix-brew-after-its-upgrade-to-yosemite

Mac e Pil / Pillow

Problema chato, com instalação de pillow, resolvido com:

sudo sed -i ''-e 's/-mno-fused-madd//g'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_sysconfigdata.py

sudo rm /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/_sysconfigdata.pyc

pip install pillow

Virtualenv e Django

Várias versões de Python, Django, Oauth e etc. Acaba em bagunça. Então vamos criar uma pasta, quer dizer uma virtualização, para organizar as coisas:

python esay_install pip

Agora

pip install virtualenv

Com a ferramenta em mãos, vamos criar nossa pasta:

virtualenv nome_da_pasta_configurada

source bin/activate

As coisas mudaram no terminal ! Agora vamos instalar django

pip install  django==1.6.5

E criando projeto

django-admin.py startproject seu_projeto

Para obter essa lista, basta utilizar o comando freeze do pip:

pip freeze
#ou para exportar</pre>
<pre style="color: #444444;"><code>pip freeze > requirements.txt</code></pre>
<pre>#ou para importar</pre>
<pre style="color: #444444;"><code>pip install -r requirements.txt</code></pre>
<pre>

 

Gerando chaves SSH no Mac OS X

Para gerar um par(publica e privada) de chaves SSH no Mac OS X abra o Terminal e execute os seguintes comandos:

1 2	$ cd ~/ $ ssh-keygen -t rsa

Você pode informar o local onde será salva e o nome da chave, ou simplesmente aceitar o padrão“/Users/seu_usuario/.ssh/id_rsa”. Será solicitado uma senha para chave que também é opcional, porém, recomendo que você informe uma. Após confirmar a senha sua chave será gerada e salva no caminho padrão ou onde você informou.
Utilizando a chave SSH
Ao utilizar sua chave SSH, recomendo copiá-la para a área de transferência utilizando o comando:

1	$ cat ~/.ssh/id_rsa.pub | pbcopy

Feito isso é só colar a chave SSH no sistema em que pretende utilizá-la.

Uma dúvida Comum que percebo é entre a a diferença entre trabalhar utilizando Http e SSH, e outra a chave de implantação e a chave do usuario.

— “Repository access denied. acess via a deployment key is read-only.

 

Serviços Web Semântico (parte 3 – Buscando Serviços)

Quando trabalhamos com serviços webs, normalmente o primeiro passo é a busca, para saber se já existe um serviço semelhante ao que queremos, ou como anda o serviço, ou como conectar um serviço. Enfim o primeiro passo é encontrar serviço baseado em algum filtro de interesse.

Encontrar um serviço Web que atenda às necessidades do cliente não é uma tarefa fácil.
Um repositório pode possuir muitos serviços o que torna impossível que essa atividade seja
feita manualmente. Por conta disso, existem ferramentas que fazem o processo de descoberta de forma automática.
Dado um repositório de serviços Web e uma requisição de consulta a serviço, encontrar
um serviço automaticamente no repositório que atenda aos requisitos da consulta é o problema da descoberta de serviços. Soluções válidas para o problema, devem satisfazer as seguintes condições (KONA; BANSAL; GUPTA, 2007):

•  produzir pelo menos os parâmetros de saída do serviço requisitado e satisfazer suas póscondições;
•  usar somente os parâmetros de entrada informados e satisfazer as pré-condições do serviço requisitado;
•  produzir os mesmos efeitos que o serviço requisitado

Para realizar a descoberta, é necessário representar a consulta com uma linguagem específica, onde devem ser informados os parâmetros de entrada e saída do serviço requerido. Para processar todos esses dados e realizar a descoberta, utiliza-se um algoritmo de correspondência também chamado algoritmo de matching. Este algoritmo faz a análise da requisição do usuário e compara com todos os serviços existentes no repositório, caso encontre um ou mais serviços compatíveis informa ao usuário.

Caso não seja possível encontrar um serviço compatível, alguns algoritmos oferecem a op-
ção da composição de serviços. Neste caso, os parâmetros de entrada e saída são combinados de forma que se obtenha uma composição de serviços que satisfaça as condições citadas anteriormente.

As informações semânticas são essenciais para os algoritmos de matching, pois diminui o
problema dos falsos positivos. Falsos positivos ocorrem quando dois parâmetros são considerados sintaticamente similares, mas na verdade são semanticamente diferentes. Isso faz com que os algoritmos que utilizam abordagem semântica sejam mais eficazes.
Alguns serviços podem não atender a todos os requisitos, mas são considerados aceitáveis
visto que atendem às necessidades do usuário. Por exemplo, um serviço pode não utilizar todos os parâmetros de entrada fornecidos pelo usuário, porém os parâmetros de saída devem ser iguais. Estes serviços são considerados parcialmente similares. Para resolver tal problema, existe um conceito chamado de grau de correspondência (ou Degree of Match – DoM) . O DoM é um número que é calculado utilizando-se algumas métricas e representa o grau de similaridade entre os serviços.

Uma ferramenta para se trabalhar com composição de elementos é o OWL-S Composer, um plugin desenvolvido para compor serviços Web semânticos através da plataforma Eclipse. Este plugin tem como principais características a utilização de um ambiente visual para gerar composições de serviços, a integração com outros plugins do Eclipse, como o WTP (Web Tool Plugin) (WTP, 2009) , minimizando a curva de aprendizagem e a facilidade de manipular as composições além de gerar o código da composição de uma maneira sintática e semanticamente correta (FONSECA; CLARO; LOPES, 2009).

Por ser um plugin do Eclipse, o OWL-S Composer tem todo o suporte necessário de um
ambiente de desenvolvimento integrado para desenvolvimento e manipulação de serviços Web. Isto facilita o trabalho do desenvolvedor, que não vai precisar utilizar várias ferramentas ao mesmo tempo. O OWL-S Composer possui um editor de diagramas onde é possível modelar graficamente a composição dos serviços previamente escolhidos pelo usuário. O OWL-S Composer possui suporte a apenas três estruturas de controle, que são: Sequence, Split e Any-Order

No próximo artigo iremos abordar um exemplo.

Serviços Web Semântico (parte 2 – OWL-S)

O modelo que utilizaremos para trabalhar com Serviços Web Semânticos esta fundamentado sobre o OWL-S. Então uma brevíssima descrição.

As descrições de serviços Web em WSDL não possuem informações semânticas. Estas informações são importantes para a descoberta, invocação e composição automática de serviços.  A linguagem OWL-S (Ontology Web Language for Service) (MARTIN et al., 2004) é uma linguagem para descrição semântica de serviços Web. A OWL-S é baseada na OWL (Web Ontology Language), uma linguagem para descrição de ontologias.
Para representar as informações dos serviços, a OWL-S possui uma ontologia principal que
descreve outras três ontologias. A figura 2 mostra como são organizadas essas ontologias.

Service é o ponto central da representação de um serviço Web. Todo serviço Web possui
uma instância de Service. Esta ontologia é descrita através das propriedades presents, describedBy e supports que indicam as tres sub-ontologias ServiceProfiles, ServiceModel e ServiceGrouding.

Um serviço pode ser classificado como atômico, simples ou composto. O
serviço atômico é um único serviço que pode ser invocado diretamente através do seu endereço. O serviço simples não pode ser invocado, ele apenas descreve uma forma de utilização do serviço atômico. O serviço composto é formado por vários serviços atômicos, sendo que a ordem de execução dos serviços é definida por controladores de fluxo (MARTIN et al., 2004). A OWL-S possui suporte para os seguintes controladores de fluxo: Sequence, If-Then-Else, AnyOrder, Split, SplitJoin, Choose e Repeat-Until.

Serviços Web Semântico (parte 1 – Introdução)

Vou fazer uma pequena introdução aos Serviços Web, para posteriormente indicar a necessidade de semântica nesta arquitetura. Buscarei principalmente comentar sobre criação, busca e composição de serviços, desta natureza.

A Internet começou suportando interações com dados textuais e gráficos. As pessoas utilizam a Internet diariamente para ver cotações, fazer compras, e ler notícias. Este nível de interação atende a muitas das necessidades atuais. Mas a Web baseada em texto não suporta comunicação entre softwares da melhor maneira, principalmente transferência de grande volume de dados. Os serviços Web surgiram para desenvolver esta funcionalidade.
Os serviços Web estão mudando a maneira como as aplicações interagem na Web. Eles
conectam programas que estão em pontos distantes do mundo, de forma mais eficiente e com menor custo. O resultado é uma melhor e mais produtiva comunicação entre empresas e clientes (NEWCOMER, 2002).
Um serviço Web é uma aplicação que pode ser acessada remotamente usando diferentes
linguagens baseadas em XML. Normalmente, um serviço Web é identificado por uma URI,
assim como qualquer outro site Web (POTTS; KOPACK, 2003). O uso do XML é uma das grandes vantagens dos serviços Web, pois os tornam independentes de linguagem, plataforma ou sistema operacional.
A arquitetura SOA (Service Oriented Architecture) propõe uma estrutura para a criação e
utilização dos serviços Web. Primeiramente é preciso que alguém ofereça o serviço, este é o papel do provedor de serviço. Então ele publica este serviço em um repositório, tornando-o disponível para que possa ser localizado. Um cliente realiza uma busca por um determinado serviço. Ao encontrar este serviço, o cliente tem acesso às informações de como utilizar o serviço. Essas informações incluem o endereço do provedor, através do qual o
cliente pode fazer uma chamada direta ao provedor do serviço.

A arquitetura SOA utiliza tecnologias essenciais ao seu funcionamento. Padrões de representação das informações foram definidos para permitir a comunicação entre o cliente, repositório e provedor do serviço Web. Estes padrões serão apresentados a seguir:

•    SOAP (Simple Object Access Protocol) é o protocolo de comunicação usado para troca de mensagens entre o cliente e o provedor do serviço. O SOAP define um formato de mensagem, baseado em XML, para troca de dados através da Internet. É um formato simples, fácil de desenvolver e independente de plataforma, linguagem de programação ou sistema operacional (NEWCOMER, 2002). O SOAP utiliza o HTTP como protocolo de transporte, o que torna possível atravessar firewalls.
•  O WSDL (Web Services Description Language) é uma linguagem de descrição de serviços Web. Esta linguagem permite que sejam representadas suas funcionalidades, assim como, parâmetros de entrada e saída, métodos e também o endereço onde se localiza o serviço.
•  A publicação dos serviços utiliza o repositório UDDI (Universal Description, Discovery, and Integration) . No repositório UDDI são concentrados os serviços Web e é possível

A Web semântica pode ser aplicada em vários contextos, inclusive os serviços Web. O uso
da Web semântica incorporada aos serviços Web tornou mais fácil a manipulação desses serviços, principalmente para a automatização das buscas. Com o uso da semântica para descrever serviços Web, a busca automática por um determinado serviço tornou-se mais eficaz. Isso é possível por causa da facilidade que a semântica oferece em realizar inferência e associações sobre um determinado conceito.
Um serviço Web semântico utiliza um documento de descrição semântica, além do WSDL,
para descrever suas funcionalidades. É necessário uma linguagem específica, que possibilite
representar as ontologias do serviço. Dentre as linguagens criadas, pode-se citar: OWL-S (Ontology Web Language for Service) (MARTIN et al., 2004) , WSMO (Web Service Modeling Ontology) (LAUSEN; POLLERES; ROMAN, 2005) e o SAWSDL (Semantic Annotations for WSDL) (KOPECKY et al., 2007) .

A OWL-S utiliza um formalismo para representar o conhecimento de uma ontologia, que é a linguagem OWL (Web Ontology Language) (BECHHOFER et al., 2004) . Na OWL-S são definidas três ontologias: no Profile são descritas as funcionalidades do serviço, é usada para identificar um serviço pelas ferramentas de busca; no Model é descrito o comportamento do serviço e como este deve ser invocado; no Grounding é descrita a localização do WSDL e a forma de acesso ao serviço, como exemplo o protocolo de comunicação e o formato das mensagens.

Os serviços, quando isolados, podem não atender aos requisitos do cliente, neste caso,
torna-se necessário combinar determinados serviços a fim de que o objetivo seja alcançado.
Esta combinação denomina-se composição de serviços, que pode também utilizar características semânticas (CLARO; MACêDO, 2008).

Assim como um serviço simples, uma composição de serviços Web tem parâmetros de
entrada, parâmetros de saída, pré-condições e efeitos. Uma composição segue as mesmas características da arquitetura SOA Para um cliente, é indiferente se o serviço que ele vai executar é simples ou composto, o que importa é que o serviço tenha a resposta desejada.

Em uma composição de serviços Web, o parâmetro de saída de um serviço pode ser o
parâmetro de entrada de outro, de forma que vários dados são manipulados por diversos serviços até que seja possível chegar ao resultado desejado. A ordem em que os serviços são executados é definida pela composição, pode ser em sequência, em paralelo, depender de uma condição, são várias as possibilidades. Existem diversas linguagens que suportam a composição de serviços, entre elas está a OWL-S.

No próximo artigo falaremos mais sobre o OWL-S, mantendo o foco inicial da série.