Towards a Framework for the Design of High Quality Web Services

Mark Nolan, Business Analyst, Application Maintenance Services, IBM Australia, Melbourne, 3000. Email: mnolan@au1.ibm.com

B. Srinivasan,Professor, School of Computer Science and Software Engineering, Monash University, Email: Bala.Srinivasan@infotech.monash.edu.au

Abstract

Web Service Description Language (WSDL) supports services with single or multiple operations. An operation performs an aspect of business functionality that a service producer wishes to externalise to a service consumer. An operation may be synchronous or asynchronous and standalone or choreographed as part of a larger business process. The complexity and size of the business process exposed is left to the discretion of the business subject matter experts and the application architects.

The overall quality of a business process is determined by both the sum of the qualities of the individual web service operations and is constrained by the performance of the weakest operation in that process. A high quality experience for a web service consumer is provided when both the overall business process and each individual web service operation meets its functional and non functional requirements and easily implementable by service consumers. In this paper, we provide a set of good design criteria that are applicable to both the overall business process and individual web service operations.

In this section we describe the service layer used to define web services. In section 2 we describe service oriented development methodologies that include processes for developing web services. In section 3 we define our design criteria and describe how service oriented methodologies and processes can be used to verify these criteria have been included in the web services output from the service layer. Finally, we conclude and present areas for future work.

Service Oriented Computing espouses the following major objectives 1) promote and simplify interoperability (AG001 Interoperability - Web Services Architecture Requirements[2004]) and more recently 2) has been seen as a major vehicle to promote intra organisational reuse [Benetallah (2004)]. Intra organisational reuse involves the standardisation and documentation of web services for use between a companies organisational units as opposed to the more conventional use of web services in a B2B scenario. Both interoperability and intra organisational reuse share similar requirements. These include the requirement for 1) reuse of existing organisational infrastructure with no reliance on new or proprietary infrastucture and 2) the documentation of both the syntactic and semantic nature of the interfaces.

Service oriented computing achieves the goal of minimal infrastructure through the use of HTTP and XML. The documentation requirement is met though the use of UDDI which can serve as a repository for interface definitions. There are a number of other less widely adopted standards which will eventually further enhance the documentation of interfaces such as OWL-S and extensions to UDDI and BPEL which describe both QoS and service choreography requirements. Current middleware does not appear to have to completely met the above goals as interfaces using conventional middleware often lack transactional, security and workflow functionality as well as being constrained to either Java or Microsoft platforms.

Separation of concern continues to be a major principle in the design of IT systems. There is a current realisation that Service Oriented Computing provides the opportunity to allow for a further level of abstraction [Booch(2004)]. This new layer is described as the service layer. By organising a solution into discrete levels, designers are able to focus on a single aspect of the solution while ignoring all remaining complexities. Once they stabilise that part of the solution, they can then proceed to other aspects, continuously evolving and refining the layers into a cohesive model, one that can ultimately be implemented [Awalt and McUmber (2004)].

A new layer of abstractions allows designers to concentrate on the aspects of the solution specific to the problems of that layer. Specifically the service layer allows designers to map legacy system components to the web services required to implement identified business processes. Web services may also be composed, choreographed and further extended to include quality of service functionality. Given the acceptance of a new level of abstraction, then design methodologies will need to be enhanced to provide new modelling artefacts. These artefacts will also be subject to new design methods. Design and development tools can then be extended to perform designs for the service layer as well as providing translation from the business process layer to the component layer.

The service layer or the service level relates to Web Services and is specifically intended to promote the externalisation of existing application resources. The service layer is intended to expose internal functionality using bottom up design with the aim of standardising interfaces and orchestrating the use of existing components. The services layer must meld with the higher layers of the IT solution definition framework. The use of top down design methods are not as relevant in a service oriented environment as service providers (solution producers) can not be completely sure of how solution consumers will use services and what their high level requirements are.

Next we describe a service model provided by Benetallah(2004) which is based on WS*Standards and further defines the service layer whose major output in the design process is web services. Benetallah’s model defines the major elements of the service layer that contribute to the design of the web services. Our proposed design criteria will influence the design decisions used to construct these various objects with the aim of creating high quality web services.

Figure 1 depicts Benetallahs Web Services Layers of Abstraction [Benetallah(2004)]. The web services standards associated to each layer are also defined. The layers are described as follows:

