 |
|
|
Abstract
This paper describes the results of a project funded by the Italian Government having as a primary goal the design of the network service architecture (called the Business Community Service Infrastructure, BCSI) for the transport operators located in the Port of Genoa. The BCSI Architecture presented in this paper takes advantages of XML and Web Services technologies and is specifically directed to a “Business Community” (BC), i.e. a Community of users that cooperate in the same business area. In particular the paper analyzes the structure and the requirements of a BC in general, derives the requirements of the BCSI and describes the BCSI Architecture technically. Finally a case study is presented to show how the BCSI has been an appropriate solution for the Business Community of the Port of Genoa.
Table of Contents
This paper describes the results of a project funded by the Italian Government[12] having as a primary goal the design of the network service architecture (called the Business Community Service Infrastructure, BCSI) for the transport operators located in the Port of Genoa. The project consortium included the University of Genoa (project coordinator), the Port Authority of Genoa, and several system integrators. The project was carried out according to the guidelines established by the Italian Authority for Informatics in Public Administration (AIPA).
The BCSI architecture is based on XML and Web Services[1] [2] technologies and is directed to a community of users that i) range from small professional offices to large companies, ii) already have mutual business relationships, iii) partially take advantage of proprietary network services iv) are coordinated by a local authority (the Port Authority). We call this community, which is an instance of the more general case of a community of heterogeneous and autonomous users tied together by a common business, a “Business Community”. Business Communities can be often found in complex business organizations and in the public administration.
The presentation focuses on the lessons learned from this project, and in particular on how i) to introduce the users to Web Services gradually, ii) to take advantage of the central role of the local authority to set up and maintain a Private UDDI Registry [5] for the community, iii) to integrate a Public Key Infrastructure [9] [10] with the Service Oriented Architecture to enable secure document and data interchange, iv) to support the migration from a centralized service provider scenario to a multi-provider scenario.
The case study demonstrates that these practices can lead to the definition of collaboration frameworks suitable to be adopted by “Business Communities”.
The application environment for this experience, which leaded to the definition of the infrastructure and related methodology that is the object of this paper, has been provided by a government-funded research project [12] targeted at the development of a communication system for the community of operators (enterprises, agencies, small companies, offices) of the Port of Genoa.
The business of the Operators of the Port of Genoa is the provisioning of logistic services (handling, management, transport, etc.) for maritime freight transport (Cargo). The system that supports the cooperation among the Port Operators is called Cargo Community System.
A good abstraction for such an environment can be provided by what we call the “Business Community” concept. A Business Community is a set of Business Operators (enterprises) that
Share a common market sector (like the cargo freight transport)
Hold different roles with respect to the given market sector (like maritime agencies, road transport operators, logistic service providers, etc.)
Have already existing commercial relations
Are coordinated by a Business Authority, who is generally an expert of the specific market (like the Port Authority, in our case)
We can find this type of organization in various contexts, for example in public administration and government, complex business organizations, etc.
The strength and the cohesion of the Business Community can take advantage of the existence of deployed network services that can improve the communications between Business Community Operators, exploiting common trading practices ruling the community and communications infrastructures enabling secure transactions.
This target can be achieved if the Business Operators and the Business Authorities participate to the Business Community with the following roles:
The Business Authority is in charge of maintaining the communication infrastructure that provides secure communication services, definitions and recommendations for application service implementations, and commonly agreed document exchange format for transactions, also capitalizing on its knowledge of the business sector
The Business Operators discover the definition of services and provide implementation of the services to the other operators, in a peer-to-peer fashion, conducting secure transactions over the secure communication services.
The approach we have followed is based on the emerging technologies and methodologies of Web Services in order to set up a secure collaboration infrastructure for a Business Community, the Business Community Service Infrastructure, and the accompanying methodology for deploying network services.
The Business Community Service Infrastructure (hereon BCSI) architecture requirements have been analyzed following a two-step methodology: the first step allowed identifying a set of Business Community (hereon BC) requirements, the second step allowed identifying a set of BCSI architecture requirements.
The following list presents the requirements of the Business Community Service Infrastructure, from the point of view of the Business Community Operators:
Pervasivity: all the BC partners should be able to use the BCSI independently of the characteristics of their infrastructures (e.g, network numbering, firewalling policies, etc.)
Distribution: the BC partners should be able to provide or access services in a distributed and multi-provider environment both for network services and application services, so that the BCSI cannot be a central node that provides connectivity and services to the partners.
Interoperability: all the BC partners should be able to integrate all the information systems of the other partners by means of the BSCI, independently of the base, middleware and application software adopted.
Openness: the BC partners should be able to easily interact with systems external to the Business Community.
Extensibility: the BC partners should be able to update the formats for data interchange and the protocols for software interoperability with rapid and low cost upgrades, even in presence of radical innovations in the application domains and in the technological scenarios.
Security: the BC partners should be able to exchange message or do transactions with guarantees of authenticity, integrity and secrecy
This step consisted of the mapping of the BC requirements on a set of BCSI Architecture requirements.
Requirements 1 - 4, Definition of Base Service: The BCSI architecture should rely on services that are available in all networks and operate across networks boundaries, independently of network types (i.e., Internet or Intranet), network configurations (e.g., Firewalling, Tunneling, NAT etc.) and network access (i.e., dial-up, always on). We anticipate that, according to this architecture requirement, Internet E-mail and Internet Web will be selected as base services, adopting SMTP and HTTP as transport protocols for all the services of the BCSI.
Requirement 5, Incremental Development and Deployment: The BCSI architecture should support services that can evolve from the Base Services to more sophisticated services in a graceful process. The evolution is graceful in the following aspects:
a) The evolution takes place in a appropriate time horizon
b) The evolution is such that more sophisticated services are based on the less sophisticated services, recursively up to the base services.
c) The user, who evolves along with the services and may slow down or speed up the evolution process, also controls the evolution.
d) Appropriate frameworks aid the evolution and tools that make the transition to more sophisticated tools as much natural as possible.
Requirement 6. Business Community Security Service : In addition to Base Services, the BCSI provides a Security Infrastructure managed by the authority of the BC
The system architecture must be the base for a communication infrastructure supporting the business collaboration between the different operators of the Business Community, as defined by the requirements. Our main architectural choice is to model the infrastructure as Service Oriented Architecture [4], but several recommendations and modifications to this model are needed due to the peculiarities of the Business Community, as explained in the following.
Service Oriented Architecture
The infrastructure is an instance of a Service Oriented Architecture [4] (SOA) that enables the provisioning and the consuming of Business Services (Web Services), providing tools and infrastructure services to the business community operators for specifying, publishing, finding and binding business services.
The following features of the Service Oriented Architecture, partially satisfying the requirements stated in the previous chapter, are the rationale for this architectural choice: ·
Integration of enterprise systems and collaboration using Internet wide transport protocols (HTTP/SMTP) (Pervasivity requirement) ·
Interoperability achieved by exploiting XML formats for document exchange and service access through SOAP protocol [3] (Interoperability, Openness and Extensibility requirements) ·
Registry-centric, distributed architecture adopting UDDI Registry [5] standard (Distribution requirement)
Private, “Business Authority” managed UDDI Registry
Leaving the task of publishing the services templates (interfaces) to the Business Community Operators could lead to the existence of functionally equivalent services with different interfaces, or to the existence of services that are not relevant or useful for the business community.
In other words, there is a need for a “harmonizing” actor who must be a domain expert (a “Business Authority”), who will be the responsible for publishing the services templates and who will run the Service Registry.
Different levels of technology and different User Access Points
Service Oriented Architectures (and all the tools and commercial platforms by now available) aim at supporting the deployment of Web Services, which can be considered the last steps of the evolution of deployed services. In other words, there is a need for a “stepwise”, incremental methodology in the deployment of services, as defined by the requirements, enabling the participation to the community of all the business operators, from the smallest offices to the largest companies (different User Access Points). In our case, it means that the deployment (publishing and adoption) of services must begin with simple, “base” services like free text Email message exchange and proceed towards Web Services.
Also, particular services must be identified which should be deployed in the middle of the evolution from base services to Web Services, and a methodology is needed to publish “software components” (like software plug-in modules) which can be downloaded by the operators and used in order to provide/consume the service. This particular services have been identified as XML Email Messages, and software components can be provided as plug-in components for popular email agents.
Security Infrastructure
Since the system is used by Business Community Operators to conduct business transactions, as placing purchase orders, security is a key factor for the effective use of such an infrastructure. In other words, there is a need for an authentication methodology, which can ensure identity between trading partners. Authentication is supported by a Certification Authority, providing support for Digital Signature[10] [11]and Public Key Infrastructure[9], which has been integrated with the Service Oriented Architecture.
The following figure shows the components of the Service Oriented Architecture, and their relationships, providing the infrastructure needed by the Business Community (Business Community Service Infrastructure).
Figure 2. Service Oriented Architecture for the Business Community (Business Community Service Infrastructure)
The key components of the architecture are the Service Registry, based on the UDDI Registry, and the Certification Authority [9].
The Service Registry is a Private UDDI Registry [5] managed by the Business Authority. The Registry is accessible by Community Operators either through the standard SOAP API [3] of the UDDI Registry, by external applications, or through a Web Front End (Operators Front End Web) by “human” operators
The Operators Front End Web provides functionalities to the Business Community Operators for ·
Applying for registration and for receiving a personal certificate from the Certification Authority; ·
Editing their own Operator Profile (the Registry UDDI Business Entity structure) containing specifications for their identities (“White Pages”), categories (“Yellow Pages”) and services provided (“Green Pages”);
Browsing and finding the other Community Operators profiles and the Services they provide;
The Business Community Registry is accessible by the Business Community Authority through a dedicated Front End Web (Authority Front End Web) that provides functionalities to the Business Authority for: ·
Publishing the services models (the UDDI tModel) ·
Managing the whole community profiles
The following figure describes the operation of the Business Community Service Infrastructure.
According to the previous picture, the following interactions take place:
The Business Community Authority publishes the services definition, like interface definition for Web Services and XML Schema [7]for XML document exchange, on the Business Community Registry.
The Business Operators join the Business Community asking for registration and receiving a Certificate for Digital Signature[10] provided by the Certification Authority.
The Business Operators provide an implementation for the services defined; the implementation can be speeded up, for certain type of services, by pre-deployed software components provided by the Authority as well.
Business Operators publish the implementation of a service on the Business Community Registry
Accessing the Business Community Registry, Business Operators can meet each other and discover provided services
Business Operators provide and consume services in a secure environment exploiting certificates provided by the Certification Authority for exchanging Email messages or accessing Web Sites or Web Services.
We will now describe how this system architecture supports an “incremental”, stepwise deployment of network services guided by the Business Community Authority (hereon, BC Authority), enables secure services access and document exchange and enhances the integration and cohesion of Business Community Operators (hereon BC Operators) at different User Access Points.
The first step of the Stepwise deployment enables the BC users to interact using Base Services (E-mail and WWW) providing a directory of contact information. As a consequence, the first deployment step consists of setting up a registration infrastructure and making BC users provide their E-mail addresses, other identity details and optionally some business information to populate the registration infrastructure. We notice that the set up of base services is not part of the first deployment step, but it is a precondition, as all the members of the community are supposed to have an Internet access acquired independently of the Business Community Authority. For this reason all the details below the Base Services are out of the scope of the BCSI architecture.
Architectural Support
The registration infrastructure is implemented using the UDDI Registry. In particular, the relevant information is defined by the contacts information (persons’ names, addresses, Email addresses, Web addresses) and category information of the operators, which can be contained in the Business Entity data structure of the UDDI Registry; technically speaking, the UDDI White Pages and Yellow Pages sections are used.
We notice that, in this first deployment step, the UDDI Registry plays a role usually assigned to simple LDAP servers. The adoption of the UDDI register is aimed at preserving the compatibility with the solutions deployed in the next steps.
In addition to the UDDI Registry, the security requirements are met by making the registration infrastructure generate and send a certificate request to the BC’s Certification Authority automatically. The CA, after the appropriate verifications, generates a certificate and sends it to the user. The certificate contains the owner's identity information and e-mail address that are stored in the UDDI Business Entity structure (the Operator’s profile). In addition, a copy of the certificate is made available in a LDAP server [9] of the Certification Authority and its LDAP URL is recorded in the UDDI Business Entity of the Operator.
The certificates are issued in this step for the following “key usage” parameters: ·
Non-Repudiation: this key usage enables BC partners to send E-mail messages signed in such a way that the sender cannot repudiate the authorship of the message content. ·
Data Encipherment: this key usage allows sending E-mail messages encrypted[11] in such a way that only who receives the E-mail can decrypt the message content. ·
Key Encipherment: this key usage allows setting up Secure Web Connections (HTTPS [11], i.e., HTTP over SSL) in which a secret session key is exchanged. The secure Web Connections allow doing secret transactions between authenticated peers.
User point of view
Getting an Internet access with an E-mail address and registering identity and E-mail address in the Registration infrastructure are the only user’s actions necessary to complete the first deployment step. In this first step all the operators can access the Business Community Registry through the Operators’ Web front-end that makes the following functions of the UDDI Registry available in Web pages: ·
Registration: allows the Operator becoming a member of the Business Community. When a user asks for registration by the Business Community Registry, an initial Operator Profile is generated (a UDDI Registry Business Entity structure) ·
Profile Editing: allows the Operator accessing his profile and fills in contact information to let the other Business Community Operators find him ·
Partner Search: allows the Operator browsing the Operators’ Web to find out the other Operators’ addresses
In this first deployment step, the user regards the BC as a community within which the interaction is easier and more secure with respect to the interaction with other Internet Users. Interaction means sending/receiving plain-text E-mail, optionally with attachments, or browsing/publishing web pages, looking up the appropriate addresses from a common repository.
As a consequence, in this first deployment step, each BC user accesses a web front-end of the UDDI registry and retrieves names, company names, E-mail address and Web Addresses of partners according to a standard classification.
In addition, when a user needs to send a secret message he/she can retrieve the certificate of the BC partners and install it in the E-mail client, using a LDAP client integrated in all the popular E-mail clients.
Deployment Issues
No definition of standard formats is required for the base services, since there is no format defined for the information exchange: this takes place only as an exchange of Email messages between Business Community participants.
The main role of the Business Community Authority, in this phase, is the management of the Certification Authority, that is the key component for the security enforcement in the communication between Business Community Operators, defining the CA policies (authentication strength, certificate validity duration, Revocation and Suspension mechanism etc.).
The deployment of "Standard Services" fills the gap between Base Services (exchange of Email messages in free text format, optionally signed and encrypted) and the deployment of Web Services.
This step is introduced to enable the participation to the Business Community of all the Operators who have not the necessary technological resources (or are not willing) to develop and deploy Web Services.
Standard Services have been defined as “Email messages carrying XML documents, optionally signed and encrypted”. The template of the XML documents (an XML Schema [7]) is defined by the Business Community Authority, on the basis of the specific business needs and type of documents used within the community (as commercial orders, invoices, commercial inquiries, etc.).
Each specific document exchange is a distinct type of service. So we will say that a BC Operator accepting “purchase order placement” in XML document format via Email (optionally signed or encrypted) is a provider of the “purchase order placement” Standard Service.
The deployment of Standard Services brings the following benefits to the Business Community Service Infrastructure: ·
It takes advantage of already deployed Base Services, of which Standard Services are actually an extension since Email messaging and Security Infrastructure are used. ·
It provides commonly agreed XML documents format, thus enhancing the cohesion and integration of the whole community. ·
It leaves the definition of XML document formats in the hands of a Business Authority, preventing a proliferation of different formats for the same type of document ·
It uses XML for the documents structure, allowing the exploitation of all the XML-related technologies and methodologies like XML Schema, validating parsers, editors and so on. ·
It enables the development and publishing of software components (like “plug-in” modules for popular email agents) which can be downloaded and used by Business Community Operators to compose and send the Email XML messages. ·
It provides the basis for further deployment of Web Services, which will take advantage of the already defined structure of XML Email messages to provide the WSDL description of Web Services interface.
Architectural Support
The system architecture, which has been developed for the Business Community Service Infrastructure, provides support for the publishing of the Standard Services by the B.C Authority and for their adoption (provisioning and using) by the BC Operators.
The BC Authority can publish the template for the Standard Services exploiting the tModel structure provided by the UDDI Registry. In our infrastructure architecture the BC Authority interacts with the UDDI registry through a Web Front End that provides the “Service Publishing” functionality.
The system architecture provides support to publish software components; these can be stored on a regular Web Server and the HTTP address at which the software component is located can be published using the UDDI registry “tModel” structure [5].
In this way, the BC Operators can access both the format of the XML document defined for the particular service and the “plug-in” module to create and send the document.
In order to publish a Standard Service, the BC Authority needs to perform the following actions:
Creating the XML Schema [7], which defines the structure of the XML document, needed for the specific service (e.g. a “purchase order” XML document for the “purchase order placement” standard service). The XML Schema is then published on a regular Web Server.
Publishing a tModel entity within the UDDI Registry (accessed through the Authority Front End Web) which reference the specific standard service (“order placement”); the tModel entity will contain a reference (HTTP address) to the XML Schema
Optionally, providing software “plug-in” to be downloaded by the Operators and installed on an Email agent (like MS Outlook™). The software plug-in, through the use of dialogs and graphic forms, is a helper tool for the Operator in order to compose or read the specific XML document. Software plug-in can be provided for different client email agents.
As a future work, it is planned that the Business Community Service Infrastructure will provide tools to develop and publish software plug-ins on the basis of the XML Schema, to be used by the BC Authority
User point of view
The following figure shows the interaction between a BC Operator, willing to provide or use a Standard Service, and the Business Community Service Registry
Figure 5. Interaction between Business Operators and Business Service Registry for using standard services
The BC Operator performs the following steps in order to provide a Standard Service (i.e. if the Operator accepts to receive business documents via Email compliant with the given XML Schema):
Browsing the Service Registry to find out which service he/she can provide. The selection of a Standard Service to be provided depends on the type of business the Operator is involved in, in particular it depends on the commercial category (UDDI Yellow Pages) the Operator belongs to (note that in a given Business Community the Operators may belong to different commercial categories).
Getting the available plug-in software provided by the BC Authority; alternatively, he/she can develop a software application sending/receiving Email messages carrying XML documents compliant with the XML Schema provided.
Updating the Operator’s Profile (UDDI Business Entity) in order to let the others BC Operators know about this fact.
Web Services deployment are the last step in the evolution of the Business Community. The final configuration is a community of enterprises maintaining commercial relationships, strongly linked together by a communication infrastructure, which allow them to interoperate directly connecting their enterprise information systems.
The first step of deployment is the publishing of Web Service interfaces, performed by the Business Community Authority. This step can be facilitated by the existence of already defined XML Schema for document exchange, which can be exploited for the definition of Web Services interfaces in WSDL (Web Services Description Language) [6].
The B.C: Operators will subsequently provide implementations of Web Services and will publish them on the Business Community Service Registry, exploiting the publication functionalities provided by the Operators Front End Web (User Profile Editing)
Architectural Support
Being centered on the exploitation of a UDDI Registry, the architecture proposed for the Business Community Service Infrastructure naturally provides support for Web Services deployment.
Several recommendations exist on how to integrate WSDL specification for Web Services within a UDDI registry [8]. Our proposal does not present specific differences: the WSDL interface document is stored in a regular Web Server and its HTTP URL is published by the BC Authority within the UDDI tModel structure.
Moreover, the BC Operators willing to provide Web Service implementation will make it explicit accessing their profile (the UDDI Business Entity) and providing the URL at which their Web Service implementation is accessible.
Deployment Issues
The BC Authority performs the publishing of a Web Service in the framework of the Business Community Service Infrastructure in the following steps:
The WSDL file is created by the B.C: Authority, possibly exploiting the previously defined XML Schema for standard services; the WSDL file is published on a regular Web Server at a given HTTP URL.
A tModel structure is created containing description of Web Services, the Commercial Categories of the Operators who may provide an implementation for the Web Service and the HTTP URL of the WSDL file describing the interface specification of the Web Service.
User point of view
The following figure shows the interaction between a BC Operator and the BC Service Registry to deploy and publish the implementation of a Web Service.
Figure 6. Interaction between Business Community Operator and Business Service Registry for the deployment of a Web Service
The BC Operator performs the following steps in order to provide a Web Service accessed by the other operators:
Browse the Business Community Service Registry to find the specification (provided by the BC Authority as the WSDL file) of a Web Service suitable to the needs of the operator. The selection of the Web Service which can be implemented is guided by several factors, as the commercial category the operator belongs to, the availability of internal procedures, the availability of a suitable internal information system, the willingness to disclose given parts of its own information processing system
Once found the WSDL description, the Web Service itself is developed by the BC Operator and deployed on a Web Services – enabled platform.
The Operator Profile is accessed and the details of the Web Service implementation, like the HTTP URL, are provided so that the other operators can be aware of it.
Both the architecture and the stepwise approach described in the previous sections has been experimented within a project funded by the Italian Government having as its primary goal the design of a BCSI (called the Cargo Community System, CCS) for the transport operators located in the Port of Genoa [12].
The Business Community considered for this project is made up of business operators involved in the cargo, logistic and transportation business within the area of the port of Genoa. We named this Business Community the Genoa Cargo Business Community (GCBC).
The GCBC is characterized by the presence of a public authority, the Genoa Port Authority (GPA), which is the natural candidate as the Business Community Authority previously defined and a large variety of different type of participants (large companies, public agencies, small and medium sized enterprises, professionals) some example of which are:
Shipping agencies
Terminal operators
Inland transport operators
Customs brokers and operators
Port Master's Office
Port fire department
In most cases these operators act as both service users and service providers. In fact the participants into the GCBC exchange services within the community since they usually take care of a single step within the chain of steps that constitute the transport process. Thus each operator of the GCBC provides services to other operators involved within the previous step of this chain and needs services from the next operator within this chain.
In addition to the service users and service providers of the community there is also a number of potential users (e.g. business operators which needs to send or receive goods, transport business operators in different geographic areas) and potential providers of services (e.g. bank and assurance companies, central government agencies) external to the community.
The system deployed within the CCS follows the architecture described in section 4. Table 1 reports the commercial components of the platform that has been used.
Table 1.
| Component | Product |
|---|---|
| Certification Authority | Baltimore UNICERT 3.5 |
| LDAP Server | Netscape iPlanet 2.4 |
| Application Server | Apache Tomcat 3.2 |
| UDDI Registry | IBM UDDI Registry Beta |
| Web Services Deployment Tools | IBM Web Services Toolkit |
| Client Plug-in | MS Outlook™ (COM Addin) |
| Client Smartcard | Schlumberger Cryptflex |
Within this framework along with new type of services have been included several services already developed by a few providers also on behalf of the Genoa Port Authority:·
Cargo Manifest management
Customs Tariffs
Customs document exchange
Hybrid Mail services
As a stepwise deployment case study this section presents the customs document exchange service. The exchange of documents describing a set of goods being imported or exported is part of the import/export procedures that must be completed in order to send or receive goods. A service supporting this procedure allows the freight forwarders to send the customs documents electronically from their offices to the Customs Department and to obtain the acknowledgement of receipt and the response document from the Customs Department.
This raw service is presently offered by the Customs Department, that is an operator external to the GCBC, as a simple file transfer service based on the FTP protocol and available on a private access network based on the X.25 Italian public network (ITAPAC).
Therefore the raw service does not meet the user requirements because: ·
The user interface is based on command line user interaction with no connection to office automation tools. ·
The X.25 access network is not widely available ·
The user support is poor (very limited call centre, no information about service health and performances, only manual transaction monitoring)
To meet the user requirements within the CCS this raw service has been deployed in the Business Community Service Infrastructure. The first deployment step included
the set up of an application gateway that allows operators to send proprietary EDI formatted documents (see figure 7a) through a standard Web interface based on HTTPS (the Base Service), and
the publication of the service implementation on the Business Community Registry.
The second deployment step included
the definition of a XML Schema that describes the customs documents (see figure 7b) and its publication on the Business Community Registry, under the responsibility of the Port Authority.
the set up of a XML plug on the client side and of a XML parser on the server side for the editing and the processing of the documents, under the responsibility of the Service Provider.
the publication of the service implementation on the Business Community Registry and of the downloadable plug-ins, under the responsibility of the Service Provider.
The third and final deployment step included:
the definition of a WDSL document that describes the customs document exchange Web Service API, and its publication on the Business Community Registry, under the responsibility of the Port Authority
the set up of the Web Service under the responsibility of the Service Provider that receives SOAP requests that include the custom document in XML format (see figure 7b) over HTTP/HTTPS.
the publication of the service implementation on the Business Community Registry under the responsibility of the Service Provider
the development of the Web Service client components integrated in the Web Service user’s information system, under the responsibility of third parties.
The first and the second step of the deployment has involved 80 users of the GCBC and supported more than 130.000 transactions.
The paper described the results of a pilot project aimed at deploying the Web Service technologies in Business Communities. The main contributions of the work presented include i) the Business Community requirement analysis, ii) the set up of a deployment methodology based on a graceful approach called “stepwise deployment”, iii) the design of a infrastructure based on Service Oriented Architecture specifically tuned for Business Communities and organized in such a way to support the stepwise deployment.
The lessons learned from this experience do not only cover technological results, but they are also related business and services organization, defining the concepts of Business Community and Business Community Service Infrastructure; the BCSI will support the deployment, provisioning and consuming of services by all the members of the community, in a peer-to-peer and decentralized way, rather than providing centralized service implementation.
The results of this project have been validated, both from a technological and business point of view, through the set up of a pilot system in the Business Community of the Port of Genoa.
[1] Web Services Architecture Overview, IBM Web Services Architecture Team, September 2000 http://www-106.ibm.com/developerworks/webservices/library/w-ovr/?dwzone=webservices
[2] W3 Consortium Web Services Initiative http://www.w3.org/2002/ws/
[3] SOAP Version 1.2 Part 0: Primer, W3C Working Draft December 17 2001 http://www.w3.org/TR/2001/WD-soap12-part0-20011217/
[4] The Tao of e-business services , Steve Burbeck, October 2000 http://www-106.ibm.com/developerworks/library/ws-tao/index.html
[5] UDDI Universal Description Discovery and Integration, The UDDI Community, http://www.uddi.org
[6] Web Services Description Language WSDL 1.1, W3C Note March 15 2001, http://www.w3.org/TR/wsdl
[7] XML Schema Part 0: Primer, W3C Recommendation, May 2 2001, http://www.w3.org/TR/xmlschema-0/
[8] Using WSDL in a UDDI Registry 1.05, UDDI Working Draft Best Practice Document, June 25 2001, http://www.uddi.org/pubs/wsdlbestpractices-V1.05-Open-20010625.pdf
  |
Design & Development by deepX Ltd. 2002 |
