SOA Video: Da série "Greg o Arquiteto"

Mais um vídeo da série "Greg, the architect". Desta vez os fornecedores "apresentam" SOA
para Greg que, confuso, tem uma "SOA overdose".

Uma boa definição de ESB

Este é um artigo muito didático sobre ESB. O artigo inicia com uma interessante visão dos desafios do software distribuido (vide figura acima).

O autor (Eric J. Bruno) enumera três grandes desafios quando se trata de software distribuido:

• O desafio da Complexidade (complexity)
  
• O desafio da Segurança (security)
  
• O desafio da Confiabilidade (reliability)

A solução? ESB. Segundo o autor, um ESB pode ser melhor descrito como tendo uma das seguintes características:

• Provides a reliable messaging infrastructure
• Enables SOA-based system development
• Is XML-based
• Supports web service standards (such as SOAP)
• Is platform independent
• Supports data transformation and routing services
• Enables service orchestration
• Supports transactions and security
• Integrates with existing standards, frameworks, and legacy systems

Vale a pena a leitura (21 pags).

O que há de errado na "ESB-oriented Architecture"?

No dia 12/Set/07, Bobby Woolf postou um controverso artigo no site DeveloperWorks (IBM). O título é "ESB-oriented architecture: The wrog approach to adopting SOA". Li o artigo assim que ele foi publicado e não tinha visto nada de "controverso" no seu texto. Voltei 1 semana depois no mesmo artigo e verifiquei que o autor havia inserido uma nota no cabeçalho do texto informando que alguns tinham interpretado de forma errada as suas conclusões.

Segue as minhas impressões do texto do Mr. Woolf:

1. O ESB, por si só, não traz nenhum valor para o negócio. ESB é "meio"e não o "fim" para SOA (aliás, Service-oriented Architecture, na minha opinião, é um "caminho" não um objetivo)
2. Ele está correto em sugerir fortemente para não utilizarmos a estratégia de "construir o barramento de serviços corporativos e esperar as aplicações SOA aparecendo em torno do mesmo". Tenha sempre uma estratégia para sua arquitetura SOA alinhada com o negócio, a arquitetura SOA não vai surgir apenas como uma necessidade de TI
   
3. A estratégia correta é: "implemente apenas e se necessário, apenas quando houver a necessidade do negócio, e não porque você está prevendo que alguém irá precisar desta implementação". Eu considero esta uma das regras de ouro da arquitetura SOA

Se você já tem um ESB na sua corporação, saiba que você já deu um grande passo em direção ao mundo SOA. Contudo, não caia na tentação de contruir uma "EOA" (ESB -oriented Architecture)!

Leia o artigo (3,5 paginas) e tire suas conclusões.

"Powerpoint" do Google Docs

Como usuário (e evangelista) do Mac OS, não utilizo os aplicativos do Microsoft Office. Utilizo o Google Docs e o NeoOffice (versão do OpenOffice para os equipamentos da Apple). No caso do Google Docs estava faltando um aplicativo para gerar apresentações... ...não está mais!

O Google disponibilizou o seu "Google Presentations", que está integrado ao Google Docs. Se antes a suite da empresa de Redmond não me fazia falta, agora menos ainda. Boas apresentações:

De volta ao Blog!

Após 05 longos meses estou de volta ao meu blog, desta vez utilizando o nosso bom e velho português. O foco do blog continua o mesmo: SOA, WebServices, Arquitetura de Software, Open-Source... ...eventualmente, alguma notícia interessante como esta:

Quer passear na Lua com o Google? Fácil vá até o novo serviço Google Moon e veja, por exemplo, onde as missões Apollo 11, 12, 14, 15, 16 e Apollo 17 pousaram na superfície lunar.

Poster: Werb Service Standards

InnoQ has this amazing poster that shows an overview of the Web services standards. There is also a PDF version.

SOA, CEP, Event-driven Architecture

Again EDA (Event-driven Architecture) and its relationship with SOA is being discussed. In my humble opinion EDA can use SOA to maximize its benefits. There is also an excellent article from SearchWebServices.com about SOA and CEP (Complex Event Processing): "SOA + CEP = 'a new physics of computing'.

