Artigo: Métricas de Reúso

Seis meses após o término das aulas regulares da minha especialização lato sensu em Engenharia de Software baseada em SOA (Service Oriented Architecture), meu artigo está aprovado pela coordenação do curso e agora estou oficialmente aprovado. Ainda falta sair o certificado oficial, mas tudo bem. Já posso postar aqui no blog o artigo e compartilhar não só a minha alegria mas também o conhecimento adquirido.

A UTILIZAÇÃO DE MÉTRICAS DE REÚSO PARA COMPROVAÇÃO  DE BENEFÍCIOS EM DESENVOLVIMENTO DE SOFTWARE BASEADO EM COMPONENTES

Why Web Services Failed at SOA (and Why REST May Fail Too!)

Why Web Services Failed at SOA (and Why REST May Fail Too!)
— First, let us review what is the concept behind services, with particular mention of the web services themselves.
A service is a business functionality exposed by a simple interface. Note that it is not an object, nor a method, nor a module, not a procedure. It is pure business functionality.
Services are consumed, not called, nor executed nor invoked. We define the service consumption as the interaction between agents, a client and a provider, which will communicate using a messaging system, where the data unit is a document. Consumption may be local or remote (meaning a service may not require remote communication).
A service may live in the web, where they are modeled as resources, identified by a URI. If not living in web, as suitable endpoint implementation should be provided.

Showcasing the Key Design Principles of SOA

Showcasing the Key Design Principles of SOA
— WS-BPEL 2.0 is the dominant specification to standardize orchestration logic and process automation between Web services. The BPEL model is used to assemble a set of discrete, essentially disparate, services into an end-to-end process flow to transform the existing stateless and uncorrelated Web service infrastructure into cohesive, process-centric applications based on a service-oriented architecture. Under this model, new applications are developed “on-the-fly” by wiring together external “partner” services that leverage existing enterprise assets.

The Four Stages of SOA Governance

The Four Stages of SOA Governance
— For several years now, ZapThink has spoken about SOA Governance "in the narrow" vs. SOA governance "in the broad." SOA governance in the narrow refers to governance of the SOA initiative, and focuses primarily on the Service lifecycle. When vendors try to sell you SOA governance gear, they're typically talking about SOA governance in the narrow. SOA governance in the broad, in contrast, refers to IT governance in the SOA context. In other words, how will SOA help with IT governance (and by extension, corporate governance) once your SOA initiative is up and running?

Dynamic SOA and BPM

Dynamic SOA and BPM

Abstract: After several years of companies industry-wide combining Services Oriented Architecture (SOA) and Business Process Management (BPM), the results are mixed. Some companies have had substantial benefits moving to SOA, while others have had average results. All these companies used the appropriate technologies, such as Web Services and Business Process Execution Language (BPEL) for processes, so the outcome should, in theory, be more predictable. It is now a good time for companies to extract the best practices and learn from others' experiences. This article is an introduction to "Dynamic SOA and BPM", a book which provides an exhaustive exploration of the best practices for delivering dynamic business processes and business services in order to quickly absorb market condition changes.

by Marc Fiammante

Published: September 25, 2009 (SOA Magazine Issue XXXII: September 2009)

Introduction

When SOA was initiated a few years ago, the simplified integration capabilities brought hopes of a simplified Business and IT landscape with reusable business components enabled by open technologies. There were however several reasons for not receiving the full business value of this services approach, including these essential ones:
• Business semantic tight coupling on a technical loose coupling: Many projects just used Web Services to implement a Client/Server approach. Any change in the server interfaces leads to client changes and high change costs.
• Business Processes reintroducing the tight coupling of flexible business services. Enterprises have implemented end-to-end processes such as order management in very large business processes, but then faced the lack of reusability of some sequences that could have been modularized and exposed as services.
• Rigid information models used to expose business services. In many cases services are only viewed as operations, forgetting that the business information structure that they carry will as well vary with the evolution of the business and lead to costly changes of services and processes.
Each of these experiences induced a deeper thinking process around what should be the essence of a business variable approach and how we could reach a true business/IT alignment with the expected shortened IT cycle enabling faster and cheaper business reactions.

