Introduction
The Internet today is an essential part of the infrastructure, something which our industrial activities and lifestyles cannot do without. In the years to come, we need to establish a digital telecommunication infrastructure that creates an Internet environment of faster, more reliable, and permanent "always ON" connections. Japan's national strategy too, urgently calls for such an infrastructure. Such a permanently Internet-connected environment is expected to enable, in addition to the traditional communication between computers ("PCs" hereafter), peer-to-peer communication among mutually connected devices, household electronic appliances, and audio-visual equipment (to be referred to as "non-PC digital devices" hereafter). This requires IP addresses that are globally unique. The NAT technology currently in use does not allow for bi-directional communication. This is a serious shortcoming. Also, all the "connected" information devices have to have a solid security feature that practically allows permanent Internet connection. To satisfy these technological requirements, implementation of IPv6 is essential. Still, with non-PC digital devices, certain cost and resource limitations do not allow easy implementation of all of the specifications of IPv6.
INTAP has formed the Digital Home Appliances Technology Committee, in order to define technical specifications optimized to serve highly secure, IPv6-based non-PC network appliances. The committee is also conducting R&D activities related to reference software, and verification tools meant for such network appliances. The results of these activities are published to the general public through INTAP's website and other means, to obtain feedbacks from, and cooperation of, research institutes and corporations. INTAP hopes the committee's specifications will spread and win the status of a de facto standard.
Already in November 2000, INTAP proposed the specifications to IETF in the form of a RFC (Request for Comments, a form of proposal of technical specifications to IETF), and IETF discussed the specifications at the 52nd IETF Conference held in Salt Lake City in December. Figure 1 in the following page shows how the development processes of the specifications and their implementations relate to one another.

1. Minimum yet secure IPv6 specifications for non-PC digital devices

1.1 Need to define minimum specifications
1) End-to-end communication with IPv6 by means of allocating global addresses
There is demand for:
- Allocating addresses to countless electronic devices
- Enabling users to take their devices to wherever they want, and use telecom services
- Devices that, unlike the traditional client PCs, can function like a server, to send out information and conduct peer-to-peer communication between nodes.
In order to meet such demand, it is necessary to provide end-to-end communications with global IP addresses allocated in IPv6 networks, instead of the conventional IPv4 networks.

3) Defining minimum IPv6 specifications to cope with resource limitations
With many non-PC digital devices, the memory capacity, CPU performance, and many other physical specifications are strictly limited. In addition to these, there are also cost limitations as well. These limitations make it almost impossible to implement all the functionality defined in the IPv6 specifications of IETF. Also, the IPsec specifications, developed for enhanced security, are meant to meet a great variety of security requirements, and many non-PC digital devices simply cannot meet all such requirements. In short, requiring unpractical functionality in non-PC digital devices should increase the sizes/performance of the ROM and other built-in components and, therefore, the costs. This will in turn inhibit the spread and progress of IPv6 network devices.
In considering these factors, INTAP has decided to define the minimum host and security specifications for non-PC IPv6 digital devices with limited resources, so that they can provide end-to-end communications with the necessary security.

1.2 Types of devices covered by the minimum specifications
IPv6 devices can come in a great variety of shapes and sizes, and the restrictions to implementation of the protocol in these devices can differ greatly, depending on their designing principles, physical shapes, etc. For instance, todayfs PC has at least 64MB of memory in most cases. With a non-PC digital devices, however, we have to find a way to embed all the necessary IPv6 and IPsec features in a very limited memory space, as shown in Table 1 below.

2. Reference software

2.1 Functionality of reference software

INTAP intends to develop software that developers can reference when they implement functionality defined by the minimum IPv6 specifications proposed in non-PC digital devices. This software should have the following functions:
- Management of the network environment
- Sending packets
- Receiving packets
- IPsec functionality
- Interfacing with applications

BSD now enjoys broad popularity as a free OS for networks. Many use the OS as reference software. Furthermore, Wind River (known for its VxWorks), a leading company of embedded OSs, recently acquired BSDI, a vendor of commercial BSD packages. These facts point to the advantages of embedding BSD-related OSs in communication-oriented applications. (See www.bsd.com)
For this reason, INTAP has chosen BSD as the reference operating software OS.
We did not choose Linux, though it is broadly used as a network OS. This was because the Linux GPL (GNU General Public License) requires anyone modifying the reference codes to publish the source codes. This requirement can be a unwanted restriction to businesses developing commercial products using Linux, and we do not welcome such a restriction.

3. Verification software

3.1 Functionality of verification software

The verification software consists of the following functions:
- Platform expansion
- Inspection tool functions
- Device-dependent processing

