CHAPTER 3: VIRTUAL ENTERPRISE INFRASTRUCTURE
3.2 T ECHNOLOGIES AND S TANDARDS FOR V IRTUAL E NTERPRISES
3.2.2 Distributed Component-based Business Systems
Whereas EDI supports electronic business by automating existing processes and enabling electronic document exchange between separate organisations, a number of other systems approach electronic business by trying to create a single virtual organisation (Stricker 00, Fielding 98). These systems use middleware, a layer of integration code and functionality that allows multiple diverse and distributed systems to be used as though they were a single system.
Using these middleware tools, business applications can be transparently accessed the multiple backend systems (Georgakopoulos 98).
The first approach used in developing such enterprise systems was proprietary custom-engineered solutions on top of Internet’s TCP/IP protocol. These systems were traditional client/server applications with proprietary message formats and customised integration of third party purchasing management systems. The provided solutions were in general closed and tailored to company’s needs and requirements. The development time and the cost were rather high, while the maintenance and re-engineering was also difficult and ineffective (Orfali 96, Nissen 99). These solutions adopted mostly by big companies due to the high development and integration costs and are characterised by inflexibility, limited degree of interoperability and security. The main reason of low acceptance of such solutions was the high re-engineering time.
This means that as the business processes and activities of the company were changing in order to respond to market needs, the systems could not respond to these changes effectively (Bolcer 99).
Due to the rapid development and acceptance of distributed object oriented platforms, a new generation of enterprise systems started appearing. The concept of re-usability and middleware has been introduced in the development and integration phase. These concepts resulted in the creation of Distributed Component-based Business Systems (DCBS). The DCBS composed of basic building blocks or components, mostly based on object-oriented technologies, that can be bought “off the self”, reused or extended, customised, configured, and integrated into the overall, distributed business information system (Orfali 96, Doz 99). This approach enables the development of solutions faster, in a cost-effective way, with easy maintenance and accepted level of interoperability and distribution. These technologies are actually integrated development and run time environments that isolate much of the conceptual and technical complexity involved in building business applications. Due to the advent of Java and open distributed platforms, like CORBA, object-oriented middleware business systems gain strong momentum and support (OMG 98, EJB 98, Ouzounis 98c). However, these systems have been initially designed and developed for intra-domain distributed applications and not for dynamic
inter-domain business process execution (Carr 96). Even when they are used for inter-inter-domain business process execution and management, their goal is to create a single unified view of a virtual enterprise (Camarinha-Matos 99).
Classic middleware systems typically involve tight binding between the systems and processes at the various domains. By closely coupling the different domains, classic middleware systems are able to provide rich functionality, but require expensive initial development and deployments, pre-agreement in the interfaces used by the different components and carefully coordinated ongoing deployment management (Thompson 99, Sheth 98). These systems are thus most appropriate for use in intra-domain, distributed applications or long-term and closely co-ordinated business partnerships (Redlich 98, Hull 99).
In the following sections the most influential DCBS frameworks are discussed and analysed in relation to their applicability to the dynamic VE concept.
3.2.2.1 OMG’s Business Objects
OMG’s Business Object was an industrial activity towards standardised DCBS based on a set of well-defined middleware CORBA services (OMG 98). The activity started mid 97 by OMG members and failed to produce a common framework due to technical and political differences among the members.
The main idea behind the proposed framework was the business object, i.e. “specialised CORBA objects that they are network accessible through an object request broker. A CORBA “object reference” uniquely identifies an active business object within the distributed object environment for purposes of communication through an object request broker.” A business object also has a unique identity that associates it with the entity it represents in the business domain. This identity, or key, uniquely identifies a business object within its type and is always associated with a corresponding entity in the real business world.
The main attributes and characteristics of business objects are the following:
• transactional: due to the fact that business objects are sharable in a distributed, multi-user, transactional environment, there must be concurrency control and transaction serialisation to maintain the integrity of the model they represent,
• persistent: persistence is necessary to maintain the state of objects, i.e., the data, when the system is shut down or fails. Persistence is not required for all business objects, but if they have state and represent current information about the business, they will be persistent,
• relationships: business objects will have relationships with other business objects that represent associations between their business-world counterparts. Relationships may be one-to-one or one-to-many, and they may be bi-directional or one-way,
• ad-hoc Notification: Most business objects also support ad hoc event notification. A message can be sent to a business object requesting notification of certain events be sent to a designated consumer. Notic es will be sent whenever any specified event occurs until the request is terminated.
Two type of business object have been identified:
• common business objects: objects that represent the key elements of a business domain, like an employee. These objects are persistent and are used for building high level business objects.
• business process objects: objects that perform a business operation or a process within a business domain or context. Usually, these objects are not persistent and utilise existing common business objects.
The layered architecture of the Business Object concept is depicted in the following figure:
E J B / C O R B A c l i e n t s
E J B / O M G B u s i n e s s P r o c e s s e s
E J B / O M G C o m m o n B u s i n e s s O b j e c t s
I I O P R M I
L e g a c y S y s t e m s , D a t a B a s e s
( O D B C , J D B C ) , M i d d l e w a r e
S e r v i c e s I I O P M i d d l e w a r e S e r v i c e s R M I M i d d l e w a r e S e r v i c e s
Figure 3: Distributed Component-Based Business Framework Architecture
The Business Objects were one of the first activities in the area of standardised DCBS and introduced a set of innovative ideas. One of the main benefits was the shorten development and deployment costs, as well as, lower costs in integration and distribution (Orfali 96). However, the differences among the OMG members did not allow a concrete, stable, and well-defined framework for business objects.
3.2.2.2 Enterprise Java Beans
Enterprise Java Beans (EJB) was a competitive to the OMGs Business Objects proposal from Sun Microsystems that has been proposed in late 98 (EJB 98). The main goal of EJB was to propose an architecture for building distributed object-oriented business applications in Java by combining, not only basic middleware services, but also existing business components. In that respect, EJBs, as well as OMG Business Objects, share the same goals and principles, i.e.
reusability and fast development and integration.
An EJB runtime environment is composed of a server and a set of containers. The server is not an application server; instead, it routes method calls to the enterprise beans deployed under its containers and provides services to these containers and their components. The services provided are defined by electronic contracts between the various parts of the EJB architecture like the contract that exists between the container and the beans in it. These electronic contracts provide interfaces that decouple parts of the architecture into roles (Nissen 99).
The EJB specification defines a number of roles necessary in implementing the EJB component architecture. The roles are logical in nature, so multiple roles may in fact be performed by the same party or human operators. EJB defines the following roles:
• server provider: the server provider provides the EJB server, which handles distributed object, distributed transactions management, and other services for enterprise beans in containers,
• container provider: the container provider produces a container, which is the context that interfaces with enterprise beans at runtime. The container can implement the session bean contract or the entity bean contract,
• enterprise bean provider: the Enterprise bean provider writes enterprise beans to make up specific applications.
• deployer: the deployer takes beans produced by the enterprise bean provider and deploys them in the backend runtime environment. This process may involve mapping the security roles set by the beans to the security roles required by the organization,
• application assembler: the application assembler uses the client view contract of the enterprise beans deployed at the backend to assemble client applications. The application assembler may also produce new beans by combining existing beans.
Two key types of EJBs have been currently proposed, namely the:
• session Bean: a session enterprise bean models a connection or session with a single client.
Session beans persist only for the life of the connection with the client. If the EJB server crashes, the session bean dies. When a new client references a session bean from the server, the container creates a new instance of the session bean, which is tied to the client that made the reference request through a bean object provided by the container,
• entity Bean: entity beans model business objects that need to persist beyond the life of a client instance. Each instance of an entity bean can be accessed simultaneously by multiple clients. Entity beans survive crashes of the server.
One of the main benefits for using EJBs is the simplicity and ease of integration, due to the usage of Java programming language and its accompanying services, web-integration, distribution (RMI), security etc (Ouzounis 98b). Another main benefit is the life-cycle operations for the creation and management of Beans. By implementing or extending only a set of well-defined interfaces and following certain instructions a bean can be easily deployed in different, native distributed platforms, like Java-RMI, CORBA-IIOP, and DCOM, due to the concept of containers. This approach enabled programmers to rapidly develop DCBS.
From the above description, it is clear that there are a lot of synergies among the OMGs Business Objects and EJBs. Particularly, the entity beans have similar concept to the common business objects while the session beans have similar ideas and mission like the process objects.
In addition to that, the container model in EJBs is actually, the same concept of infobus provided by CORBA-IIOP for interoperability reasons. Actually, EJBs are considered not more than a well-specified, realistic , and standard version of OMG’s Business Objects specification based on Java Framework and RMI protocol (Chung 98). Due to the industrial support of EJBs and the tools provided for developing and deploying this technology, EJBs are better positioned in the world of DCBS.
Although EJBs gained momentum in the open market, the model that is being used is the tight integration of distributed components, and thus the integration of EJBs business components across different domains can only be performed by tight integration and object binding (Hoffner 98 and 99). This is the favoured and applicable model for static Virtual Enterprises, where the
business relationships among the business partners are static, pre-determined, and fixed. This approach positions the EJB as a promising technology for intra-domain distributed component based business applications and not for dynamic VEs (Zarli 99, Tombros 00, Geppert 98).
3.2.2.3 San Francisco from IBM
IBM's SanFrancisco framework, proposed in mid 97, as OMG Business Objects and Sun’s EJB, is a multi-tier Java development framework for building distributed business applications (SanFran 98). The SanFrancisco framework specifies and deploys standard business components and easy integration and customisation services with backend legacy systems. Using this framework, developers can build systems, such as order management systems, that span multiple physical nodes, integrate with the backend legacy systems at those nodes, and provide unified functionality across the diversity of different nodes and systems.
San Francisco was one of the first serious commercial attempts in the area of DCBS. The main design principles of San Francisco was the same like EJBs and business objects, i.e. to specify a set of common, persistent, objects that represent real entities in a business environment and a set of objects that deploy these “middleware” business objects to provide business processes. In that respect, San Francisco was actually IBM’s view of DCBS based on the different concept emerged in OMG.
Although the framework was based on open, standard, distributed technologies like CORBA and Java, the acceptance of it was rather low (Zarli 99, Filos 00). The main reason was the deployment of non-standard and in most cases, proprietary middleware services provided only by IBM. The evolution and thus, maturity of San Francisco framework stopped when IBM announced full support of Java 2 Framework and consequently, the full adoption of EJB approach and concept.
3.2.2.4 Alliance from Extricity Software
Another related framework for inter-domain business process management is Alliance, a suite of products, aimed at business-to-business process integration (Allinace 98). Similar to the other middleware systems, Alliance provides a distributed framework that can access multiple enterprise systems and supports unified and transparent access to those systems.
However, unlike Enterprise Java Beans or SanFrancisco, which focus on data integration between systems, Alliance focuses on process integration between distributed business partners.
Alliance is thus, designed from the beginning to support inter-domain business process management.
A set of business partners deploys and integrates Alliance by determining the processes that they will engage in together. The partners use the Alliance process implementation environment to model their common processes. Each partner then uses additional Alliance tools to model its private processes as they support the shared processes. Separating the definition of shared and private processes allows partners to update their private processes independently. Coordination is only needed when changing the shared portion of a cross-organization process.
At the same time, as the inter-domain shared business processes are specified, partners model the data they exchange during those processes. Alliance uses a document exchange model,
which decreases coupling of the partner information systems. The documents exchanged are defined starting from templates provided with Alliance and using information modelling tools included with Alliance. This customisation is analogous to the implementation conventions required to implement EDI solutions.
Because Alliance uses document exchange between organizations, it avoids many of the security issues that limit the applicability of Enterprise Java Beans and SanFrancisco in inter-domain deployments (Filos 00, Bolcer 99). However, other design choices in Alliance increase deployment costs and make it most appropriate for long-term, stable, closed, and closely coupled business relationships, i.e. static VEs. For example, because cross-organization business processes must be modelled across all the participating partners and then implemented in concert, partners must coordinate manually their deployments (Stricker 00). And during deployment, significant customisation and integration work is required so the system can interoperate with each of the partners' enterprise systems. This means that each new relationship takes significant work to support and thus, evolution of the VE is very difficult and time consuming task.
Alliance is thus most applicable to static VE model where business partnerships function essentially as long term partnerships of a larger virtual enterprise. These virtual enterprises can afford the deployment cost of an Alliance solution and can look for returns over long periods of time.
3.2.2.5 Distributed Component based Business Systems in the context of VEs
Distributed Component based Business Systems gained momentum in the R&D activities, as well as, in commercial systems due to the simplicity, ease of integration and deployment, high degree of distribution, standard underlying distributed protocols, like CORBA-IIOP and RMI and middleware services. However, most of these systems are inadequate for usage in a dynamic VE environment (Filos 00, Zarli 99, Tombros 00).
DCBS assume a tight coupling model (Orfali 96). This applies both to the integration with backend legacy systems and to the client applications. Backend systems and clients integrate with the distributed framework using the APIs and object models exposed by the underlying levels of the architecture. While clients are insulated from the APIs of the backend systems, they are tightly bound to the provided APIs. This design choice has two implications (Ouzounis 99b).
First, by using object binding as the interaction technique, as opposed to document exchange used in EDI, DCBS applications must be adopted at once by all participants in the cross-organization relationship. And upgrades to backend systems, the component framework, and the business application must be coordinated across all participants (Spinosa 98, Hull 99). Second, because of the tight binding, security issues are a major factor. Objects running in the business components-applications at one company must be able to communicate directly with objects running in the same component model, either EJB or San-Francisco at a partner company (Thompson 99, Sheth 98). For good reason, the IT staff is reluctant to allow object access across corporate firewalls. This poses a significant barrier to adoption in cross-organization environments.
Additionally, the DCBS frameworks do not provide a complete solution, but instead serve as the starting point for developers to build applications (Orfali 96, Carr 96). By building on the
framework, developers can more quickly complete applications and leverage the code in the framework that takes care of many of the mechanical details needed for a successful distributed application. This is ideal for corporate developers who are already accustomed to doing significant custom programming.
Finally, these choices make the DCBS frameworks most appropriate for deployment inside a single company that needs to link multiple distributed divisions or sites (Redlich 98). Such a company can plan for a unified deployment and can afford the integration and customisation work. A single company can deal with the security and firewall issues internally without opening potential security hazards to the outside world (Nissen 99). Indeed, as it is stated above, the majority of DCBS deployments are taking place inside single enterprises and for intra-domain applications.