Download PDF.

Are Services Nouns or Verbs?

Are Services Nouns or Verbs?
— Should Services be nouns or verbs? It's possible to design Services either way, as Entity Services, which predictably represent business entities, or as Task Services, that represent specific actions that implement some step in a process, in other words, verbs. Which approach is better?

The Role of the Business Analyst in an SOA World

The Role of the Business Analyst in an SOA World
— Those of us that are part of SOA-related projects where traditional business analysts (BA) are involved often find ourselves frustrated by the incongruence between the analyst’s approach to requirements gathering and the SOA design. The problem arises because SOA models functionality of a business across multiple boundaries, whereas the business analyst wants to focus on a user’s needs. One focus is tactical and the other is strategic. However, more than this key difference, certain aspects of the tactical requirements overlap with the strategic requirements; specifically with regard to service boundaries. Thus, important business rules that are relevant to the definition of a particular service are buried among hundreds of irrelevant (to the SOA goals) requirements and the SOA architect is forced to mine these requirements like a miner mining for gold.[...]

Why SOA Needs Cloud Computing - Part 1

Why SOA Needs Cloud Computing - Part 1
— It’s Thursday morning, you’re the CEO of a large, publicly traded company, and you just called your executives into the conference room for the exciting news. The board of directors has approved the acquisition of a key competitor, and you’re looking for a call-to-action to get everyone planning for the next steps.

Avoid Getting Lost on the (Enterprise Service) Bus

Avoid Getting Lost on the (Enterprise Service) Bus
— While purchasing an ESB too early in a SOA project does substantially increase your risk of failure, all is not lost. After all, you're not alone; this mistake is one of the most prevalent SOA snafus in IT shops around the world today, and not all of those projects end up as failures. Many of today's ESBs are now mature products, and can be an important part of a fully functional SOA implementation. Understanding the risks that buying an ESB too early in a SOA initiative presents, and dealing with those risks proactively, can turn a bad situation around and get your SOA initiative back on the right track.

The Overlapping Worlds of SaaS and SOA

The Overlapping Worlds of SaaS and SOA
— Software as a Service (SaaS) is getting a lot of attention these days. The concept of SaaS is not new and has existed for a while. It has been referred to by other names such as Application Service Provider (ASP), Managed service provider (MSP), on-demand services, cloud computing, utility computing etc. SaaS involves exposing applications over the network on a subscription basis with the pay-as-you-go model. This model was earlier popular with only small businesses who didn't want to invest heavily in their own IT departments, but slowly, this model is making its way into medium and large enterprises. SaaS offerings from companies such as SalesForce.com and Cisco WebEx have made this move up the chain possible. SaaS value proposition is now pretty clear to companies of all sizes and SaaS has become a crucial component of IT strategy for all companies.

Use The Source, Luke!

Use The Source, Luke!
—

Is ESB just an expensive integration hub or is there more to the story than we heard…

In the beginning, the ESB (Enterprise Service Bus), was marketed as much more than an integration technology. While the core of an ESB is certainly about connectivity between services, there was – and still is – so much more to an ESB than just integrating disparate protocols and technologies. Transformation, parallel processing, content based routing, and service orchestration are among the more useful and beneficial capabilities of an ESB.

That’s why it was somewhat surprising to see the CTO of an organization that offers an (open-source) ESB essentially quoted as discouraging the use of ESBs unless it’s for use as an integration hub. Dana Gardner, in To ESB, or Not to ESB?, analyzes MuleSource CTO Ross Mason’s recent blog that actively discourages architects from leveraging an ESB unless it’s necessary.

While the conversation focused on the pitfalls of using an ESB where you don’t need one, the Mule CTO naturally believes there are architectures where the ESB makes sense. To begin with, you need to be working on a project where you have three or more applications that need to talk to each other, he explained.