Figure 4 in the following page illustrates the environment of the verification software. 3.3 Workshops of interconnectivity tests

We can justly expect that more and more informational home appliances, and other non-PC digital devices, will be permanently connected to the Internet over the years to come. To facilitate the growth and popularity of informational home appliances and other non-PC digital devices, it is crucial to define the minimum IPv6 specifications that provide sufficient security, to develop and provide reference software compliant with the minimum specifications, and to create a good environment of verification tests and interoperability evaluation. Another highly important task is to propose the defined specifications to IETF, so that Japan can be a world leader in international standardization with respect to informational household appliances. The spread of these non-PC digital devices should facilitate launches of new content businesses and stimulate other IPv6-related service businesses.

1) Objectives and activities
The committee is meant to prepare and publish some standardized guidelines of description and methodology to help organizations develop large, highly complex enterprise systems of today and integrate internal business systems in the way typically called EAI (Enterprise Application Integration). Such guidelines should enable corporations to divide the related specifications into several sections for easier management, and should be readily understood by third parties. Those guidelines, the committee hopes, will help businesses get over the complexity of enterprise systems today and improve interoperability among such systems. The committee employs the following two standards as the foundation for such standardized description and methodology.

2) Foundational standards employed
- RM-ODP (Reference Model for Open Distributed Processing)
This standard was jointly defined by ISO and ITU-T as one to be referenced in describing an open, distributed processing system. Technologically, the standard defines five viewpoints, enterprise, information, computational, engineering, and technology, and the target system should be described in terms of each of these five viewpoints. This means the whole description of the system's specifications should consist of five sets of descriptions. The standard's regulations cover its basic concepts, the five viewpoints, and the vocabulary and descriptive rules to be followed in describing the system specifications from each of the five viewpoints. The advantage of employing this standard is that the five viewpoints defined, effectively categorize the items of interest, and this way helps the user divide the complexity of the target system for easier description and management. The users have to, however, define their own additional methodologies when using the standard, since it does not define the specific methods or procedures of describing specifications (modeling) nor any regulations for descriptive languages and graphic representations.
- UML (Unified Modeling Language)
Standardized by OMG(Object Management Group), this is a graphical modeling description language that has integrated multiple methods of existing model descriptions. The language is expected to become an international standard in the near future. UML Profile for EDOC is an extended version of UML, which enables describing of enterprise and business systems. The extension designs its UML Profile based on gviewpoints,h which is among the basic ideas of RM-ODP as mentioned earlier. In addition to RM-ODP, the committee employs UML Profile for EDOC as well for the following three major reasons: (1) The use of UML enables more precise model description. (2) Using the existent UML tools available provides a ways to proceed forward to next steps of development, for instance, generation of skeleton source codes. (3) UML Profile for EDOC includes some functionalities not covered by RM-ODP but often featured by todayfs enterprise systems, such as Publish/Subscribe. Still, UML Profile for EDOC does not include the whole of RM-ODP. Actually, some parts of the latter can not be described by UML Profile for EDOC. Thus, once again, the users have to define their own additional methodologies.

3) Recent activities
In 2000, the committee analysed some instances using mainly RM-ODP, and participated in the joint projects described below. These activities enabled the committee to accumulate more know-how. These achievements are described in a report for 2000, which is available from INTAPfs website. The committee is currently working to publish the first edition of the guidelines mentioned above as an accomplishment for 2001.

2. Joint project of medical enterprise models
Four organizations, namely MEDIS-DC(the MEDical Information System Development Center), JAHIS, CBOP, and INTAP, are currently developing a reference enterprise model for Japanfs hospital information systems, as a joint project. Commenced in the latter half of 2000, the joint project is part of the medical information standardization efforts of MEDIS-DC and JHIS, a good opportunity for CBOP to put its modeling and component technologies into practice, and a valuable opportunity for INTAPfs Open Distributed Processing Committee to gain more know-how for preparing the guidelines mentioned above. The committee can apply RM-ODP to a specific enterprise system of hospital information. In 2000, the committee prepared the first edition of a reference enterprise model for Japanfs hospital information systems, which is described in the committeefs report for that year. 2001 saw the committee specializing in the field of medical radioactivity and applying the basic section of UML Profile for EDOC to the field. The results of such efforts have been compiled in the form of an exercise to UML Profile for EDOC, Part II. Since the latter half of 2001, the committee has been trying to create a model for e-medical record systems from the basic models defined so far.

