AA using WS vanZyl 2002-05-06

AA using WS vanZyl 2002-05-06.doc Updated: 06 May 2002 Page 1

Application Assembly using Web Services Software application realization and deployment through the use of software assets and assembly

Dr. Jay van Zyl

Rubico Products (Pty) Ltd, Postnet #22, Private BagX87, Bryanston, 2021, South Africa

Summary: The momentum created by web services has opened a number of topics that relate to the ability of non-technical people to construct and deploy complex business management software. History has shown that every time a promise of this nature is made that disillusionment sets is before realistic expectations are set. How realistic is the vision of having non-technical people constructing systems, and still having data integrity, performance and usability attributes attended to? Rules of how a business system can be abstracted must be defined in order for development and delivery organizations to operate together in providing software solutions. This paper presents an approach to doing application assembly and deployment by understanding the separate elements from abstract requirements to software implementation. Some of the challenges that exist when trying to implement a systems assembly paradigm are discussed. The separation continuum is presented as a solution to understanding the various elements that make up a business system. It is also used to determine what needs to be included when product lines are assembled using assembly tools using software assets.

Keywords: architecture, separation of concerns, separation continuum, patterns, application assembly, Web services

1. Introduction

The vision behind web services is nothing new. A definition of web services as defined by the CBDI Forum [CBDI] is: “A web service provides a location independent business or technical service in a manner that the consumer of the service does not need to be aware of the implementation of the component providing the service.” Gartner [Gartner] has a slightly different, and more technical view on this: “Web services are loosely coupled software components delivered over Internet standard technologies. A Web service represents a business function and can be accessed by another application over public networks using generally available protocols and transport. It can also be accessed directly by a user through a client interface. This business service can be implemented as a stand-alone application or a series of applications linked by an application integration infrastructure.”

Implementers of software solutions have been trying to find better ways to deal with reusability, connectivity and usability to mention a few. Re-usability processes and concepts have brought to bear a new way of developing solutions, where the elements of the system are scattered all over the world or local area network. System construction mostly deals with the exploring, find and usage of pre-built functionality. This functionality could’ve been created by an organization’s own developers or they might’ve been “hired” from a provider of functionality. One of the questions that need answering is: how feasible is it for non-technical people to assemble and deploy systems.

Components come in all forms and shapes, where services are more limiting in its usage and implementation. If providers of web services stick to

the cross-platform, cross-connectivity standards, developers all over the world can focus on the one thing most important to them, functionality realization. Object technology is built using specific technology for execution, where components can wrap technologies, separating the interface from the implementation. Services take this one step further in that the interface and connectivity mechanism is completely independent of the platform that hosts the functionality. This promises to allow execution of functionality over a distributed and dispersed environment. By using this paradigm, many of the conventional deployment and execution methods of software components are challenged.

With functionality available “globally” the interface of how this can be used by audiences other than the creators and constructors, needs a new look and feel that is different to the traditional integrated development environments. Once functionality is made available in the context of a particular business system, business users should be able to change the more volatile areas of the software system to match their exact requirements. A provider of business patterns can assist the business related user with the combinations of abstractions, processes, and components needed to construct a particular software business service, where business service equates to a Web service.

Web services might be seen to be an integration tool only [Chester] where traditional enterprise application integration teams can move their efforts from tightly to loosely coupling of systems using XML (Extensible Markup Language) formatted messages and over HTTP (Hyper Text Transfer Protocol). This paper presents a

Application Assembly using Web Services


much wider picture whereby systems construction and deployment need to be looked at afresh.

2. Challenges with and the promise of application assembly

The provision of re-usable, easily deployable software functionality has never been an easy task – Web services do not make things much easier. In actual fact, design techniques applied need to be more precise and more disciplined than before. Having developers in organizations supplying and using Web services use re-usable software-as-services, can put major pressure on disciplines that might not have been implemented before. It might be the case where core functionality of a system is never owned, but just rented based on use.

Some of the specific challenges that were found as part of this research include: Firstly, taking abstract thinking into software is still a concern, and even more so with giving non-technical audiences the ability to assemble applications. New concepts must adopted by the software supply community in context of the technology platforms used. Secondly, the benefits of application assembly are not always understood, where developers want to “write code” and business users want their unique requirements implemented in unrealistic time frames. Thirdly, pricing of Web services and components is still a contentious issue especially when looked at in context of intellectual property right ownership.

