ABBA : معماری برای استقرار برنامه های کاربردی تجارت الکترونیک B2B
|کد مقاله||سال انتشار||تعداد صفحات مقاله انگلیسی||ترجمه فارسی|
|3406||2004||13 صفحه PDF||سفارش دهید|
نسخه انگلیسی مقاله همین الان قابل دانلود است.
هزینه ترجمه مقاله بر اساس تعداد کلمات مقاله انگلیسی محاسبه می شود.
این مقاله تقریباً شامل 9852 کلمه می باشد.
هزینه ترجمه مقاله توسط مترجمان با تجربه، طبق جدول زیر محاسبه می شود:
- تولید محتوا با مقالات ISI برای سایت یا وبلاگ شما
- تولید محتوا با مقالات ISI برای کتاب شما
- تولید محتوا با مقالات ISI برای نشریه یا رسانه شما
پیشنهاد می کنیم کیفیت محتوای سایت خود را با استفاده از منابع علمی، افزایش دهید.
Publisher : Elsevier - Science Direct (الزویر - ساینس دایرکت)
Journal : Electronic Commerce Research and Applications, Volume 3, Issue 2, Summer 2004, Pages 190–212
An efficient design process for developing B2B EC applications is critical for numerous reasons, namely: (i) the complexity and the growth of this category of EC, (ii) its differences from other categories in many aspects, and (iii) the number of existing approaches and standards causing confusion to enterprises willing to deploy B2B EC applications. In this paper, we first analyze and compare existing architectures, reference models, approaches, standards and languages used to deploy B2B EC applications. In the light of this analysis and a specification of B2B EC requirements, we propose ABBA, a comprehensive architecture, and a corresponding design process. ABBA is a layered architecture with four interfaced abstraction levels: business model and business process, business process decomposition and distribution, supporting services, and integration technology. ABBA aims at making a common view of the business process independent from the implementing technology, and providing guidelines for a design process to develop comprehensive, interoperable and scalable B2B EC applications.
Electronic commerce (EC) is the ability to conduct business transactions via respective services and protocols (e.g., WWW, EDI, XML, HTTP and SOAP) of the Internet and VAN (Value Added Networks). EC is generally broken down into categories depending on the roles of the actors (e.g., business, customer, administration and employee). The well-known categories are business-to-consumer (B2C), which is selling goods and services directly to consumers; and business-to-business (B2B) which is related to businesses selling goods and services to other businesses. Regardless of its category, the value of EC is clear: reaching a wider market, saving time, cutting costs, responding to customer queries quickly, obtaining needed product data, making informed purchase decisions, and developing and maintaining relationships . However, this work focuses particularly on developing and deploying B2B EC applications according to the following motivations: •The growth of EC is mainly in B2B. Zwass  notes that B2B volume surpasses that of B2C by a factor of 8 or 9. • B2B differs from B2C in many aspects, namely: the partner's relationships and coordination mechanisms, such as electronic networks , the type of transactions (e.g., load, degree of integration and innovation), the content (e.g., products presentation), and the personalization (e.g., type of customization) . •B2B differs from B2C in the deployment of the computational infrastructure (applications and platforms). While B2C requires some Web servers, backend applications and databases (business side) and a Web browser (consumer side), B2B integration requires a common agreed-upon business process, EAI (Enterprise Application Integration) of each of the involved partners and middleware , in addition to the services of the Internet and VAN. •B2B applications deployment is complex and costly . Linthicum  notes that though the value of B2B is clear, how to make it happen in the real world is much less clear. Moreover, the number of EC architectures, models, approaches and standards give us an idea of the complexity of such a deployment. Now, EC applications implement only a portion of the market transaction (e.g., order process, payment), on a case-by-case basis, and with a focus on the technology. The question is “Can we succeed in developing an entire integrated B2B applications?” We argue that it is possible provided that companies avoid being driven by the current technology. That is, companies must focus first on the specification and (re-) engineering of the business process that crosses the boundaries of the organization, i.e., roles, functions , and requirements. We need to understand the flows of information between businesses and the barriers to these flows, in order to get a common business process. Mastering the comprehensive business process assists in deciding a suitable technology (existing technology or new one to develop) that makes the business process more innovative, integrated and efficient. Indeed, current technologies might not be suitable . They are generally more developer-oriented than business-oriented . Moreover, B2B EC applications developed on a case-by-case basis, focus only on a part of the B2B transaction. B2B EC applications which do not implement important phases (e.g., pre-transaction, post-transaction) and partners' relationships (e.g., interaction aspects, namely mechanisms of coordination) are not very profitable. Therefore, a framework with multiple abstraction levels is required to specify the whole business process (including its distribution over involved businesses) independently of the implementing technology. Indeed, this independent specification helps in deciding the right B2B integration technology. This work proposes ABBA, an Architecture for deploying Business-to-Business Applications, an architecture with four interfaced abstraction levels: (1) business model and business process, (2) business process decomposition and distribution, (3) supporting services, and (4) integrating technology; and a consequent six-step design process to develop interoperable and scalable B2B EC applications. The objectives of ABBA are manifold: •Independence business process/technology. A design process of a B2B EC application must begin with the requirements, the analysis, the specification, and the modeling of the whole business process. The business process (flows of information and processes) must be understood and agreed by all involved businesses. The implementing technology must be decided later. Although, the technology is an enabler, there may be various implementing technologies for the same business process. Technology options include for instance, leveraging companies' technologies, reusing market technologies (e.g., Web services, OMG objects), or completely developing new appropriate technologies  and . This requires a common representation (or modeling), and a managing responsibility of the business process regardless of the technology. •Guidelines for a design process (towards a methodology) to deploy B2B EC applications. Due to the inherent complexity and the important deployment costs of B2B EC applications, a development on a case-by-case basis is inefficient. We need a comprehensive design process. Such a design process assisted by models, formalisms, languages, and tools aims at reducing the complexity and cutting the development costs. ABBA provides these guidelines. For instance, we can envision each level or interface of ABBA as a step towards the deployment and maintenance of B2B EC applications. •Communication between people involved in the design process (e.g., decision-makers, technologists and actors). Models, formalisms, and languages used at different levels, high (business process level) as well as low (technology level), allow communication between people “speaking” different domain-related languages. The rest of this paper is organized as follows: Section 2 presents a deep study and a comparison of current architectures, reference models, approaches, standards, and languages for B2B EC. Section 3 specifies the desired properties and the requirements of B2B EC. Section 4 elaborates the components of ABBA. Section 5 details ABBA corresponding design process. Section 6 concludes the paper and suggests future developments and issues.
نتیجه گیری انگلیسی
The goal of this work is to propose a comprehensive architecture for deploying B2B applications and systems. This architecture aims at: (i) making the business process (crossing the boundaries of the organization) independent from the implementation and integration technologies, in order to get a specified agreed-upon business process; and (ii) providing guidelines for an efficient design process to reduce the complexity of this kind of deployment. For this purpose, current contributions such as architectures, reference models, standards and approaches have been deeply studied and compared with respect to: the existence of a design process for B2B EC applications, the business model dependence and specification, the business process specification and modeling, the market type dependence, the orientation (process-oriented or document-oriented), the use of XML, and the technical requirements of each approach. Although, the studied models and approaches complement each other with respect to the abstraction levels, they do not propose explicitly an efficient design process for deploying B2B EC applications to reduce their complexity. Components of B2B applications are still deployed on a case-by-case basis. Accordingly, we have proposed and detailed ABBA, an architecture with four interfaced abstraction levels, and a derived six-step design process. ABBA is a new comprehensive business process-oriented architecture for deploying B2B EC applications and systems. This is an important issue today where the deployment of complex, open and scalable B2B EC applications and systems are critical for any competitive organization looking forward to be a leader (not a follower). Future work includes: • Developing models, formalisms, languages and tools to support the steps of the proposed design process. • Developing collaborative tools to manage the entire business process and its elements such as: generating and visioning a common business process from organization and partner's processes (re-construction), or dynamically managing partner's business processes (adding, modifying and removing) to deal with B2B EC system openness and scalability.