“If you’ve got three applications that have to talk to each other, you’ve actually got six integration points, one for each service, and then it goes up exponentially,” Mason said.

The ESB technology is also needed where the protocols go beyond HTTP. “You should consider an ESB when you start using Java Message Service (JMS), representational state transfer (REST), or any of the other protocols out there,” Mason said. “When communications start getting more complicated is when an ESB shows its true value.”

I could disagree more, but not much. The reduction of a robust technology like ESB – once considered the backbone of SOA – to little more than an integration hub was painful to read.

But what’s more painful is that the paraphrasing in Dana Gardner’s article misses most of Mason’s guidance. Reading through the original blog clearly indicates that Mason believes an ESB is much more than an integration hub and even spells out a rather lengthy list of “selection criteria” to help architects understand when and ESB will be beneficial and when it will not. But Gardner’s article appears to make the case that the only good use for an ESB is as an integration hub.

---

SECOND HAND INFORMATION OFTEN LACKING NECESSARY CONTEXT

---

The only disagreement I have with Mason’s list is that some of the criteria seems to contradict other criteria. For example, he states: “Do you need to use more than one type of communication protocol? If you are just using HTTP/Web Services or just JMS, you’re not going to get any of the benefits if cross protocol messaging and transformation that Mule provides.” but then offers “Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing?”

But what if I need aggregation of message flows and content-based routing between three or more HTTP/Web services? Oh the conflict!

Aside from that particular nit, which is really not all that much of one given that architects are smart enough to resolve that apparent conflict, Mason’s extensive set of questions not only offer proper guidance but also subtly lays out a comprehensive list of what an ESB can (and should) really do. He is not, as it appears from Gardner’s article, implying ESB is nothing more than an integration hub. In fact it appears that Mason is doing exactly the opposite as the list of criteria clearly leads the reader toward an understanding that if the only thing you need is integration, you might want to look at solutions other than an ESB. The problem is that the secondary article distills Mason’s guidance in an attempt to succinctly get to the point and in doing so oversimplifies the answer to the question “Should I use an ESB or not?”

The article about the original article is lacking the context necessary to properly interpret and understand Mason’s points. It’s much the same as we see in an application infrastructure, where multiple point products are chained together in an attempt to provide a variety of application delivery related services: security, optimization, load balancing, secure access, and acceleration. As data flows from one solution to the next, the original context is lost and the loss of that context means that most of the hops are bereft of all the juicy information (the lengthy list in Mason’s article) necessary to actually make intelligent decisions regarding the application of policies designed to improve application security, reliability, and performance.

The use of disparate solutions to provide related but separate application delivery functions takes the transaction out of context much in the same way second-hand sources tend to distill the original source until its context is nearly gone and changes its intended meaning. That leaves folks (and devices) interpreting information without the benefit of the original context, which can lead to the wrong conclusion (wrong policy, wrong decision, etc…).

Too, the simplification of a technology-related matter also bothers me not just because it does a disservice to ESB, but because it happens all the time with technology; I see it every day with load balancing and application delivery. Load balancing is certainly core to application delivery, the latter deriving from the former over time, but application delivery is, like ESB and any other evolutionary solution, comprised of much more functionality and value than its predecessor. Load balancing is certainly easier to implement, like point-to-point integration between two services, but the optimization, security, and acceleration benefits of application delivery are lost when focusing solely on load balancing much the same way the orchestration, processing, and management benefits of an ESB are lost when focusing solely on its integration capabilities.

Distillation is all well and good, and oft times necessary, but should not happen at the expense of the technology.

Technorati Tags: MacVittie,F5,ESB,SOA,integration,application delivery,load balancing,optimization,acceleration,security,protocols,JMS,content-based routing,Ross Mason,Mule Source,Dana Gardner,web,internet,blog

Related blogs & articles:

• From the Mule’s Mouth: To ESB or not to ESB
• Dana Gardner: To ESB, or Not to ESB
• The Context-Aware Cloud
• Governance: Service Catalogs and the Cloud
• SOA Announces Comeback Tour
• SOA isn't dead, but its standards are
• Is your SOA really SEA?
• Load Balancing as an ESB Service
• Business-Layer Load Balancing

Categories: Development and General , SOA Delivery , General SOA

SOA Infrastructure Blog: REST maybe part of the answer

In the last few weeks/months I have got more immersed in the world of REST and what it means to build and have a REST application. While at first glance it may seem that REST is a lighter weight version of a web-service implementation, it is by no means the complete answer and I do not believe REST is simply a replacement of Web Services because of how they operate is different.

When developing Object applications, in whatever language, you hit a reality that if your application is successful, then it will grow beyond the confines of the machine/JMV that it runs on, and as such you have to refer to objects that are beyond a single instance of the application's memory space. This can be done using a number of different technologies such as object databases that can map the same object into different application instances, but the locks are maintained by the central server so consistency of the objects are maintained, even if the object is distributed in 100s of applications at a time.

Read more >
SOA Infrastructure Blog: REST maybe part of the answer

The Five Basic Characteristics of SOA

The Five Basic Characteristics of SOA
— The Gartner Group just listed "9 ways to measure SOA success.” Not to take anything away from Gartner, but theirs is a pretty basic list, if you ask me. Indeed, these nine measurements are really about any successful architecture, using SOA approaches or not, which is fine. However, I have a few of my own that are more specific to SOA.

Getting the Links Straight Between Cloud Computing & SOA

Getting the Links Straight Between Cloud Computing & SOA
— Want to know what gets my blood pressure up? It’s when there’s both a huge shift in thinking around how we should do computing, namely cloud computing, and at the same time, there’s a bunch of information out there that causes confusion. As cloud computing hype spikes to a frenzy, so does the number of less-than-intelligent things that I hear about it and its relationship to SOA.

Building Architecture For SOA Policy Management

Building Architecture For SOA Policy Management

Eight Gates to Great SOA

Eight Gates to Great SOA
— While there’s certainly no shortage of opinions on the future of SOA, the reality is that SOA is very much alive. The core principles of what SOA can do in terms of cost savings, increased productivity, and the virtual elimination of information and application silos won’t go away. However, the term “SOA” will likely evolve into something else, as it becomes more and more a part of the computing landscape.

Bringing the Cloud to SOA

Bringing the Cloud to SOA
— There’s no shortage of opinions on how cloud computing and SOA are related. Just plug the phrase into your favorite search engine and you’ll have a day’s worth of reading. What you are likely to find are articles discussing how SOA led to cloud computing, how a good SOA is a prerequisite to leverage cloud computing, or how to leverage cloud computing in your SOA.

The Future of SOA

The Future of SOA
— As consumers we are accustomed to the end-user experience of the Internet. With HTTP and XML, you don’t need to have a specific application on your computer to make use of external data – you can just open a browser window and do a search or visit a particular Web site to find the information you need.

Agile Methodologies Improve the State of SOA

Agile Methodologies Improve the State of SOA
— Recently industry analysts, press, and bloggers have been writing about the state of service-oriented architecture (SOA) and whether it’s “dead” or in the “trough of disillusionment." These discussions have been fueled by surveys that suggest a decline in the number of organizations considering SOA, or that organizations have evaluated, but decided to shelve SOA for the time being.

Identify & Achieve ROI with Your SOA Training

Identify & Achieve ROI with Your SOA Training
— For many people, even entire organizations, the approach to education seems to be along the lines of learning facts, figures, details, tools and standards. This results in a shallow understanding of both the business problem and the new Service Oriented Architecture (SOA) strategies available for addressing the business’s needs. The next step is either to scrap the initiative or pour more time and money into patching the solution to bridge the chasm that could have been avoided with a more complete understanding of the domain and the implications and strategies surrounding service orientation.