2.1 Taking abstract thinking into software

Systems analysts, designers, developers and testers deal with great deal of complexity when performing their individual roles in the software development life cycle. In order for humans to break down complexity into manageable pieces of work, layered architectures have provided much assistance.

2.1.1 Paradigms

Object orientation took organizations years to implement even though the apparent “ease-of-use” means of identifying and using objects. Research in this field produced results that show how long it took for the adoption to take place. Componentization was the natural evolution and convergence of a number of technologies including the renewal or legacy systems and the exposure of components based systems to courser-grained applications. These shifts produced major disruptions in information systems providers to both internal and external customers.

The move towards service-based architecture presents another evolution in thinking and might produce the same challenges to transform the organization’s information systems departments. Transformation

should be easier due to the lower levels of technology skill required to realize software functionality.

Software-as-services can be provided within a development team, organization, community or across multiple organizations. The aspect of trusting the source of the service will need to be addressed by means of certification based processes. Characteristics of security, performance, usability, data ownership and configurability are some of the most commonly mentioned issues during this research.

2.1.2 Technology

Most platform vendors have embarked on Web service infrastructure provision, but only two host Web services themselves, namely Microsoft and IBM. All of these technologies are still in their infancy and have some way to go before organizations can use these productively and securely, as no physical software component is ever deployed only its interface is . Other providers of Web services are springing up from many different locations in their pursuit for market share. Between Microsoft, IBM, BEA, HP and Sun gorillas [Moore] will emerge i.e. major market leading platforms . The smaller players which provide Web services platform capabilities will quickly be absorbed in one or more of the platform providers.

Security is still a problem over the web even though security organizations and platform providers provide secure transaction ability. Application security in itself is not going away, but will become more complex, especially when managing applications that are constructed in a loosely coupled environment. Loosely coupling means that configurations can determine the sequence of execution possibly from remote locations. Security requirements need to be removed from the abstract application layers and implemented in the technology platforms.

Standards provide a great deal of usability, as once the service provision community has adopted a core set of standards, tools should mature into this space. Emergence of standards like MDA (Model Driven Architecture) tries to address the problem of having one platform independent standard to system specification. Wiring services together still have a multitude of standards that can be used creating confusion as to the selection and appropriateness. Developers need to think about providing re-usable software components as Web services, where they can be “told” how to behave and what data to use. Essentially business rules and data definition is removed from the underlying software components.

2.2 Understanding the benefits of application assembly

Benefits to the business community might come in the form of a better return on investment of the application



of business products. Currently, most organizations have a clear strategy to purchase software packages where functionality is already built and can be provided in an instant. It is only under extreme cases that software build options are explored. It is normally the case where businesses cannot do without the unique functionality required to operate their business.

Once the build option is embarked upon, the question is will developers trust and re-use the functionality provided by someone else, and that possibly over the Web. One can already see some usage in the area of web sites and portals that use news provision, stock indicators and authentication services for example. Developers have a hard enough time re-using each other’s code in the same organization, how will Web services make it different?

Specific productivity tools are required to realize the benefits of Web services. Platforms cater for mass-market deployment, where application assemblers focus on more specific implementations. Rubico’s Assembler tool is such an environment – assembly of applications using patterns. Benefits of using such a tool are tangible when time-to-market, quality, staffing-requirements, and the ability-to-implement-unique-requirements, as drivers are significantly affected.

2.3 Pricing and intellectual property

Pricing models will change as software components are never really owned or installed in the Web services infrastructure. There will be hybrids where some software will be licensed, but the drive is towards software as services – the ability to pay for usage only. One-time licence fees will be affected as users of the services will pay for a group of services on a periodic basis. A means of managing membership and subscription will be more prevalent rather than paying software royalties.

If some parts of a solution is then executed, and built, outside of the organization, strategies need to be in place to deal with intellectual property rights. When developers construct unique requirements into software, it is normally done because of competitive advantage. Business owners will not be happy to give this away unless there is a means of protecting their unique ways of doing business that is the essence of their competitive advantage.

This particular topic is not discussed in this paper, but represents a major field of study in the context of software systems that are made up of diverse and loosely coupled pieces of software.

3. Application assembly

In order to understand the implications of application assembly and deployment using Web services, a common architecture for abstraction will be discussed