When to use SOA and when to use EDA?
The answer comes from this post (Jack van Hoof's blog):

In contrast to SOA, EDA provides a way of loose coupling. EDA is not a synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa; components are loosely coupled in the sense that they only share the semantics of the message.

If you are seeking to support strong cohesion in the business processes, situations where all process steps are under one control, SOA is the way to go. The command-and-control style of SOA - in general – is applicable to:

• Vertical interaction between the hierarchical layers of functional decomposition
• Functional request-and-reply processes such as man-machine dialogues; the user waits for an answer
• Processes with a transactional nature which require commit and rollback facilities
• Data enrichment in a message to be published to bring the message to its full content in a formal format

If you are seeking to support independency between business process steps, EDA is the way to go. This style of architecture is appropriate in federated and autonomous processing environments. Recognizable situations where EDA might be applicable are:

• Horizontal communication between tiers in a process chain
• Workflow type of processes
• Processes that cross recognizable functional organization borders, external (B2B) as well as internal

SOA=Command and Control, EDA=Business Process Chain
This same post presents the "SOA X EDA" view:



EDA Overview
Brenda Michelson wrote an EDA overview in her blog (in fact, the best definition I've read).

Also from this post from Brenda' blog are the pictures below:

1. Complex Event Flow

2. EDA Implementation Components

What Is Software Architecture?

In this blog I write posts and more posts about SOA, ESBs, RIA... ...all these subjects and terms are related to Software Architecture. But, what is software architecture? Besides definition that you can find at Wikipedia, there is an excellent source of many definitions at SEI.CMU website. SEI is the Software Engineering Institute at Carnegie Mellon University.

Below some examples:

• First, architecture defines elements. The architecture embodies information about how the elements relate to each other. This means that architecture specifically omits certain information about elements that does not pertain to their interaction. Thus, an architecture is foremost an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. In nearly all modern systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts. Architecture is concerned with the public side of this division; private details of elements—details having to do solely with internal implementation—are not architectural
• Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution (note from Davi: this is my best definition ever)
• A software system architecture comprises
  - A collection of software and system components, connections, and constraints.
  - A collection of system stakeholders' need statements.
  - A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements.
• [Crispen 94]: An Architecture, as we intend to use the term, consists of (a) a partitioning strategy and (b) a coordination strategy. The partitioning strategy leads to dividing the entire system in discrete, non-overlapping parts or components. The coordination strategy leads to explicitly defined interfaces between those parts.

RIA versus JSF?

To be correct, the article's tittle is "RIA renaissance versus JSF dark ages?", from SearchWebServices.com. In this post I just want to write some excerpts:

- "Developers have a choice of tools and technologies for RIA, including Flash from Adobe Systems Inc. and the more generic Ajax, and they can even mix and match as best suits individual projects, he said during a Burton telebriefing on Tuesday. But they need to beware of tools and technologies that are inflexible. The theme of the briefing, "Build for Today, Architect for Tomorrow," was that architects and developers should select technologies and approaches to today's projects that are flexible, agile and not too complex, so that today's application can be modified to fit future needs."

- "Our confidence is pretty weak in JSF in general because we continue to get feedback from customers saying that the platform's too complicated..."

- "...Using Web frameworks like Shale and JSF and Struts to do RIA works, but it's inflexible. Because your interface is being generated rather than being coded, you don't have as much flexibility on how it's presented..."

- "What we're talking about is not Java in general, but a particular aspect of Java, which is the Java enterprise edition and that we do believe is overly complex to the point where it actually hinders productivity."

- "You can use them in combination. Many times we find that Ajax is the most powerful solution especially for enhancing existing Web apps, taking existing Web sites and adding some graphical capabilities to them. But sometimes it falls short and Flash or Java applets might be a better choice."

I completely agree.

JBossESB 4.0 Released

JBossESB 4.0 was just released. According to this news the next version (4.x?, 5.0?...) will be ready later year (2007). Below some features in this release:

• support for general notification framework. Transports supported include JMS (JBossMQ, JBoss Messaging and MQSeries), email, database or file system.
• trailblazer example.
• many quickstart examples to get you going.
• support for data transformations using Smooks or XSLT.
• listeners and action model to support loose-coupling of interaction steps.
• content based routing using JBoss Rules or XPath.
• support for registries, using JAX-R and jUDDI out-of-the-box.
• gateways to allow non-ESB aware traffic to flow into the ESB.
• high performance and reliability (in use by a large insurance company for 3 years).(*)

* probably it refers to the second-largest insurance company in Canada, where this ESB handles data from 3,000 employers and more that 2,0 million customers.

See an abstract view of ESB/SOA infrastructure:

SCA, SDO and DAS

Times from times I have read about standards like SCA and SDO in a SOA environment. This article was written by three IBM guys and it presents an overview of SDA and SDO.

Apache Tuscany project aims to create a infrastructure that simplifies the development of SOA-based systems. This project uses independent technology and standard that together provide:

• SCA: Service Component Architecture (SCA) enables composition of service networks through assembly of existing and new services;
• SDO: Service Data Object (SDO) provides a uniform interface for handling different forms of data, including XML documents, that can exist in a network of services and provides the mechanism for tracking changes;
• DAS: Data Access Service (DAS) provides a simple SDO interface to relational databases.

(image from Apache Tuscany website)

These specifications can be found at OSOA web site and Apache Tuscany provides input for them.

Here the SCA and SDO definitions from Tucany Project:

- SCA: "SCA provides developers with a simple, business-oriented, model for creating systems based on a service oriented architecture. It manages infrastructure complexities such as transactions, security and reliable messaging and frees the developer to focus on providing business function. The solutions developed using SCA can be changed declaratively to alter infrastructure capabilities or application configuration properties to meet changing business requirements. For example, infrastructure capabilities such as security policies may change from one environment to another and can be changed without the need for re-implementation. Application configuration may also be changed in this way, for example, the currency quoted by a stock quote feed may be changed though the SCA configuration mechanism."

- SDO: "Service Data Objects simplify and unify SOA data access architecture and code in a heterogeneous environment. SDO is programming language neutral. Within Tuscany it is being implemented in Java and in C++."

MULE ESB (II): 500,000 Downloads and counting...

According to this news at ebizQ.com, the open source ESB, MULE, has already more than 500,000 downloads.(image from MuleSource.com)

By the way, see below the environments where MULE can operate:

- Operating System: Red Hat / Fedora Linux, Windows Server, Solaris SPARC / x86, Suse Linux, Ubuntu / Debian Linux, FreeBSD, Mac OS X

- Java: 1.4, Java 5, 6 and 7

- Transport: JMS, MQ Series, Tibco, Oracle AQ, Web Services/SOAP, FTP, HTTP/HTTPS, SSL/TLS, Multicast, IMAP, In-Memory, JBI, JDBC, Multicast, SMTP/POP3, RMI, and more...

- Integration: Spring, JBI, EJB, GigaSpaces, HiveMind, JavaSpaces, JCA, JNDI, JOTM, JTA, PicoContainer, Plexus

- Web Services: Apache Axis, XFire, REST, SOAP, WebMethods Glue

- Application Servers: WebLogic, WebSphere, JBoss, Apache Tomcat, Geronimo, Jetty, JRun, Oracle, Resin

Good enough :-)?

MULE ESB: A Case Study

Eugene Ciurana (from Walmart.com) wrote this article that you can find at TheServerSide.com. The subject is ESB, more specifically MULE ESB. Version 1.3.3 is "fresh from the oven" with 27 issues/functionalities implemented since 1.3.2.

Eugene's text starts with a simple question: "Why are ESB needed?". After this there is an interesting comparation between the ESBs from TIBCO (Matrix BusinessWork), SUN (openESB), Progress Software (Sonic ESB), IBM (WebSphere ESB) and, of course, Mule ESB (open-source, MuleSource Inc.).

He points out some advantages of Mule ESB:

* Active open-source community and commercial support available
* State of the art implementation and ability to run under Java 5/6
* Number of relevant features out of the box
* Response time from vendors within 48 hours (average time for the winners was 2 hours)
* Ease of installation and deployment
* Ease of configuration and expansion
* “Codeless” integration with legacy, third-party, and commercial products
* Ability to drop in/pull out without incurring in lock-in or ancillary product dependencies
* Low total cost of ownership

And how Mule ESB enables two or more applications to communicate? Mule implements elegant protocols and standards based on well-defined patterns. Applications communicate with one another by implementing these patterns with a set of predefined components (see figure below):

Eugene continues:
"... - Applications interface with Mule over a transport.
- A transport carries service objects between components (some of the current documentation refers to service objects as “UMOs” or universal message objects; that term is deprecated now).
- The transport is any mechanism for exchanging data between two points
- Mule doesn’t implement or mandate use of particular transports. It offers instead a number of transport providers and the integration engineers or developers get to choose the appropriate one for a given application.
- A transport provider implements a message receiver or dispatcher, a connector that implements a protocol like JMS, TCP, etc., and an optional transformer.
- The transformer may be use to convert service objects from one format to another (XML to native Java, for example).
- Mule routes inbound and outbound data between transports through the service object component, which is responsible for managing component events to and from the component, and for managing pooled resources. ..."

Good reading!

RIA and SOA

I am investigating the advantages of RIA (Rich Internet Application) over the traditional Client/Web interfaces. In this article, Duane Nickul, Senior Technical Evangelist at Adobe, puts some light in this discussion.

Lest start with a traditional SOA stack:

Since a human being lives in the world above the service consumer,
the service itself will not necessarily care or be aware that a human is there. However, it is highly likely that humans are part of a service call and exist as either the trigger of some event that results in a service call and/or are the ultimate
consumers of the service result themselves. While contradictory to the title
of this article, one could state that humans are not directly part of SOA any
more than business processes are. However, both business processes and
humans utilize the SOA infrastructure.
To architect such interactions, architects should take great care to abstract any details of the service itself away from the human. The human should view the
"V" (view) component of MVC and not care about the "C" or "M" components. Accordingly, architects need a mechanism to present consistent views to the human that are abstract of any dependency upon the service.

Client-server Approaches:

1. Traditional Approach

2. AJAX, Flex mode for RIAs (new approach)

3. Final Considerations

In the Flex example shown, web services are used to communicate interactively
with the services at the bottom. Note that the cardinality is not limited in any
way to 1:1. A Flex or AJAX application may communicate directly with multiple
services, then abstract all the complexity of SOA and present the view and some
control components to the human being above the client side.
Several recent examples of the model for RIAs to interact between humans and services can be seen all over the Internet. Some applications like Apple iTunes have viewer panes which are generated locally on the client machine—such as the user's music library (see Figure 4). When they switch panes to view the iTunes Music Store, they connect directly to the Apple iTunes Music Store service, retrieve a result set, and then present it to the human being (see Figure 5). To the human being, the end result is a seamless experience joining both service calls and local
processing into one application

Implications of SOA on Business Strategy

This is an article that you can find in SOA Magazine, 3rd edition (Jan/2007). Thomas Erl is the site editor of this excellent source of information about Service-oriented Architecture.

Below some excepts from the article "Implications of SOA on Business Strategy and Organization Design", written by William Murray.

1. From Business Tasks to Business Services
In 1994 Hammer & Champy's “Manifesto for Business Revolution” argued that technology could be applied at the process-level to significantly improve organizational efficiencies through streamlining organizational processes, structures and governance, thereby bringing to the mainstream the discipline of business process reengineering, and the concept that business processes are the fundamental building blocks of the corporation. This is the beginning.

2. The IT Utility Curve
From this manifesto, we see that, regarding technology adoption in a company, there are three phases, mode and planning posture to this adoption:

Phases: Enabling, Disruptive, Enabling
Modes: Experimentation, Innovation, Commoditization
Planning Posture: Tactical, Strategic, Tactical

The graphic that shows the investment along these phases or modes is a "S" curve:

SOA Meta Model

This is what David Linthicum proposed as SOA Meta Model.

Ten Things to Think When Building SOA

David Linthicum wrote another excellent article. The tips (listed below), in fact, tell us what to do and what NOT to do regarding SOA implementation. Let's see the " rules" with my notes:

1. Focus holistically, act locally: SOA is NOT a project. SOA is a path that not ends, like quality (in an broad sense). SOA is the sum of many parts and you should take them in count when implement you architecture.
   
2. Define the value: Strategy is important, better, a business case. If you defined that SOA is the new architecture approach for you company, how it can happens if there is no guideline that will make this happen?
   
3. Don't neglect service design: What we have behind composite application and composite process?... ...Services! So, they deserve special attention. Web Services must be design to be reused, to provide behavior and information (not to be app specific), must be aware of hardware and O.S. (no calls to native interfaces).
   
4. Leveraging a legacy is unavoidable: What keeps our business running? Legacy systems! Service-oriented architecture came to allow you to take the best from these legacy systems, not to rewrite them.
   
5. Remember the semantics: When dealing with data think about the real meaning of them, the context of this information, the semantic... ...ask yourself which relevant information you can extract from this data?
   
6. The proper place for orchestration: SOA implementation does not necessarily need orchestration to run. However, consider it for some application.
   
7. Security soaks in as you execute; it's not an afterthought: You might firstly developer Web Services for internal use, but in a near future they can be used for other companies (partners). Think about Identity Management from the beginning.
   
8. Classify the patterns of use: Three rules when implementing Web Services: patterns, patterns and patterns.
   
9. Persistence is important: "... You need to think about persistence for a few reasons, including federation of services around the SOA. When building an SOA you may end up with composites or processes created out of services that may exist over a dozen or more different systems, and as such, persistence becomes more complex if done at the points...".
10. Don't skimp on testing: Keep in mind that most of the data and system that Web Services will deal with are business-critic. Thus a test plan is very important and this must be written from the beginning.
    

100+ in TI Innovation

In last December 2006 Transit received an important prize: it is one of 100+ in TI innovation (category: Telecom and Technology). The project submitted is related to "CDR convergence and mapping using SOA".

See all categories and the winners. I received, on behalf of IT team, this prize.

See below other picture.

SOA Book in my Wish List

This is the #1 SOA book in my wish list. Please feel free to donate one :-).

Happy 2007! (now with blackberry)

This Blackberry (BB) you are seeing is (was) one of the most desired gadgets in my "wish list". It was a suprise on my birthday (Dec, 27th). Now I can post directly from my BB, read and write my e-mails, browse the Internet, send SMS... ...and, believe or not, I can you use it as a mobile! Simply wonderful. I've asked myself how I could, so far, live without one of them?

Thanks Debby!