1) Applying RM-ODP to a hospital information system
The committee's challenge was to verify whether it was possible to describe in RM-ODP, the information system of a typical Japanese hospital, in a way that satisfies the requirements of such a system. Among the five viewpoints, the enterprise viewpoint required the committeefs own methodology of application, since there was no precedence for this viewpoint, for which standardization was still in progress. In more specific terms, the committee extracted from the draft standard a small number of core concepts which the committee believed were reliable enough. Using those chosen concepts, the committee tried to enable description that was as simple and reliable as possible. An enterprise model contains these model elements such as community, objective, scope, role, object, policy, process, and others. Now, let us explain how they found these elements and described them.
(1) A community refers to a collection of objects that collaborate for the same objective. The committee began to create the enterprise viewpoint model with its community. First, they treated the whole hospital information system as a single community. Then, they described the communityfs relationships with the outside communities, with the focus set on what external communities it could have relationships with.
(2) Next, the committee structured the hospital community by defining sub-communities within it. In addition to the objective, they assigned roles and objects, which are to be explained later, and also considered policy differences and other issues. After many trials and errors, they settled on defining a structure similar to that of an existing section.
(3) They assigned the objects and roles that made up each community. While an object has a corresponding status, a role indicates how it should behave. In conducting this assignment, the committee considered, among many other issues, that an object should have a corresponding status, that an object should perform some roles which were abstracted expression of the behaviors, and that an object should be able to play some roles. They extracted some candidates for the roles and objects from the information supplied, namely the operational flow. Still, they had to choose between two possible principles in modeling, for instance, whether a doctor should be treated as a role or an object. They made this decision depending on the objective of the modeling, which defined what kind of a model was appropriate, and the level of granularity supposed.
(4) The committee defined policies mainly for the community and the roles. For instance, these policies provided regulations that held true to the whole community, other rules that an object should observe as it played a role, and so on. All of these regulations were described with the keywords already defined by RM-ODP, namely duty, prohibition, approval, and permission.
(5) The committee expressed a process by making a diagram of activities divided into lanes, with each lane corresponding to the communityfs roles, based on the operational flow. This was used as the standard flowchart expression. Such diagrams made clear the major business process flows and the information transmitted within the hospital.

These efforts above resulted in a document describing the enterprise model. Except for the diagrams of activities, most of the model was described in the text. The numberes of model elements were: 10 for the community, 27 for the roles, 13 for the objects, and 118 for the policies. At the same time, this project revealed what remaining tasks the committee needed to accomplish. One major task that was needed was to simplify the policy elements.

2) Experimental application of UML Profile for EDOC
Beginning with a RM-ODP enterprise model, the committee created a model using UML Profile for EDOC. In this phase, the committee decided to focus on a specific aspect of the hospital system, rather than trying to cover the system as a whole. They chose the radiology department as its main focus.
- Enterprise model
In order to describe a model from the enterprise viewpoint, the committee chose the Business Process Profile, as the major tool of description from the multiple Profiles available from UML Profile for EDOC, since the Business Process Profile seemed most suited to describing the operational flows within a hospital, the kind of flows covered by this project. Beginning with the activity diagrams prepared with the RM-ODP enterprise model, the committee clarified the operational steps and expressed them in the form of business processes. This way, they repeatedly identified the details of who performs a particular operation, what informational elements are affected by the operation, the presupposed conditions, the conditions resulting from the operation, information passed from one step to another, and many more issues.

- Information models
Expressing a RM-ODP information model in UML results in a diagram of classes that represent the information objects, and the restrictions to the respective classes (should always be true, initial values, conditions for updating, etc.) expressed in OCL or some other format. This project produced the information models using some of the business processes of enterprise models and other processes. Since there are other methods for doing this, the committee is currently evaluating guidelines for these other methods. The diagram below shows some of the other information models.

- Computational (component) models
RM-ODP description divides a computational object into some logical units of functionality. UML Profile for EDOC can relate business processes to various technologies. In more specific terms, it can handle components, workflows, messaging, Web services, etc. This project prepared its computational models to suit the component technology that the committee believed was the most secure at the time of the consideration. Still, such computational models can work with the other technologies mentioned above. UML Profile for EDOC has a basic profile called Component Collaboration Architecture (CCA) as a component technology. The committee decided to express the specifications in a way that corresponded to CCA, in order to gain platform independence. The majority of these correspondence efforts included defining the processing components that corresponded to the performers of the respective activities of business processes, and adjusting the information passed among the activities to remain consistent with the information models. These efforts enabled the committee to express a list of the components, complex forms of the components, the interfaces provided by the respective components, the interactions among the components, and so on. The diagram below shows some of the computational models using CCA. The committee continuously presented such RM-ODP and UML Profile for EDOC applications, and published the related reports, on many occasions including OMGfs Healthcare Domain Task Force (in March and July), the IEEE EDOC 2001 Conference (September), BOSC 2001 (November), and others. These presentations were also intended to promote international collaboration on such applications.

