{"id":3541,"date":"2022-06-30T14:59:17","date_gmt":"2022-06-30T17:59:17","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=3541"},"modified":"2024-01-12T18:16:15","modified_gmt":"2024-01-12T21:16:15","slug":"fundamentos-para-arquiteturas-baseadas-em-servicos","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-baseadas-em-servicos\/","title":{"rendered":"Cap 3.3 Fundamentos para arquiteturas baseadas em servi\u00e7os"},"content":{"rendered":"

— Este cap\u00edtulo ainda carece de edi\u00e7\u00e3o e conex\u00e3o apropriada entre os t\u00f3picos. Aprecie com modera\u00e7\u00e3o.<\/span><\/strong><\/p>\nUm dos grandes desafios da arquitetura de software \u00e9 decompor sistemas em unidades modulares pequenas, com conjuntos bem delimitados de responsabilidades.<\/strong> Service-oriented computing<\/em> representa uma estrat\u00e9gia para supera\u00e7\u00e3o desse desafio.\n

\n

De forma ampla, abordagens\u00a0service-oriented <\/em>implicam em “perceber” sistemas complexos como conjunto de servi\u00e7os<\/span>, cada um deles atendendo um conjunto bem claro de atividades de neg\u00f3cio ou demandas t\u00e9cnicas, sempre orientadas a um determinado\u00a0outcome<\/em>.<\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Um servi\u00e7o implementa uma cole\u00e7\u00e3o de capabilities.<\/em><\/p>\n

\r\n

Thomas Erl<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Todo servi\u00e7o deve ser, dentro do poss\u00edvel, <\/strong>self-contained<\/strong> –\u00a0<\/em>ou seja, com condi\u00e7\u00f5es de cumprir suas atribui\u00e7\u00f5es de maneira independente – sem depender de outros. Al\u00e9m disso, devem operar em\u00a0black-box<\/em>, tornando detalhes de implementa\u00e7\u00e3o e funcionamento irrelevantes para eventuais consumidores.<\/p>\n

Eventualmente, servi\u00e7os podem “combinar” funcionalidades de outros servi\u00e7os<\/strong> de forma a atender plenamente objetivos de neg\u00f3cio, respeitando restri\u00e7\u00f5es e atributos de qualidade.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Muitas das ideias indicadas para SOA s\u00e3o plenamente aplic\u00e1veis com microsservi\u00e7os. As principais distin\u00e7\u00f5es est\u00e3o na forma como a comunica\u00e7\u00e3o \u00e9 implementada (em SOA, tradicionalmente, recorre-se a um barramento para orquestra\u00e7\u00e3o) e na granularidade (cada microsservi\u00e7o, idealmente, realiza uma\u00a0capability).<\/em><\/p>\n

<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Organiza\u00e7\u00f5es com seus sistemas organizados a partir de arquiteturas service-oriented<\/em>, mant\u00e9m r\u00edgidos processos de governan\u00e7a, partindo de um invent\u00e1rio.<\/strong><\/p>\n

Elementos fundamentais em SOA<\/h2>\n

Ao projetar sistemas com SOA, cabe ao arquiteto considerar, em primeiro n\u00edvel, segregar componentes de software em quatro categorias.<\/p>\n

    \n
  1. Frontend<\/em><\/strong> – contendo tanto as interfaces com usu\u00e1rios quanto APIs externas;<\/li>\n
  2. Services Repository<\/em><\/strong> ou Invent\u00e1rio – contendo uma rela\u00e7\u00e3o organizada e estrutura dos servi\u00e7os, bem como seus contratos e interfaces;<\/li>\n
  3. Service Bus<\/strong>\u00a0<\/em>– como principal elemento de comunica\u00e7\u00e3o e orquestra\u00e7\u00e3o<\/li>\n
  4. Services<\/em><\/strong>, podendo ser implementa\u00e7\u00f5es finais ou composi\u00e7\u00f5es de servi\u00e7os.<\/li>\n<\/ol>\n
    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\" Em n\u00edvel mais alto, arquiteturas service-oriented<\/em> s\u00e3o tecnicamente particionadas.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nInteressante observar que SOA abre espa\u00e7o para forma\u00e7\u00e3o de, pelo menos, quatro frentes de trabalho dentro das organiza\u00e7\u00f5es.<\/strong> N\u00e3o \u00e9 raro, por exemplo, a forma\u00e7\u00e3o de squads\u00a0<\/em>inteiros voltados ao relacionamento com usu\u00e1rios internos e externos, atrav\u00e9s dos frontends <\/em>e servi\u00e7os de “experi\u00eancia”. Tamb\u00e9m n\u00e3o \u00e9 raro o estabelecimento de times inteiros arquitetando e implementando “integra\u00e7\u00f5es” (integration architects <\/em>operando barramento e o invent\u00e1rio).\n
    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\" Em empresas maiores, \u00e9 comum implementar governan\u00e7a a partir do invent\u00e1rio de servi\u00e7os.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    Para cada servi\u00e7o, por sua vez, \u00e9 importante ponderar sobre:<\/p>\n

      \n
    1. contract<\/strong> –\u00a0<\/em>estabelecendo como um servi\u00e7o pode ser consumido, com detalhes t\u00e9cnicos e indica\u00e7\u00e3o de restri\u00e7\u00f5es e requisitos, geralmente descritos em conjuntos de documentos como (WSDL, XSD e WS-Policy<\/em>)<\/li>\n
    2. implementation<\/strong> –\u00a0<\/em>contendo o c\u00f3digo, propriamente dito, do servi\u00e7o.<\/li>\n
    3. interface <\/em><\/strong>– realizando elementos especificados em contrato.<\/li>\n<\/ol>\n
      \n

      \u00c9 na implementa\u00e7\u00e3o dos servi\u00e7os que reside a l\u00f3gica de neg\u00f3cio<\/strong> e a persist\u00eancia<\/strong>.<\/p>\n

      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\" Idealmente, o projeto de servi\u00e7o deve ser particionado por crit\u00e9rios do dom\u00ednio.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

      Alguns princ\u00edpios arquiteturais\u00a0para SOA<\/h2>\n
      \r\n

      Defini\u00e7\u00e3o: Princ\u00edpio arquitetural<\/p>\r\n

      <\/p>\n

      Um princ\u00edpio arquitetural \u00e9 uma pr\u00e1tica generalizada e aceita. Trata-se n\u00e3o somente de recomenda\u00e7\u00f5es adotadas por outros, mas amplamente defendidas.<\/p>\n

      Princ\u00edpios s\u00e3o guidelines <\/em>contendo recomenda\u00e7\u00f5es que direcionam para a elabora\u00e7\u00e3o de solu\u00e7\u00f5es com determinados objetivos explicitamente definidos.<\/p>\n

      <\/p>\r\n<\/div>\n

      Thomas Erl<\/a>, uma das grandes refer\u00eancias em projetos de arquiteturas baseadas em servi\u00e7os (SOA), ensina que h\u00e1 oito princ\u00edpios fundamentais a observar sempre que estivermos projetando sistemas nesse estilo.<\/p>\n

        \n
      1. O design<\/em> deve ser orientado a contratos coerentemente padronizados<\/strong>, ou seja, todos os servi\u00e7os dentro de um mesmo invent\u00e1rio devem estar em conformidade com um mesmo conjunto de padr\u00f5es de projeto. Os contratos dos servi\u00e7os devem ser sempre fornecidos com seu respectivo servi\u00e7o, compreendendo especifica\u00e7\u00e3o t\u00e9cnica e\/ou documentos descritivos formais. Essa padroniza\u00e7\u00e3o pode ser desafiadora para ambientes com muitos servi\u00e7os, ao longo do tempo.<\/li>\n
      2. Servi\u00e7os devem ter baixo acoplamento entre eles<\/strong>, atrav\u00e9s de contratos, que n\u00e3o revelem nem dependam de aspectos internos de implementa\u00e7\u00e3o, como tecnologias adotadas e padr\u00f5es de armazenamento.<\/li>\n
      3. Qualquer informa\u00e7\u00e3o n\u00e3o essencial de um servi\u00e7o deve ser abstra\u00edda<\/strong>, atrav\u00e9s de uma classifica\u00e7\u00e3o criteriosa de propriedades expostas;<\/li>\n
      4. Servi\u00e7os devem ser projetados para reuso<\/strong>, ou seja, de forma a atender diferentes contextos de utiliza\u00e7\u00e3o, n\u00e3o relacionados intimamente a processos ou atividades espec\u00edficas;<\/li>\n
      5. Servi\u00e7os devem ser\u00a0<\/strong>aut\u00f4nomos<\/b>, ou seja, devem ter influ\u00eancia principal dos ambientes de execu\u00e7\u00e3o onde operam;<\/li>\n
      6. Servi\u00e7os devem minimizar gest\u00e3o de estado<\/strong>, reduzindo a demenda de gest\u00e3o por recursos de persist\u00eancia, transferindo a gest\u00e3o do estado para aplica\u00e7\u00f5es clientes sempre que aplic\u00e1vel.<\/li>\n
      7. Servi\u00e7os devem ser “descobr\u00edveis”, <\/strong>expostos atrav\u00e9s de um registro central (invent\u00e1rio)<\/li>\n
      8. Servi\u00e7os devem ser compon\u00edveis,\u00a0<\/strong>por exemplo, pela ado\u00e7\u00e3o da estrat\u00e9gia\u00a0funcionalidade -> processo -> Experi\u00eancia<\/em><\/li>\n<\/ol>\n

        Classifica\u00e7\u00f5es para segrega\u00e7\u00e3o de responsabilidades em servi\u00e7os<\/h2>\n

        H\u00e1 duas abordagens amplas, interessantes, a adotar quando se est\u00e1 segregando responsabilidades de um sistema em servi\u00e7os.<\/p>\n

        A primeira, proposta por Thomas Erl, consiste na separa\u00e7\u00e3o de servi\u00e7os em:<\/p>\n