Linking ActivityML to Mathematical Web Services
step 1: check if things are all connected!!
So many technology items to piece together before a service can be designed and 'made'. I am following the Quick Start Guide here:
- A 4G IBM Blade Center Unit with dual processors (Xeon's)
- RedHat
- Tomcat 5.5.17
- JDK 1.5.0_07
- axis2-1.3
- environment variable AXIS2_HOME points to /opt/axis2
- compile the simple saas001.java based on the StockQuoteService at /opt/src
- at /opt/src, do this
/opt/axis2/bin/java2wsdl.sh -cp . -cn A2A.computeEngine.services.algebra.saas001 -of saas001.wsdl
- the saas001.wsdl is generated at /opt/src. Not sure where this WSDL file should go. In principle, this WSDL exposes the service for the broker to locate the service on behalf of a client.
And part of the WSDL file (raw; we need to modify some areas to reflect the true environment, e.g., domainname vs localhost):
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:ns0="http://algebra.services.computeEngine.A2A"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:ns1="http://org.apache.axis2/xsd"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
targetNamespace="http://algebra.services.computeEngine.A2A">
<wsdl:types>
<xs:schema xmlns:ns="http://algebra.services.computeEngine.A2A"
attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://algebra.services.computeEngine.A2A">
<xs:element name="getCountry">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="param0" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="getCountryResponse">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="return" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="update">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="param0" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="param1" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<wsdl:message name="updateRequest">
<wsdl:part name="parameters" element="ns0:update"/>
</wsdl:message>
<wsdl:message name="getCountryRequest">
<wsdl:part name="parameters" element="ns0:getCountry"/>
</wsdl:message>
<wsdl:message name="getCountryResponse">
<wsdl:part name="parameters" element="ns0:getCountryResponse"/>
</wsdl:message>
<wsdl:portType name="saas001PortType">
<wsdl:operation name="update">
<wsdl:input message="ns0:updateRequest" wsaw:Action="urn:update"/>
</wsdl:operation>
<wsdl:operation name="getCountry">
<wsdl:input message="ns0:getCountryRequest" wsaw:Action="urn:getCountry"/>
<wsdl:output message="ns0:getCountryResponse" wsaw:Action="urn:getCountryResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="saas001SOAP11Binding" type="ns0:saas001PortType">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<wsdl:operation name="update">
<soap:operation soapAction="urn:update" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
</wsdl:operation>
<wsdl:operation name="getCountry">
<soap:operation soapAction="urn:getCountry" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="saas001SOAP12Binding" type="ns0:saas001PortType">
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<wsdl:operation name="update">
<soap12:operation soapAction="urn:update" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
</wsdl:operation>
<wsdl:operation name="getCountry">
<soap12:operation soapAction="urn:getCountry" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="saas001HttpBinding" type="ns0:saas001PortType">
<http:binding verb="POST"/>
<wsdl:operation name="update">
<http:operation location="saas001/update"/>
<wsdl:input>
<mime:content type="text/xml" part="update"/>
</wsdl:input>
</wsdl:operation>
<wsdl:operation name="getCountry">
<http:operation location="saas001/getCountry"/>
<wsdl:input>
<mime:content type="text/xml" part="getCountry"/>
</wsdl:input>
<wsdl:output>
<mime:content type="text/xml" part="getCountry"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="saas001">
<wsdl:port name="saas001SOAP11port_http" binding="ns0:saas001SOAP11Binding">
<soap:address location="http://localhost:8080/axis2/services/saas001"/>
</wsdl:port>
<wsdl:port name="saas001SOAP12port_http" binding="ns0:saas001SOAP12Binding">
<soap12:address location="http://localhost:8080/axis2/services/saas001"/>
</wsdl:port>
<wsdl:port name="saas001Httpport" binding="ns0:saas001HttpBinding">
<http:address location="http://localhost:8080/axis2/services/saas001"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Ok, for each service, axis2 imposes a structure to be followed packaged in a 'aar' file. In our case, we have:
- saas001
- META-INF
- services.xml
- lib
- A2A
- computerEngine
- services
- algebra
- saas001.class
The services.xml file should contain the following information:
<service name="saas001" scope="application">
<description>
Conversion of IP to Country Service
</description>
<messageReceivers>
<messageReceiver
mep="http://www.w3.org/2004/08/wsdl/in-only"
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
<messageReceiver
mep="http://www.w3.org/2004/08/wsdl/in-out"
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
</messageReceivers>
<parameter name="ServiceClass">
A2A.computerEngine.services.algebra.saas001
</parameter>
</service>
The file at /opt/jakarta/webapps/axis2/WEB-INF/conf/axis2.xml is
modified with the following specific (to my environment) information and other changes as a result:
- I changed the password to username 'admin' for the admin page to that the same as for 'aola'.
- No change to /opt/jakarta/webapps/axis2/WEB-INF/web.xml for now. Axis2 repository path can be defined here.
- saas001.wsdl has been modified by replacing the 'localhost:8080' references with 'blueberry.ccl.baf.cuhk.edu.hk'; there is a reference to Namespace of 'http://algebra.services.computeEngine.A2A' that should be defined or changed.
- Create the /opt/WebLOGs/ directory to hold the log4j logs (e.g., in /opt/jakarta/webapps/axis2/WEB-INF/classes/log4j.properties now points to /opt/WebLOGs/axis2.log)
I think I know what needs to be done, but let me try the basic setup first.
STOP, let me try the samples that come with the release...
Linking ActivityML to Mathematical Web Services
one small step: the environment for services
Taking a lesson plan and realize it as a portable XML-based document can now be done with the activityEditor. With an activityML lesson, the AOLA environment now brings the lesson live in the ePlatform. The next missing step is the discoverable mathematical services to render on-demand graphical mathematics (some form of dynamic mathematics) and to provide the computational engine for dynamic mathematics in real-time.
In this posting, we learn how to use axis2 to create an online environment to create a proof-of-concept Saas (software as a service) for AOLA mathematics learning.
The next few postings will be the deployment of a simple computational engine that provides Saas to an activityML lesson.
Some Old News
moved from any2any.net site
[2005]
myAirport
destination-to-destination travel management - courtesy of myAirport
Locating in Chek Lap Kok, Hong Kong International Airport (HKIA) is now one of the busiest airports in the world. With the rapid growth of passengers and cargo throughput, baggage handling becomes an important issue for airports like HKIA. According to a report of SITA Corporation released on March 21, 2006, deliver-return of mishandled baggage costs the industry an estimate of US$2.5 billion in 2005. Would RFID technology help to reduce the number of re-handled bags, at the same time, addresses other value-added services to boost passenger throughput? HKIA's current RFID adoption in their baggage handling system (BHS) provides us the following view:
The HKIA is fast becoming myAirport to all – providing a window for passengers’ personalized preference to “travel” with their bags. myAirport knows how bags should be handled at the destination. Tagging can even be applied to boarding passes – virtually tagging the passenger and then renewing these every leg of the trip. With each swipe of the boarding pass at critical points, myAirport provides personalized services to customers. Extending the adoption across AA’s at destinations, the boarding pass can be invalidated or re-validated at different preference levels. myAirport continues at a transit airport as bags are ready to be cleared upon check-in by simply passing through any of the check-in points, not necessary the designated airline counter. Moreover, further customizations can be done at customs and immigration check points.
As third-party airport service providers enter the myAirport realms across the globe, specialized services can be pre-arranged at customers’ fingertips. They can have a designated bag to be stored at the airport for the third leg of their travel (e.g., they leave their business bags as the third leg of the trip is for pleasure), or they may request special luggage handling service at that airport before the start of their journey. That airport is myAirport. Furthermore, customers may leave instructions with the airport, and myAirport will route their exact RFID-tagged bags to their hotel via courier, as if myAirport recognizes their bags personally.
The adoption of RFID technology by the HKIA is in itself a deed not viewed favorably by many. We are well aware of the dialectic views on RFID technology. However, it is the holistic benefits of the industry as a result of adopting RFID technology that may silence critics and convince doubtful bystanders. Particularly, we believe that the HKIA has taken a first bold step many people have shunned or voted down. However, this is a step that is perceived functionally to be at par with the existing bar code system. Hence, we will learn from the experiences – business, managerial, and technical, and now the opportunities ahead towards myAirport which is a personalized destination management, where each airport adapts to customers’ needs, providing them with an integrative destination chain likened to a supply chain that knows exactly what end-customers want. Each airport is myAirport, and here, customers are treated appropriately, and their bags are handled accordingly, just as each supply chain partner deals with customer orders as their personal order, ensuring coordination with the upstream partner and cooperation with the downstream partner.
It may not yet be time to celebrate about the future of myAirport, but it is definitely time to learn from HKIA’s RFID implementation, taking the same road not simply to replace the “working” barcode BHS system, but to be open to and be ready for the vision of myAirport – facilitating the transformation of the anonymous traveler to the traveler with identity!
Privacy & Security Issues in EPCglobal Network
can I read the tag information on your cellphone and find out your birthday in EPCglobal Network?
One research project is currently at the stage where findings in privacy and security issues will have to be addressed with respect to the EPCglobal Network as proposed by EPCglobal. The discussion given here is based on the information provided in the document, "The EPCglobal Architecture Framework," Final Version as of 1 July 2005, published by EPCglobal. The framework is described in "an open and vendor neutral manner," can be implemented with no implied platform, is designed to be extensible and scalable, secure and privacy-ensured.
The framework consists of "EPCglobal Standards," based on which 'core services' are built. These services are to be "operated by EPCglobal and its delegates" - collectively referred to as "EPCglobal Core Services." Users of these services are driven by the fact that EPC (Electronic Product Codes) are adopted in their business environment. The specific goal is to enhance the supply chain, thus users are likely partners [the term "trading partners" was used] in supply chains. These users are one type of 'end-users', while the other type of end-users are the solutions providers. Standards entails hardware, software and data interfaces, e.g., RFID tag, protocol, and middleware such as Savant's. Core services, e.g., include ONS (Object Name Service).
We now discuss information sharing among partners in a supply chain. The context of discussion is of supply chains, but not"supply chain network." As partners adopted EPC for goods to facilitate management of the physical flow, data of goods can be correctly obtained. As these end-users become part of this EPCglobal infrastructure (standards, services, and EPC), the operational effect is viewed as a EPCglobal Network. As data filters into the centralized EPCglobal, services are offered for end-users to access the data accordingly, or pipe the data into solution providers to obtain target business information.
Different classes of RFID tags (UHF and HF) are defined. The Auto-ID Center originated UHF Class 0 Gen 1 and UHF Class 1 Gen 1 specifications [RF Protocol] (November 2003) are now superceded by EPCglobal's UHF Class 1 Gen 2 specification [Tag Protocol] (December 2004). With 'EPC Tag Data Specification' also ratified, the remaining components in this framework are either in development, or TBD. The security issues need to be identified and the privacy policy needs to be formulated according to established theory or best practices. In both situations, the enforcers have just to be determined, be it embedded components, agents or entitlement services for on-demand privacy and security preference as we propose.