3) Problems to solve
The committee encountered many problems as it went forward with the considerations. The major issues include:
- Since RM-ODP and UML Profile for EDOC were both in the process of standardization, the committee selected the sections that it believed were reliable. This in turn meant some other functionalities and concepts of these standards were not used for this project. Since the standardization has progressed since then, these standards today have more reliable functionalities and concepts. One task the committee should address is the application of more of these standards.
- The committee recognized that handling policies were a remaining problem in both RM-ODP and UML Profile for EDOC.
- The committee strongly recognizes the necessity for methodologies to apply RM-ODP and UML Profile for EDOC. The committee is determined to continuously consider and prepare the guidelines mentioned earlier, which will provide such methodologies of application.

3. Related topics and activities abroad
OMG is a non-profit organization to promote standardization of UML in collaboration with UML. OMG has recently been promoting an initiative named Model Driven Architecture (MDA). In short, this initiative defines consciously gPlatform-Independent Modelsh (PIMs) in software development, applies platform-specific mapping to such models, convert them into gPlatform Specific Modelsh (PSMs), and use those PSMs in software development for the specific platforms. This initiative enables semantic correspondence, even among different platforms, as long as the original platform-independent models are the same. This facilitates interoperability among different platforms as well as re-use of platform-independent models.
One effective way to prepare and describe such gplatform-independent modelsh is employing three viewpoints, enterprise, information, and computational, of RM-ODP. Supposing the UML description in this way, the corresponding profiles of UML Profile for EDOC will also be used. The Open Distributed Processing Committee hopes the RM-ODP application guidelines will offer assistance to many users in their preparation of platform-independent models.
In Europe, the COMBINE Project is currently under progress as an EU project, trying to develop enterprise systems based on models and components. This project employs the concepts of UML Profile for EDOC and MDA. INTAP hopes to exchange some information with them.

4. The committee is currently considering a procedure, summarized below in model development, which may provide a relatively reliable methodology. The procedure employs both RM-ODP and UML Profile for EDOC.

The Open Distributed Processing Committee is still continuing the modeling work of the hospital information system. The committee hopes the guidelines for application, though somehow heterogeneous from the other interoperability-related regulations developed by INTAP so far, will provide standard reference information with respect to enterprise systems modeling. The committee eagerly hopes to hear many opinions and requests from the readers of this work.

iDC market and the trend
iDCfs are attracting attention is that as the shift to broadband Internet and high-speed electronic commerce accelerates, Internet connection is becoming a commodity and so carriers are pursuing new services. This is leading to a shortage of IT engineers and cost saving by outsourcing non-core functions.
iDC is a new market that is rapidly changing with the players coming and going. According to the data of market research companies, the iDC market including ASP will be worth from $4.7 billion to $25.3 billion in 2004.
Major iDC players include carriers such as ATT, WorldCom (uuNet) and Global Crossing, hosting specialists such as Exodus and Digex and neutral data centers such as Equinix. These major players are competitively building iDCfs. As the earnings ratio is low on the model that only leases space, there is a move to increase the earnings ratio by providing various services. IBM and Digex enjoy a higher earnings ratio, while Exodus has a lower earnings ratio compared to gross sales.

Conditions of iDC
The construction of iDC requires special contacts and specialized knowledge, and real estate companies often have a separate division to provide special services for data center construction. A data center must satisfy various demands, such as to keep the servers and other devices safe and to enable continuous operation. The main conditions are that the building should be firm and not be affected by fire or natural disaster, have broadband and fast network access, and have a large electric power supply capacity. The recent shortage of electricity in the Silicon Valley area in north California is a serious problem, and a stable power supply is of utmost importance.
For network access, the supply of a fast broadband network is greatly affected by elements such as whether there is a nearby connection point to the backbone and how the backbone is peered with other backbones. For details of bandwidth and transfer speed in peering and Internet core, an article by Mr. William Norton from Equinix, a specialist in the field, is a good reference.

ASP selection standard
Information Week published the results of a survey on the standards used by users when selecting ASP. Speed is a major problem. Bandwidth, equipment and distance also affect the speed of Web response.
Regarding bandwidth, as an IP network cannot insure QoS at present, more bandwidth than is necessary is usually allocated. The method to carry IP over layers such as ATM is also used. Constant bandwidth should be insured in this field once MPLS and Diff-Serve technologies are established. However, it is expected to take several years until QoS over multiple ISPs is actually insured.
Though reinforcing servers and other computer equipment can affect the response speed to some degree, increasing CPU and memory is physically restricted and is not an effective solution alone.
Regarding the distance problem, as the speed of light is constant and finite, making the distance between contents and users closer is an effective way to boost response speed. Active moves are being made regarding contents, delivery and network as a solution.

