Web based sevices (WBS)
Reality
Today, admittedly, the above scenario is still primarily a lab exercise. As vendors and clients
participate in this environment, key factors are still under design discussion. Data costs.
Software to provide services has cost. Both may be protected by copyright, or some data may
be sensitive in nature. For government agencies where data was collected using tax money,
the Freedom of Information Act has defined that you have already paid for it. The agency
can only collect cost of media and processing, which for web access is negligible. As of the
date of this paper neither the FCC, any PSC, nor PUC has mandated that facility information
needed for competitive access or safety reasons (electric voltage or pressurized gas) be made
available this way. Whether census data will be available in this manner is still a topic of
discussion. Local governments have not decided to publish land ownership and zoning in this
manner. No DOT has documented their street resurfacing plans within a compliant catalog.
Not yet. In some cases, such as Local Number Portability, legislation precedes technical
ability. In this case, capability is ahead of the mandates.
A problem also comes when you seek data that is augmented or collected by a non-regulated
commercial enterprise. Companies that sell data are not eager to give it away. The E-biz
data cases are being developed. As a methodology for data and service acquisition, standards for access provide tremendous benefits for a commercial firm. Distribution costs are
minimized. Still transactions do cost. Many standards bodies and organizations are
addressing this issue. Many workable solutions have been proven. However, no one standard
exists today.
Implementation
As companies move from Silo or stove-pipe implementations to more integrated solutions,
two core architectures are evolving. These may be called either database or bus architectures.
It is often stated, and is very true, the corporate information maintained within database(s) are
very valuable assets. Companies that follow a data integration do a thorough job of defining
data dictionaries. They evaluate existing information, define what is common across systems,
what is unique to each system, and how each set of data relates to each other. The hardest
task is perhaps the establishment of stewards for each type of data. This defines who,
organizationally, can create an object, what they define, and what business rules are
employed. Then the definition includes who can access, if they can modify, how this is done
with business rules defined again. This continues through each data set until every object and
attribute is mapped.
A logically single schema, although physically segmented, can be produced to represent all
information. Data is moved from the silo databases into the new structure where security
controls establish which users have create and update access and who may read the
information. Triggers are usually established such that work flows are driven via the data.
For instance, a plan for a wire center is approved, service or marketing requests create work
activities. This opens access to engineers, performing work orders to view and copy current
facilities and plan data into their work order designs, where they add further engineering and
material details. The work order, when finished, triggers the appropriate management level
based on cost, job type, and area for approval. Rejections with comments flow back to the
responsible engineer for correction. When management approves, this action triggers the
permit acquisition process. When permits are obtained, the job is scheduled for construction.
The release to construction may trigger release of pending transactions to the customer and
circuit assignment systems. As construction updates the facilities from proposed to built (and
add details of actual construction material lengths) the assignment systems see these facilities
as available for use. As assignments are made to the facilities, this flows to customer billing.
Assignments create exhaust. At some predefined utilization level, planning is notified of the
need to plan additions to the facilities and the cycle repeats. Trouble reports, network alarms
and other data about the network also flows to the data model to cause other actions to occur.
Many other actions are also triggered such as number pooling, activities for number exhaust,
capital budget utilization, and other items which must be tracked and managed.
The second architecture, the bus architecture, achieves the same results. However, rather
than focus on mapping the data, processes are analyzed. Data is important as it feeds or exits
the process, but it is process action that inserts information, a trigger if you will, onto the bus.
Other processes listen for specific events that cause them to take action. The major difference
is that data private to the process is encapsulated to the process. Even shared data may be
stored locally with the process, which accepts a public interface to transmit (and possibly
transform) the data to the requesting process.
In many ways, these architectures have the same goals. Information flows automatically
between the organizations which need it to perform the companies business. In both cases,
web based services may be defined to provide common functionality needed across work
groups. IT is already a focal point for identification of requirements and acquisition or
creation of software. In the future, service catalogues may be accessed to identify solutions
to these requirements as well as to test replacement solutions that perform better or operate
more effectively in these environments.
No company is independent of outside influences. Planners and engineers need to know the
external activities that affect their work. They need to know:
-
Where a corn field has been rezoned for an apartment complex, subdivision, or
commercial activity.
- Construction schedules
- Where and when road moves and resurfacing activities are planned
- Where new roads and other transportation lines are being built
- When and where poles or conduit, which you do or could use are being replaced.
- When and where the water or gas company is trenching in new mains (a nice time to bury
that new fiber run)
In the same manner, utilities could benefit from knowing the telco construction plans.
The important thing is all of the above are outside your information system. This information
does not automatically invoke triggers within your database or raise events on your bus.
Today, to get this information people make trips or calls to courthouses, other public
agencies, and other planning departments. Typically, this information is difficult or
impossible to acquire. In the future, even before all of the security and cost issues are
resolved for fully open access, local government agencies, utilities, and telcos could decide to
share this level of information via catalogue services. Authentication services already in
place, could restrict URL access to the participant organizations. As this becomes common,
the web based services to correct for data differences (again projection, format…) could be
used as defined by OGC.
The benefits are fairly obvious. We have all seen streets repaved weeks before they were dug
up for a new cable or gas line. We have seen one trench opened for water and as the
replacement sod began to grow, another trench for gas require a second dig. We have seen
pole runs replaced, because of age and deterioration, only to be replaced again as a two lane
road becomes four lanes. We have seen 100 pair copper cable replaced by 800 pair copper
along a rural road and within months seen this replaced with fiber as the new subdivision
builds. Better communication makes for better integrated plans. It prevents rework and offers
cost sharing opportunities.
Differences in “platform” prevented this data sharing in the past. Web Based Services, based
on standards, makes these differences transparent to the end user. It is time to take advantage.
Appendix A: Example XML (GML), WBS Interfaces and Foundation