The policy layer defines service protocols and policies and is a new dimension of interoperability attributable to service oriented computing. Artefacts at this level need implicit information concerning the processing of business transactions as in closed environments to be made explicit. This includes specifying the order of messages, for example, a purchase message must occur after a login message. Transactional policies such as, can I cancel a purchase?, must be made stated. The temporal aspects of the business processes must also be specified, for example, can I cancel a purchase any time? Security policies must be identified and privacy policies must be agreed between parties, such as, will the results be digitally signed?

Other policy areas to be negotiated include:

• Quality of service
• Exception Handling
• Compliance and Monitoring
• Compatibility: Does the assurances of the provider satisfy the requirements of a client?
• Change management
• Federated Identity Management

After discovering a matching service (e.g., using a public or a private registry), Parties A and B need to agree on the joint business process (activities, delivery mode, etc.) and interaction contracts (security, privacy policies, QoS, etc.) This involves defining the semantics of interactions (joint business processes) whereby partners must agree on the choreography of interactions and the meaning of the messages. For example, the steps and their order (send order, process order, deliver product) and the contractual implications (a purchase is refundable after 2 days).

The semantics of interactions must be well defined, such that there is no ambiguity as to: What a message may mean? What actions are allowed? What responses are expected? For example, if a company requires an acknowledgement of purchase orders from its partners.

Content Layer

Deals with the message structure and the semantics of messages exchanged. Partners must understand the structure and semantics of messages, for example, does a document represent a purchase order? or, A request for a quote?, or a, A product description?

The structure may include diverse information formats, such as, XML schemas, text (e.g., different structures for a purchase order), services may provide the same functionality but with different operation structures (e.g., different names, different signatures). Semantics include issues such as, does a service provide the required functionality?, and, does Price mean Price including tax?

There must be a way to communicate the messages that contain requests/business documents between Parties. Issues to be defined include:

1. SOAP encoding style
2. RPC or Message Oriented communication paradigm
3. Transport protocol to be used such as, FTP, HTTP or SMTP
4. Encryption standard
5. Security protocols
6. Addressing standards

The addition of a new layer of abstraction, the services layer requires changes to current development methodologies. The major function of a system development methodology is to apply documented processes to the inputs of one abstract layer to create outputs for input into another layer. It is even better when these processes can be automated, such as the case with tools that can both forward and reverse engineer. When outputs are produced, they must then be verified for correctness and quality.

There are two main mechanisms widely used to check correctness and quality, the most common being the subjective process of peer review of artefacts resulting from system development methods and processes. Also, less commonly the automated process of using utilities which check for syntactic correctness and are less often able to measure semantic correctness and quality. In section 3 WS Design Criteria, we propose quality criteria and define the currently available mechanisms for verifying output from the services layer. There is still a large amount of work to be done to automate and verify the production of service layer artefacts. The following sections describe two current Systems Development Methodologies that lead to the creation of web services.

System design methodologies traditionally have been either Top Down such as those originally proposed at IBM and refined by Yourdon, Constantine and DeMarco in the 70’s and 80’s or Bottom Up as proposed by Freeman and Wasserman and others. Current approaches use Meet In The Middle techniques due to the need to minimise cost from reuse and to allow development and design tasks to be performed in parallel. The Co-Design methodology proposed by Thalhiem(2004) has created a meet in the middle approach which will reduce development time by performing analysis, design and programming in parallel. The meet in the middle approach encourages reuse. Khoury and Simoff(2004) further aid this approach using their concept of Elastic Metaphors which uses a common design element throughout all stages of the SDLC reducing semantic impendence mismatch between artefacts produced during different phases.

A number of web service design methods are also becoming available which embody the meet in the middle approach. In the following sections we describe two examples of web service design methodologies, one which extends the traditional object oriented methodology to include a service layer and associated processes known as Representational State Transfer (REST). The second is a new method built specifically for web services design by IBM known as Service-oriented Modeling and Architecture (SOMA). In section 3 WS Design Criteria, we show how these methodologies can aid service oriented design to create web service artefacts that meet our proposed quality criteria.

According to [Snell(2004)] the difference between REST-style and SOAP-style Web services depends on whether or not an application is resource-oriented or activity-oriented. Resource-oriented services are fine grained and focus on distinct data objects upon which a handful of basic, standard type specific operations can be performed. The service provider maintains a collection of resources and exposes type specific operations to perform such tasks as:

• Retrieving the resources
• Modifying the resources
• Creating new resources
• Deleting resources