Response speed and improved technology
As Web response speed is a big problem, we considered various technologies used to improve it. A method of measuring response speed is necessary to improve speed. Keynote provides a wide variety of services on measuring Web response speed and publishes Web response data for 20 to 40 companies in 9 categories every month. Caching is a technology that can be used in several places such as in front of the user site, the ISP site and the data center server. Load distribution is used to distribute loads to multiple servers. Context identification switching can change the quality of service depending on what the request is and who requested it. Contents Delivery Network (CDN) places the content server at the edge of the Internet and delivers contents to users from the nearest server.

iDC/ASP interview research
We conducted interviews with three companies in different positions to hear the direct views of the iDC/ASP market.
Equinix, which is an iDC, provides a place for ISP, ASP, SI and end users to freely develop their businesses from a neutral position as a data center. They did not disclose the location of the actual data center for security reasons and we know only that they have 6 data centers called IBX in the US. We visited a data center in San Jose.
At Corio, which is a major ASP, our interviews focused on iDC from the viewpoint of ASP. Though they have their own network center, the actual servers operate as hosts in the data centers such as Exodus. We heard that there was no problem regarding security between sites because they were using dedicated lines such as T1.
Loudcloud of SISP/AIP provides outsourcing services to construct an infrastructure based on Web technology. Loudcloud is called an MSP or AIP in the market and they describe the market they occupy using the new term, SISP (Software Infrastructure Service Provider).

Conclusion
The iDC market is expected to grow greatly. Based on the current merger trend, carriers are likely to deploy not only infrastructure network but also businesses to provide data centers and related services. As it is not easy to develop technologies such as iDC and Web integration, Exodus and Loudcloud may end up being bought out. According to a forecast of a market research company on iDC in 2001, ASPfs will disappear eventually unless they overhaul their business model. ASPfs might be purchased by carriers.

Four categories
The Internet infrastructure layer mainly provides the hardware and software that form the infrastructure of the Internet. This includes companies which provide the fiber itself, carriers which provide the network, vendors which provide network equipment, servers and PCs and companies which provide security. The advantage of this layer is that businesses will increase as network traffic increases, irrespective of the trend of the layer formed on this layer as a base. The disadvantage is that commodities will be prevalent and the price will rapidly fall. There are moves toward a merger of the three major carriers, ATT, WorldCom and Sprint, and to separate the long distance call business with its slow growth in earnings, from the Internet. The results of companies providing components on which the Internet is built such as Cisco, Lucent, Nortel and 3Com will be affected by the purchasing eagerness of carriers and service providers.

The Internet application layer provides utilities, tools and services on the core infrastructure layer. These services are general services and not specific to electronic commerce. Internet consulting ASP, AISP and SISP are included here. Companies such as Yahoo with online marketing functions and search engines span multiple categories. As there are various utilities unlike the infrastructure layer, it is difficult to describe the features of everything except to say that they will be built on the infrastructure layer. The Internet consulting company USWeb/CKS was acquired by Whitman in March, 2000 and a new company MarchFirst was formed. Though they added workers to keep pace with the development of electronic commerce, they hit problems with the bursting of the dot-com bubble. Oracle, which provides Internet software infrastructure, prides itself on its high market share in electronic commerce and Internet, and a considerable number of back offices use Oracle databases for electronic commerce. The company is little affected by the recent sluggish stock market and is performing well.

The Internet interface layer provides a place to extend business and earns revenues from business transactions. This layer makes use of the functions of the Internet application layer and does not provide functions by itself. Priceline, which enabled users to sell or buy air tickets and accommodations by specifying a price, was notable for its novelty. However, it was defeated by the emergence of competitors that require no brokers. Schwab, which runs a website for buying and selling stocks, is doing well by combining services that require an existing office network and specialized knowledge that are not dependent on the Internet.

The Internet commerce layer is not greatly different from the interface layer and focuses on sales rather than interface. This layer uses the functions of the application layer and does not have its own functions. Though many companies have established their brands by large-scale advertising such as Amozon.com, WebVan (sales of perishables on the Web) and Pets.Com, they have serious problems with their earnings and face an uphill battle.

Conclusion
Internet-related businesses have been highly touted, but must now reconsider their business models following the dot-com collapse. Though conditions specific to the Internet are required for Internet companies to succeed, they must at least satisfy normal business requirements such as having a carefully reviewed business plan, entrepreneurial skills and experience.