Objetivos y Beneficios de SOA

en espagnol

Es muy importante establecer qué tanto los proveedores y las comunidades de usuarios finales dentro de la industria de TI están pasando por el problema de la adopción de la plataforma de computación orientada a servicios y que abarca todo el cambio que viene con él. La visión detrás de la computación orientada a servicios es extremadamente ambiciosa y por lo tanto también muy atractiva para cualquier organización interesada en mejorar verdaderamente la eficacia de sus TI de la empresa. Un conjunto de objetivos comunes y los beneficios se ha convertido para formar esta visión. Estos establecer un estado objetivo de una empresa que adopta con éxito el servicio de orientación.

El conjunto de las próximas secciones describen cada uno de estos objetivos estratégicos y los beneficios
- El aumento de la interoperabilidad intrínseca
- Aumento de la Federación IT
- Aumento de las opciones de diversificación de proveedores
- Aumento de Negocios y Tecnología de alineación
- El aumento de rendimiento de la inversión
- Aumento de la agilidad de organización
- Se redujo la carga

Es beneficioso para entender la importancia de estos objetivos y los beneficios antes de estudiar y aplicar la orientación a servicios, para que los principios de diseño son siempre vistos dentro de un contexto estratégico. 

What they do ???? ...Software Architects

What they do: Like architects who design buildings, they create the blueprints for software engineers to follow -- and pitch in with programming too. Plus, architects are often called on to work with customers and product managers, and they serve as a link between a company's tech and business staffs.

What's to like: The job is creatively challenging, and engineers with good people skills are liberated from their screens. Salaries are generally higher than for programmers, and a typical day has more variety.

"Some days I'll focus on product strategy, and other days I'll be coding down in the guts of the system," says David Chaiken, 46, of Yahoo in Sunnyvale, Calif., whose current projects include helping the web giant customize content for its 600 million users. Even though programming jobs are moving overseas, the face-to-face aspect of this position helps cement local demand.

What's not to like: You are often outside the management chain of command, making it hard to get things done.

Requirements: Bachelor's degree, and either a master's or considerable work experience to demonstrate your ability to design software and work collaboratively.

Thinking SOA

A Service-Oriented Architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.
Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification. For more on DCOM and CORBA.
CORBA ? ORBS ...this is SOA until 1967.


CORBA is the acronym for Common Object Request Broker Architecture. It was developed under the auspices of the Object Management Group (OMG). It is middleware. A CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.
The first service-oriented architecture for many people in the past was with the use of Object Request Brokers (ORBs) based on the CORBA specification. The CORBA specification is responsible for really increasing the awareness of service-oriented architecture.

SOA not new technologies, SOA is re-engineering the CORBA and similar concepts...

Software architecture is a coherent

Software architecture is a coherent set of abstract patterns, or principles, guiding the design of each aspect of a large software system.

Software architecture underlies the practice of building computer software. In the same way as a building architect sets the principles and goals of a building project as the basis for the draftsman's plans, so too, a software architect or systems architect sets out the software architecture as a basis for actual system design specifications, as per the requirements of the client.

Software architecture is like an architecture of a building in that it has to do with the purpose, themes, materials, and concept of a structure. A software architect employs extensive knowledge of software theory and appropriate experience to conduct and manage the high-level design of a software product. The software architect develops concepts and plans for software modularity, module interaction methods, user interface dialog style, interface methods with external systems, innovative design features, and high-level business object operations, logic, and flow.

A software architect consults with clients on conceptual issues, managers on broad design issues, software engineers on innovative structural features, and computer programmers on implementation techniques, appearance, and style.

Software architecture is a sketchy map of the system. Software architecture describes the coarse grain components (usually describes the computation) of the system. The connectors between these components describe the communication, which are explicit and pictured in a relatively detailed way. In the implementation phase, the coarse components are refined into "actual components", e.g., classes and objects. In the object-oriented field, the connectors are usually implemented as interfaces.


What is Software Architecture? Some definitions make me feel a little confused about structure and architecture. According to Bass’s book, one software architecture can have many structures at the same time. So what is the difference between software structure and software architecture? English is not my first language, so I have to borrow a hand from dictionaries. In Merriam Webster, structure means "the arrangement of particles or parts in a substance or body" (I just picked one meaning which I think is more proper than the others to my topic) while architecture is "art or science of building; specifically the art or practice of designing and building structures" according to MW. Architecture seems having much more things than structure. So I believe that software architecture contains structure or structures. Many people think structure and view can be used interchangeably. However, that depends on how you understand the word "structure". I would rather make it simpler to think it as only a module structure, which contains components and connectors,, which is also the elements mentioned in Perry and Wolf’s paper. Since software architecture is the art and science of building software structure, it must have much more plentiful contents, such as rationale (which is related to requirements and implementation), abstraction, architectural style, overall structure, constraints, multiple views, multiple models, and so on, it even includes representation and evaluation. I have to admit that I am a total beginner to this discipline, so please forgive me if some idea seems quite immature to you. However, I just want to make sure if I really understand what I am doing now. Finally, I agree, in practice, as Bass said in his book, the lack of an engraved definition will not prevent us from making good use of the concept 