They then identify and locate resources by a Universal Resource Identifier (URI), and the operations that might be performed against those resources are defined by the HTTP specification. The core operations include:

• GET - This operation returns a state representation of the identified resource. You can determine the state by a number of contextual factors such as who is submitting the request, the parameters of the operation (passed in as either HTTP headers or query string parameters), and current session state maintained by the service provider.
• POST - This operation performs some form of application-specific update to the identified resource. The behaviour of this operation is completely up to the service implementing it. The data returned by this operation is also completely up to the application. It could, for instance, return a state representation, as does the GET operation, or it could choose to not return any data at all beyond the standard and required HTTP response.
• PUT - This operation creates a new resource at an identified location (URI). The operation input must include a state representation of the resource. It is up to the service to create a resource based on that state representation.
• DELETE - The DELETE operation destroys a resource at the identified location (URI).

In each of these cases, the design of the service interface allows the service consumer to move information about resources around, leaving it up to the consumer to decide what to do with that information. The service producer is easily able to define all relevant resources and the associated type oriented actions to be performed on those resources for an application ensuring a complete and essentially self describing coverage. A major issue with this approach may occur when there are a large number of resources with complex interaction between them. The choreography requirements will be difficult to describe and there will generally be a need for state information. In this case, the business object level fine grained services may need to be packaged up into activity oriented BPEL controlled large grained, statefull services.

Alternatively, web services may be activity-oriented. These types of applications focus on actions that you might perform rather than on the resources upon which they act. A simple example of an activity service would be a bank transaction in which a customer transfers money from one account to another. The customer doesn't want to work with the resources directly (the money, the bank accounts, and so forth), they merely want to tell the bank what it is they want to accomplish and have the bank handle the resources on their behalf.

SOAP-style Web services are generally activity-oriented. The WSDL document defines and describes service-specific operations. Operations consist of an exchange of service-specific messages. Each operation is an activity that might be performed. What those operations are being performed against is generally irrelevant. Resources are implied in the activity, as described by the WS-Resource Framework family of specifications, but such implication is independent of the definition of the activity and serves only to refine the context within which the activity is performed.

Experience from the early implementation of Service-Oriented Architecture (SOA) projects [Zimmermann, O., Krogdahl, P. and Gee, C. (2004)] suggest that existing development processes and notations such as Object-Oriented Analysis and Design (OOAD), Enterprise Architecture (EA) frameworks, and Business Process Modeling (BPM) only cover part of what is required to support the architectural patterns currently emerging under the SOA umbrella. Thus, there is a need for an enhanced, interdisciplinary service modelling approach which SOMA is attempting to capture.

Figure 2, shows the layers of abstraction required for service oriented computing [Arsanjani, A. (2004)]. The definitions, artefacts and design process relating to the business process and component layers are well defined. New design principles, artefacts and methodologies are defined for the service layer to produce artefacts (including a Service Model) which apply good design principles in SOMA. The layers are described below:

1. Operational Systems Layer contains existing systems or applications including existing CRM and ERP packaged applications, legacy applications and "older" object-oriented system implementations as well as business intelligence applications. The composite layered architecture of an SOA can leverage existing systems, integrate them using service-oriented integration.

2. Component Layer that uses container–based technologies such as EJBs or COM+ objects and creates designs used in typical component-based development.

3. Service Layer business unit specific components and in some cases project specific components and provides services through their interfaces. The interfaces get exported out as service descriptions in this layer, where services exist in isolation or as composite services.

4. Service composition into flows or choreographies of services bundled into a flow to act as an application. These applications support specific use-cases and business processes. Here, visual flow composition tools such as WebSphere WBI-Modeler or Biztalk can be used for design of application flow.

5. Presentation layer is defined using some recent standards such as Web Services for remote Portlets version 2.0, UIML or WS-TIA may indeed leverage Web Services at the application interface or presentation level. It is also important to note that SOA decouples the user interface from the components.

6. Integration Architecture enables the integration of services through the introduction of a reliable and intelligent routing, protocol mediation, and other transformation mechanisms often described as the Enterprise Service Bus.

7. Quality of service through sense-and–respond mechanisms and tools that monitor the health of SOA applications, including the all important standards implementations of WS-Management.

The systems development methods applied to each layer are described below.