next . Software-as-services can also be seen as a different way to realize software systems – the concept of deploying software to specific infrastructure is no longer needed. The principle of “wiring” services together in order to create a product line is the essential link between business requirements and software infrastructure.

The separation of concerns is discussed to provide a context for where Web services fit in relation to other models and architectures. Assembly using Web services shows how the Web services are used in order to assemble applications.

3.1 Separation of concerns

The separation of dimensions, based on context and relevance, are fundamentally important when defining a product line architecture [Doerr]. Aspect-Oriented Frameworks [Constantinides] can assist with the challenge that is faced by so many designers and architects. Aspects refer to the properties of the system that do not align directly with a system’s functional requirements, but cut across functional components increasing their interdependencies. Web services models [Oellermann] are designed to be independent of the actual service and consideration for languages, tools, and platforms.

“Horizontal separation” is concerned with the separation of how the user interface is independent of the connectivity and, in turn separate from the business logic and data access. “Vertical separation” is the layering needed to implement platform elements separately from the higher levels of abstraction needed at application levels .

Figure 1: Separation continuum

Vertical separation of contexts in the organization, considers the following moving from abstract layering to platform implementation:

Business Model: This layer represents the basic concept of “doing business”.



Systems Model: The systems model deals with the business systems required to satisfy a specific business model.

Applications Portfolio: Applications are required to automate required business systems.

Services Architecture: This architecture is concerned with the breadth of functionality needed to implement the business systems via the applications portfolio. A generic term that could be used here is “Web service” or “service based architecture”. This is where this paper will focus.

Component Architecture: The component architecture view presents a complete view of the business components that can be exposed as services. Components are typically course grained software elements that satisfy a particular requirement.

Object Architecture: Components are created from object or other technologies and exposed as business components. Objects are the finest granularity of functionality in a typical system.

The horizontal dimension is made up of the following elements on the platform implementation continuum – moving from visual to non-visual capability:

User interface: the interface that is used by the user of the system that might include a multitude of devices including web browsers, personal devices, etc.

User interface controller: this controller is needed to manage the behaviour of the interfaces (for example, Web pages) that connect to the business logic layer.

Services and business logic layer: the ability to have a cluster of business and/or technical services exposed to the user interface.

Connection or middleware layer: the ability of the user interface to connect to a server that directs the way in which the interface is used.

Data provision layer: the ability to store in a reliable fashion that may be used by the services layer to deal with transactional, system and meta-data data definitions.

Application assembly and the use of Web services is discussed next.

3.2 Assembly using Web services

Elements of an applications portfolio will be constructed using Web services. The selection and use of these services form an integral part of what the application’s ultimate intentions are. There needs to be a clear separation between services that are used for private purposes from those that are used for public purposes. A currency converter invoked from a web site as an add-on feature can easily be external to the organization, but more mission critical services need to

be owned and implemented in a more controlled manner.

3.2.1 Services architecture

This architecture is concerned with the breadth of functionality needed to implement the business systems via the applications portfolio. A generic term that could be used here is “Web service” or “service based architecture”. It means that the application portfolio is constructed out of independently usable software components that are exposed as services.

Services must be defined in such a way that they can be used in a loosely coupled way – meaning that an assembly process is applied to tie together the different functionality areas at run-time of the software system’s execution by using interoperable standards. People performing the role of assemblers, need not have the technical skill than that of a component builder or assembler. It should be made safe to tie together various services to make up an application. A concept such as contracts can be used to ensure that services have the correct inputs, produce the appropriate outputs and are controlled by means of pre- and post conditional checks.

Figure 2: Separation continuum and product line realization

Component and object architectures form the nucleus of software execution. Product lines are realized where the abstract layers join the implementation layers – the focus of application assembly. The diagram above shows that there are two ways to realize product lines:

Top-down: The business model drives strategic initiatives from the top all the way to the implementation. All the interpretations of how the business systems must function are realized in the application portfolio specification. The platform implementation continuum needs to be flexible enough to respond to changes with quick turn-around times. This approach is used to prioritize the building of new services or the mining of existing potential services. An example might be that a customer portal requires a number of services to view and manage customer



portfolios. The functionality might already be available on existing platforms in legacy applications.

Bottom-up: The architectures already implemented either present enablers or inhibitors onto the business model. Web services is a good example of how business is affected – new means of realizing functionality quickly can facilitate new business products to be taken to market. Initiatives in this approach will normally be directed by specific technological challenges. Challenges might include complex application integration needs and central customer data management. The result of a typical bottom-up initiative might be a repository of software assets that cab be exposed as services.