Source :
Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice. Addison-Wesley, 1998.
Dewayne Perry, Alexander L. Wolf. Foundations for the Study of Software Architecture. ACM SIGSOFT Software Engineering Notes, pp. 40-52, October 1992.

DNA of Software Architect ...

Software Architects must have excellent communications and base technical software skills.
Communications skills are the skills that I work on the most because they are the most critical for an architect. Don’t get me wrong: technical skills are an absolute necessity, but without top communications skills, it’s going to be difficult to get your vision into the heads of others. Many of the disciplines, attitudes, and ideas that I discuss in my IT operations article also apply to solutions architecture. The highest responsibility of an architect is communicating the solution to the business leaders, technical leaders, and any other interested parties in a language that they understand. Architects need to have a mastery of three languages: business language for communicating with the business people, industry language for communicating in the vernacular of the business, and technical language for communicating to the technical leadership and the developers. I personally have a dual degree having majored in business (marketing) and minored in engineering. I actually started out in engineering and then started taking business classes in my junior year. At a job fair job fair I kept hearing that I should take some business classes because I would be out working with business people and would need to understand their world. Thinking back, my team won an engineering competition not because of the technical merit of the solution, but because we had given the business case for the solution to a panel of judges who happened to be all business people. We spoke in a language that they could understand. We need to speak in a language that an audience can understand. It is often the case that the audience will not tell you when they do not understand you, and a confused mind will always say no. So be sure to understand your audience, and then be sure to speak their language. I have worked in many different industry sectors, all with their own specific domain languages. As a result I picked up a habit early on in my career that has allowed me to quickly learn each domain. In most business lobbies, trade magazines for that industry are displayed. I would read these magazines as I would wait to meet with the client. I would also take the free subscription cards for the journals and send them in to get my own copies of the periodicals. Granted this was before the Internet, which has made industry specific research much easier. The point is that you need to become familiar with the domain in which you will be developing a solution. And whilewe are on the topic, I believe that there is a tremendous benefit to having experience in multiple industries and domains.


This allows you to be like a bumble bee and cross-pollinate the best ideas across industries. I have also found that the DNA of most architects has a hunger for knowledge in a broad range of subject areas. Architects are interested in knowing about things and understanding how things work. Architects can then synthesize this knowledge into creating solutions. 

It is assumed that architects know the technical language. Yet this is not always the case as not all architects come from the technical ranks. And even if an architect comes from the technical ranks, their vocabulary and experience may still be narrow enough to hinder communications to all parties. I believe that an architect needs to understand several development methodologies and development environments, and also understand infrastructure, security, databases, business integration, and operations and support. Blindness in any of these areas can cause problems, however such limitations can be overcome with a team of architects and or a good network of peers. 

Source : ITABOK - http://www.iasahome.org/web/home/skillset

Uma boa opção para definir e customizar processo de engenharia de software

Se queremos produzir com apoio de uma ferramenta um processo de engenharia de software customizado no que a empresa necessita, pode-se atualmente encontrar com boa qualidade.

O Eclipse Process Framework (EPF) visa produzir um software com características próprias, fornecendo ferramentas e conteúdo que pode ser usado como base para uma grande variedade de processos de TI a fim de resolver necessidades. O EPF ajuda na autoria de métodos, ferramentas, processos, gestão de configuração de bibliotecas de métodos para processo e publicação de processos. O Framework conta com exemplos de processos prontos para serem adaptados, reutilizados a processos de desenvolvimento de software e ferramentas que são suportadas por vários tipos de projetos e formas de desenvolvimento. Ao usar EPF Composer pode-se criar o seu próprio processo de desenvolvimento de software e estruturá-lo em sentido específico, usando um esquema predefinido, aderente ao processo a ser registrado. Este esquema é uma evolução da Software Process Engineering Meta-Model (SPEM 1.1) de especificação referida, como o da Arquitetura do método unificado (UAM - Unified Architecture Method). Grandes partes da UAM foi recentemente adaptada para a revisão da SPEM e o EPF Composer irá apoiar plenamente o SPEM 2.0 em futuro próximo. A UAM e a SPEM são projetos de apoio à organização, com grande quantidade de descrições de métodos e processos de desenvolvimento.

Os projetos individuais de diversas organizações de desenvolvimento de software podem facilmente transferir e implantar os processos capturados no EPF. Eles podem personalizar processos existentes através da mistura de correspondência de conteúdo de vários processos, por remoção, adição ou personalização de conteúdo através da aplicação de conteúdos fornecidos por plug-ins. Os processos resultantes podem facilmente ser implantados, e continuamente evoluir, acomodando as lições aprendidas à medida que o projeto avança.