• Domain. (Not depicted in Figure 2) use Domain Analysis (or Domain Engineering) including
• Functional Areas grouping
• Variability-Oriented Analysis 
• Project vision. (Not depicted in Figure 2) use Business Performance Modelling.
• Business process. use Business Process Models to understand the series of sequentially organised business activities, events that trigger them, roles that perform them, inputs, outputs, control points, etc.
• Align Services with Business Goals
• Detailed requirements. use Process Modeling, Component-Based Development (CBD), Object-Oriented Analysis and Design (OOAD), and Use Case Modelling.

Web service design has become an important topic for both application builders and software vendors. Industry is migrating away from developing monolithic applications and towards providing a dynamically re-configurable set of services that fulfil an application via service oriented architecture. For software vendors the battleground has moved from operating systems to middleware. Middleware is subject to a range of innovations mainly in the area of web services standards and use. In this section we describe some web service design principles which allow us to define the desirable properties of a web service and, any design constraints and their effects. We also describe the current mechanisms available to verify these qualities are contained in a web service.

Benetallah(2004) states that the quality of a web service is determined by 2 factors, specifically it must be, 1) useful, whereby it performs relevant business functionality and 2) useable, in that it allows itself to be readily and simply invoked. These two criteria are most easily judged after the design phase during the production phase of the web service application. Furthermore, a web service may not be useful or useable in its own right even though it may be functionally sound. This may because a web service relies on other web services to provide reference data or state information. For some unplanned or uncommon interactions, this prerequisite information may not be available. It would be beneficial if we could further refine the useful and useable criteria to produce an alternative set of more finely grained criteria which could be used during the design process that we know will produce web services which in their production phase will be both useful and useable.

The elements which define general software quality such as McCalls [McCall et al (1977)] Quality Metrics listed below must be included in our web services quality criteria:

The FURPS Metric[Grady and Caswell(1987)] is another quality model and is an acronym for:

Functionality - evaluate the feature set and capabilities of the program, the generality of the functions delivered and the security of the overall system

Usability - consider human factors, overall aesthetics, consistency, and documentation

Reliability - measure the frequency and severity of failure, the accuracy of outputs, the ability to recover from failure, and the predictability of failure

Performance - measure the processing speed, response time, resource consumption, throughput and efficiency

Supportability - measure the maintainability, testability, configurability and ease of installation

We have developed our own design criteria specific to web services because many of the metrics described above have an emphasis on certain development phases and are often difficult to collect information on. It is also hard to get agreement on measures of software quality as there are diverse opinions on the relationship between metrics and eventual quality. Our design criteria are defined along with some mechanisms available to verify them.

Ejiogu (1997) recommends the following Attributes of Effective Metrics for both the derived metrics and the contributing measurements:

• simple and computable - easy to learn how to gather the data.
• empirically and intuitively persuasive - satisfies an engineer’s intuitive notions
• consistent and objective - unambiguous results not dependent on the observer’s involvement
• consistent use of units and dimensions - avoid arbitrarily mixing unnatural measurements through dimensional analysis
• programming language independent - based on the model, not the language
• effective mechanism for quality feedback - provide information for correcting quality problems

We categorise web service design criteria as either mandatory, those that must definitely be met in order to produce high quality fit for purpose web services or, optional, nice to have, those that will help make a web service more easily used. Our classification of mandatory versus optional is largely based on our definition of what web services are? We define web services as required to use XML for message definition. A web service must not create any barriers to interoperability and must support common transport technologies, at a minimum, HTTP with standards based message formats. Optionally, a web service should reduce impedance mismatch by close alignment of both functional and technical specification and implementation. The mandatory web service design criteria include:

• functionally complete, cohesive and consistent coverage – a web service must perform all required functionality in a consistent manner with related web services and operations for that application or domain. In order to be fully and flexibly choreographed each web service must have an associated compensatory operation or must support the ACID properties. Web services are proven to provide complete functionality if all schema entities and classes are potentially updatable and all required business objects and components are callable from the web service. The REST methodology ensures completeness by listing all resources and operations for each resource to allow application designers to simply check for a complete coverage. SOMA suggests the use of Component Based Modelling in order to capture all the functionality provided by legacy applications. A web service is cohesive with other web services of an application when it provides required reference or state information in a timely fashion.
• implementation of all mandatory policy assertions for example, QoS requirements such as choreography, transactional, security, privacy, reliability and metering must be met. This is proven by the inclusion of sufficient information detailing the QoS functionality provided by a web service in a design pattern definition or described by the UDDI or WSDL containing policy information describing the service. The alignment of policy requirements with design and implementation should be peer reviewed to ensure service consumer expectations are met.
• interoperable – support common industry protocols, platforms and languages, defined via a published well defined interface, open standards for data encoding, discovery, and description, use common data encoding and decoding schemes, defined semantics for the particular application context. Interoperability should be verified using cross industry supported test suites such as those provided by the Web Services Interoperability (WS-I) Organization Basic Profile Version 1 for web services and related standards. Standards alone do no guarantee interoperability and therefore must be verified by the use of utilities such as those provided by WS-I.
• performance – a web service must be capable of meeting its service level criteria with regard to response time and throughput expectations. A set of benchmarks will need to be developed by the standards bodies with test harnesses to allow service producers to do performance testing and subsequent publishing of performance results. The use of caching to promote efficient transactions and to aid with scalability will improve performance. The performance of a web service may be defined by the response time requirements of either an individual service or a compound set of services that comprise a business process. If response time requirements are not met then it may be possible to restructure a web service to increase granularity and to reduce the number of interactions in the business process. Optimistic concurrency control techniques may be used to validate stable data to ensure that reference data is still current.
• channel agnostic and device independence whereby the web services do not have any knowledge of the channel they are called from or where they get information from.
• longevity and backward compatibility – service consumers require stability of the web services which have been included in their applications. This includes both the structural component and semantics of web services. Any changes must leave new versions of the web service backward compatible with previous versions. It is not acceptable to create new web services that essentially repackage and marginally increase the amount the functionality performed by existing web services. Backward compatibility should be tested for by the service producer. Generic WSDL should be used instead of specific WSDL. For example, there is a trade off between using XML validation to check very type specific data structures and the need to constantly update that structure every time a new type is introduced.
• autonomous – a web service should not require data, policies or web services outside of its sphere of control.
• A web service should not have to make decisions regarding its orchestration to forward to another web service.

Nice to have web service design principals include:

• dynamic discovery – a web service should be described in a UDDI directory.
• flexible and agile – a web service should be easy to extend. Possible to orchestrate with one of more other web services and possible to combine with one or more web services to create composite web services.
• ability to negotiate - a web service should be designed in such a way that the service consumer can negotiate input and output message structure and encoding style, granularity, transactional properties, QoS, ordering, acknowledgement and priority requirements. Clients should be provided with their own view of a web service.
• meaningful – the functionality that is provided by a web service should be meaningful in the context of the application.
• naming is understandable – the name of the web service should reflect the functionality performed by that web service.
• stateless – web services should be stateless so as to remove the overheads of caching. Stateless web services can be called in any order and if a service producer already has the information required by a web service in a business process then the rederivation of this information can be skipped altogether. Also current implementations of Business Process Execution Language (BPEL) do not support long running processes very well. Business Processes which call a large number of web services require many compensatory paths which are difficult to specify and equally difficult to implement. Alternately, web services may need to be stateful to stop the need for passing previously processed state information which requires revalidation.
• the web services of an application should be based on the same architectural style and design patterns.
• extensibility - add new functionality without effecting backward compatibility
• granularity – in order to reduce the number of messages a web service should be a large grained as possible in order to minimise the number of interactions. This will reduce the number of round trips and improve overall response time of a business process. Large numbers of data capture invocations are not acceptable. Useability principles also require errors to be captured on the current screen and so packaging up input from a number of screens to perform server side validation in one exchange is generally unacceptable. Granularity should be configurable by the service consumer. For example, a parameter should be set to allow the return of a single postcode and suburb combination for a single address capture service or to return a large number of postcodes for a number of input suburbs in one invocation of the same service. The large grained service may be used in the creation of a list of valid postcode and suburb combinations to be used with address capture services at a later time.
• web services should not contain any system, process or state information to be passed with input client data required by an operation.
• design to maximise reuse – any service that could potentially be used as a stand alone web service should be exposed as we can always combine web services using BPEL to extend functionality.
• traceable – the web services should be traceable back to the original business goal and related functional requirements.
• Identified as generic or domain specific – if a web service is generic to the organisations business processes then it should be identified as such in the service model.
• based on domain standard xsds or schemas where possible such as eTOM (enhanced Telecom Operations Map) for the telecommunications industry
• transactional - although this criteria is a part of the QoS criteria, individual web services should be transactional and where possible be associated with compensatory counterparts if required.
• explicit well defined and published policies – the web services need to be based on published policies which should be open to negotiation.
• context aware return only data relevant to the environment that the web service is operating in.
• published – placed in a UDDI directory
• maximises the overlap between the business and technical perspective’s of an application, that is, business processes should be comprised of business activities which should closely align with implemented web services. From a business requirements view Service Oriented Computing is a good paradigm because it removes impedance mismatch from functional requirements to technical implementation. This helps verify that developers have implemented the functional requirements if the technical specification is similarly structured and can be freed of platform specific detail. Both architectural methods and toolsets should reflect this new approach.
• Small footprint – web service messages that transport device display formatting information are to be avoided. There are technologies available to format output such as XSLT and the overhead of transporting this information can be enormous and lead to response time issues.