3.2.2 Standards

The exposure and use of services are restricted by the types of technologies that can be used to assemble applications. Standards form an integral and important part of this paradigm.

The HTTP (Hyper Text Transfer Protocol) protocol that is used on the web today forms the basis of all forms of transfers. With the widespread usage and adoption it was a logical method to use to transfer even non-visual data like XML (Extensible Markup Language).

SOAP (Simple Object Access Protocol) provides a mechanism to provide structured and types information between piers in a decentralized environment using XML. SOAP messages can be sent to services for processing.

The UDDI (Universal Description, Discovery Integration) specification is for distributed web-based service registries. It essentially produces a way to publish and discover information about web services.

Web services can be described by using the WSDL (Web Services Description Language) format. It is an XML format for describing messages between web services that can be either document-oriented or procedure-oriented. WSDL is normally used in conjunction with SOAP 1.1, HTTP and MIME.

Process flow related standards are still under development and have limited implementation support. Development and implementation communities have shown interest in two particular standards namely WSFL [IBM] and ebXML [OASIS].

3.2.3 Producing a platform independent definition

In order to wire components and services, a flow language standard like WSDL is needed. There is a challenge in that flow can be used to define dialog sequencing, process flow, software component invocation and web service wiring. Another related issue is that these flow definitions need to describe both the build-time and run-time environments. Build-time requires a rich semantic in order to specify the total

functionality for either, components and services, or the way in which they will be invoked. Run-time requires the definition of dynamic flow such as user defined window sequencing or the changing of a process on the fly.

When taking all of these characteristics into account, the designer is concerned with having a complete and correct definition of the intended use of a particular feature. A combination of code generation and re-use of existing components can be used to construct the final run-time system with all its related deployment elements. This final product line is constructed and contains typically database definitions, software components, user interface designs, and related drivers for installation on a particular architecture.

3.3 Working with patterns

Assemblies can be used in many different processes and product lines. Application Portfolio level patterns are used to construct applications based on pre-defined and re-usable characteristics. Service and Web service patterns assist with the means by which these services are wired for both the user interface, process, and other forms of behavioural definition.

Essentially a patterns library is used to take previously acquired knowledge and apply it to the process of application assembly. The same issues apply as to the re-use of software components, in that if developers or system assemblers cannot get to the pattern it will not be used. This means that searching and locating patterns is a critical factor in the assembly process.

Patterns used during built-time are used to design and implement software features.

Patterns used during targeting or deployment time are used to produce the run-time application.

4. Discussion

A number of products have entered the domain of assembling software systems from Web services. The current focus is on Web services only, where this paper has shown that the assembly process needs to be extended into the area of assembling components, user interface sequencing, services, and possibly other constructs that make up a typical commercial software product.

The separation of business and technology has never been more relevant than now. Assembling systems from software assets (including Web services) that have been implemented in a variety of languages and architectures is the vision for application software provision. It opens an entirely new thread of discussion as to what software is available on an organizations infrastructure versus that of its software-as-service supplier.



5. References

[Constantinides] Constantinides C.A. Bader A. Elrad T.H. Fayed M. E. Netinand P. (2000). Designing an Aspect-Oriented Framework in an Object Oriented Environment. ACM Computing Surveys. March 2000.

[Doerr] Doerr B.S. and Sharp D.C. (2000). Freeing product line architectures from execution dependencies. Software product lines: Experience and research directions. Edited by Patrick Donohoe. Kluwer Press. ISBN 0-7923-7940-3.

[Dsouza] Dsouza D. (2001) Model-Driven Architecture opportunities and challenges. Kinetium. http://www.kinetium.com/

[Gartner] Gartner Research. (2001). Web services. http://www.gartner.com/

[IBM] Leymann F. (2001). Web Services Flow Language. IBM Software Group. WSFL 1.0.

[OASIS] Oasis. (2001). ebXML Business Process Specification Schema. www.ebxml.org/specs/ebBPSS.pdf.

[MDA] Architecture Board MDA Drafting Team. (2001). Model Driven Architecture a technical perspective. Document Number ab/2001-02-01.

[Moore] Moore G.A. (1998). The Gorilla Game, picking winners in high technology. Harper Business Press. ISBN 0-88730-957-7

Documents

AA using WS vanZyl 2002-05-06