Definição do Processo com o auxilio do EPF Composer


O processo foi definido com a intenção de ser mais leve possível, mantendo entretanto a formalidade necessária para o desenvolvimento flexível, ágil e estável.

Como visto anteriormente a grande particularidade do EPF Composer é a categorização dos elementos padronizados no SPEM, em dois conceitos principais. São eles: Method Content e Process.

O Method Content descreve o que deve ser produzido (WorkProduct), as competências necessárias exigidas (roles), e as instruções passo-a-passo (steps) explicando como os objetivos serão atingidos. Process descrevem o desenvolvimento do ciclo de vida, relacionando os elementos dos Method Contents em seqüências semi-ordenadas que são personalizadas para determinados tipos de projetos.

Ao definir o processo no EPF foi criado primeiramente o plug-in, que poderia ser denominado hipoteticamente como PDS ou Processo de Aquisição de Software. Posteriormente foi criado a estrutura de pacotes dentro do Method Content que, nesse


caso, foram as etapas do processo definido levando em consideração o ciclo de vida do projeto, por exemplo: requisitos funcionais e não-funcionais, projeto, desenvolvimento, etc.. Cada pacote é expresso usando WorkProduct (artefato), role (papel), task (tarefa) e guidance (guia) relativo a sua etapa do processo assim como pode ser observado na figura abaixo. Os guias estão posicionados na interseção entre Method Content e Process, pois podem expressar informações para as duas categorias definidas no EPF.


Iniciando uma instância do projeto a partir do processo definido no EPF


Na utilização do processo publicado através da ferramenta EPF podemos constatar um ambiente rico em conhecimento, contemplando, todas relações entre papeis, tarefas, artefatos e guias, permitindo obter mais detalhe sobre cada item do processo. Ainda é possível verificar as relações das fases como, por exemplo, inspeção e as atividades envolvidas, Gerenciamento, Modelagem de Negócio e Requisitos. Podemos verificar claramente tal situação, como ilustra a figura abaixo.



Um ponto forte na utilização do processo publicado foi à possibilidade de desempenharmos papeis mesmo estando separados geograficamente, através da uma intranet. Isso facilitou o desenvolvimento do projeto, principalmente nas tarefas de curto prazo.

Os guias podem ser uma grande ajuda uma vez que, tornam-se indispensáveis na busca de informações para desempenhar de forma eficaz algumas atividades, como por exemplo, em uma fase, etapa projeto, na atividade de definição de casos de uso, onde sentimos a necessidade de obter exemplos da especificação e diagrama de caso de uso ou de um outro diagrama dinâmico ou estático.

O processo definido no EPF Composer, aponta diversas vantagens com pode ser visto, atendendo a todas as nossas expectativas e superando as nossas necessidades, proporcionando assim, uma resposta rápida e eficaz as demandas dos stakeholderes.

Era uma vez o Java...será ????

Desde meu ínicio na carreira em Tecnologia da Informação, desde 1993 quando tive meus primeiros contatos com estágios não remunerados e remunerados em linguagem de programação e o mundo profissional de tecnologia da informação, com linguagens como C Standard para Unix e MS-Windows, Clipper 5.2d, lembram ??? MUMPS para AIX...bem eu começava em 1997, já antes do Java programava algumas automações de backup e aplicações de baixa complexidade em Python e SmallTalk com a ferramenta da IBM...também lembram ??? Assim comecei a ouvir de professores, colegas sobre a linguagem OAK ...mais tarde o Java, o querido Java do nosso depois mascote Duke que reuniria funções, tecnologias de linguaguens como C, C++, SmallTalk enfim ...uma boa invenção do nosso colega James Gosling, não vou ficar aqui fazendo trilha das linguagens que implementei e conheço e propaganda de uma linguagem e plataforma de desenvolvimento como o Java, não precisa não é ????
Mas então a Oracle conseguiu ??? O que ???
Iniciar a ação predatória dos cientistas da antiga SUN, cientistas tem seus métodos, seus cronogramas que não são parecidos com os cronogramas do mundo MakeBizz, não é ? Hoje podemos dizer que se a SUN não conseguir equalizar esta falta que Gosling fará ao projeto e sua continuidade, teremos muitas baixas de empresas que irá preferir estar com tecnologia similares como o Python e estável em sua continuidade, veja não entendem que estou querendo dizer o Java terminou, não é isso...mas sem Gosling perderá força !
A Oracle tem seu jeitão e não mudará já fez isto com o Weblogic, o servidor de aplicação mais estável na minha opnião profissional e hoje o Weblogic já mostra a nova cara com o jeitão da Oracle, não sei mais esperamos que a essência do Java não seja dilacerada.

Abaixo posto o blog pessoal do sr. James Gosling :
http://nighthacks.com/roller/jag/


O mundo do desenvolvimento de software hoje tem de abstrair estes STACKs de linguagens e convergir em uma unica notação ...