In presenting these good design criteria we acknowledge that not all are achievable given the current maturity of the service oriented environment. A major limitation of web services at present is the immaturity of a number of the web service standards and their implementation such as the support for security, service definition, transactional properties and process choreography and its implementation in BPEL. It may not be possible to meet a security QoS requirement due deficiencies in either the WS-Security standard or the implementation of that standard in security related products. BPEL currently only supports the orchestration of web services and does not provide full workflow capabilities such as controlling other objects like screen interaction. Workarounds to allow BPEL to pass the name of the screen to be presented are currently hand crafted by development projects. This makes it difficult to link user interfaces to a business process and its goals in order to aid requirements traceability. On a positive note, although current implementations of BPEL are immature, the ability of BPEL to orchestrate a number of web services into a composite web service allows us to change granularity and to even expose the web services of a business process at different granularities. Web services are able to store state information in the context area of the web server which overcomes any limitations with state.

In this paper we have presented some design criteria to judge the quality of web services. We have described some current means by which these criteria can be used to verify that a web service is both useful and useable.

Our next task will be to place our design criteria against the tiers in Benetallahs(2004) service layered model with the aim of learning which of the WS standards effect which elements of web service design. We will also describe how to use these WS design criteria in a number of ways to improve web service design.

1. We will create some modifications to patterns languages to hold these criteria as simple metrics.
2. We will describe how to use these metrics to judge the quality and suitability of various e-business patterns.
3. We then show how these criteria are used to judge the quality of a web service created from one of the e-business pattern templates.

Arsanjani, A. (2004) Introduction to Service-Oriented Modeling and Architecture (SOMA) Presentation

Awalt, D. and McUmber, R. (2004) Secrets of Great Architects July 2004 accessed from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmaj/html/greatarchitect.asp

Benetallah, B. (2004) Service-Oriented Computing Oppurtunities and Challenges accessed from http://socsig.csse.monash.edu.au/Socsigweb/Portals/0/SOCSIG-Boualem-keynote.pdf

Booch, G. (2004) IBM's Grady Booch on solving complexity. Big Blue Fellow talks about grid computing, the future of middleware, and working with IBM Research accessed from http://www.infoworld.com/article/04/02/02/HNboochint_1.html February 02, 2004

Ejiogu, L. O. (1997) On Dimishing the Vibrant Confusion In Software Metrics. SIGPLAN Notices 32(2): 35-38

Grady, R. and Caswell, D., Software Metrics: Establishing a Company-Wide Program, Prentice Hall, 1987

Khoury, G. and Simoff, S (2004) Enterprise Architecture Modelling Using Elastic Metaphors in Proceedings of the first Asian-Pacific conference on Conceptual modelling - Volume 31 Dunedin, New Zealand Pages: 65 - 69 2004

McCall, J.A., Richards, P.K., and G.F. Walters (1977), "Factors in Software Quality," Rome Air Defense Center Technical Report RADC-TR-77-369, Vols. 1 - 3.

Snell, J. M (2004) A quick look at the relationship of REST-style and SOAP-style Web services 12 Oct 2004 accessed at http://www-106.ibm.com/developerworks/webservices/library/ws-restvsoap/

Thalhiem, B. (2004) Co-design of structuring, functionality, distribution, and interactivity for information systems Proceedings of the first Asian-Pacific conference on Conceptual modelling - Volume 31 Dunedin, New Zealand Pages: 3 - 12 2004

Web Services Architecture Requirements W3C Working Group Note 11 February 2004 http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211/

Web Services Interoperability Organization Basic Profile Version 1[http://www.ws-i.org] Accessed August 2003.

Zimmermann, O., Krogdahl, P. and Gee, C. (2004) Elements of Service-Oriented Analysis and Design Access at http://www-106.ibm.com/developerworks/webservices

Copyright

Mark Nolan and Bala Srinivasan, © 2005. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant anon-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.