Software Components

veryard projects - innovation for demanding change

software componentry

veryard projects > cbse > material
veryard projects > material > cbse

on this page

availability

links

articles in Interact

Richard Veryard is a regular contributor to the CBDi Forum's Journal Interact. He is available for adhoc consultation, engagements and commissions on business/software components and related topics.

Notes for product vendors

Notes for editors

Notes for event organizers

cbse

Articles published in Interact

veryard projects > cbse > material > Interact

Material published in the CBDi Forum Journal Interact is available online to Silver/Gold members of the Forum only. Single copies and reprints available by negotiation. Contact us for details.

Title	Abstract	Date
Processes and Process Frameworks		April 2002
Data Identification		March 2002
Service Identification	This article looks at techniques for the identification of web services. We suggest that service identification is not a linear progression of conventional analysis techniques, and that services require consideration of a number of additional perspectives. One of the important perspectives discussed in this article is the pricing of web servives, and the various pricing schemes available. Design of web services may be influenced by the need to maximize service revenue.	Feb 2002
Web Service Security (with Aidan Ward)	Microsoft and IBM are currently pushing different notions of trust and security. Microsoft is appealing to a model that harks back to the Fortress Mainframe of the 1960s, while IBM is developing a radically different model that appeals to biological rather than military metaphors.	Jan 2002
Semantic Standards		Dec 2001
Patterns and Reuse	Some software vendors are taking the incessant drive for productivity and reuse to a higher level of abstraction – not just software components but also software patterns. Within the Java community, the recently published set of J2EE patterns from Sun has been added to the longer-established design patterns from the Gang of Four. Several vendors are taking these patterns as a basis for further automation; and in this report we feature Compuware, which is taking the radical step of using open source patterns in its Java generation product.	Nov 2001
Component Identification (in two parts)	How to decompose a set of business or system requirements – or for that matter a set of Use Cases – into discrete lumps of componentry. This question leads to two further questions: How many lumps should you arrive at (Granularity) and how do you know if you’ve done it properly (Quality). This article aims to establish current best practices and outstanding issues. We also wanted to ask whether the method and tool vendors had moved forwards in their support for the component identification process. Part 1 identifies some of the main design styles that have consolidated themselves in recent practice. Part 2 evaluates and critiques these styles, and presents a CBDi Forum design framework and recommendations.	Sept 2001 Oct 2001
Component Pricing	One of the perennial topics of Component-Based Development – and now web services as well – is the supply and demand of components (and web services). Many CBD players are eagerly looking forward to a much livelier component market – healthy supply and healthy demand. Both of these factors are seriously inhibited if the pricing is opaque and inefficient. And yet there is surprisingly little serious discussion of pricing.	July / Aug 2001
Renaissance of Data Modelling	The new data modelling faces a new agenda, where business collaborations involve complex exchanges of information that cannot simply be packed into arbitrary strings of XML, where flexible interfaces require an accurate appreciation of the structure and meaning of the underlying vocabulary, and where integration of information systems across heterogeneous environments demands careful mapping and translation between different logical data views.	June 2001
Business Flexibility	There is a widespread belief in the business or social value of flexibility. A truly flexible business would adapt easily to changing demands and conditions, and could accommodate social and cultural diversity; and this in turn would depend (among other things) on flexible computer systems and platforms. This article provides a framework for understanding, planning and achieving flexibility.	June 2001
Mobile Computing	Should mobile hand-held devices be regarded as serious business tools or executive toys? Can we envisage serious business applications using them? Will they be integrated into enterprise systems?	May 2001
Trusting Components (with Aidan Ward)	The shift towards components and web services, and the increased separation between the producer and the consumer of a component or service, puts a growing emphasis on questions of trust. If we can’t trust components and services from external sources, how can we expect and ensure adequate security in the businesses and systems that use these services? In this report we examine the security and trust aspects of business interchange using components and web services, mainly from the consumer/procurement standpoint.	April 2001
Information Services	There are many ways of classifying web services. In this article, we focus on information services – web services whose primary purpose is to provide information. There are two motivations for this focus. Firstly, there are some things to say about information services in particular. Secondly, we want to draw attention to the separation and decoupling of information services from operational services – which may turn out to be a useful architectural pattern in itself.	March 2001
Legacy Refactoring	Patterns for evolving legacy software progressively towards a component architecture.	Feb 2001
Business Design from GoF Patterns	Can the design patterns in the Gang of Four book be used to design business processes? Do they represent general solutions to design problems at any level, or are they only meaningful to OO programmers?	Jan 2001
Differentiated Service	One of the risks of component-based development is that it merely shifts the complexity from the component itself to the wiring between components. One way to avoid this danger is to control the proliferation of different interfaces. If there are significantly fewer interfaces than components, this simplifies the wiring – leading to greater adaptability for the component-based system, and greater reuse opportunities for individual components.	Dec 2000
Towards Component Rigour	The next leap of automation in software reuse will be dependent upon rigorous notations for component specifications. For example widespread adoption of certification will probably not be practical without rigorous specification and Web services will require comprehensive description of the component interface in order to be self-describing. Within the world of software components, various tools and methods have appeared, claiming to offer "rigorous" and "precise" specifications of components and services. In this article, we look at these claims, and evaluate some of the leading methods in terms of the rigor on offer.	Nov 2000
The Job Bid Market	It has been suggested that one of the paradoxical results of the Internet will be a partial return to pre-industrial modes of production and exchange. In several domains now, services are starting to be traded through a kind of odd-job exchange, in which small items of piece-work are negotiated between buyers and sellers – sometimes even bartering rather than dealing with cash. Is this mode of production suitable for software production, or are software requirements too complex for such simple trading?	Oct 2000
Supply and Fit	Imagine an IT manager who argues as follows: "I can only use off-the-shelf components to the extent that they fit my requirements. Good components are highly generalized beasts, drawing their strength from economies of scale and reuse. My requirements are highly specialized. So although I may be able to make use of the odd component here and there, I cannot use Component-Based Software Engineering as my primary approach to building software solutions. In other words, Component-Based Software Engineering doesn’t fit the needs of my organization." This article responds to this challenge by taking a fresh look at some of the concepts taken for granted in this challenge: *fit, requirements, generalization, specialization*, and indicates some of the methods for making practical judgements about software components.	Sept 2000
Are you being served?	Who will be the leading players in the service-based economy?	July/ Aug 2000
Business Patterns	A survey of business patterns: what patterns (if any) are in circulation; what (if anything) is being done with these patterns; and how (if appropriate) we might take the idea of business patterns forward.	June 2000

top

home page