Web Services & TeachEngineering Case Study
- XML review:
- Question: Why is XML such an
important contribution to computing?
- Question: Name some XML
applications/formats?
- XML for validation of datasets or documents:
- An entire XML document can be read into a tree and stored
in memory; e.g., as a DOM object.
- When the tree is properly constructed; i.e., as a tree, the document
is
said to be well formed.
- Only well-formed documents can be reliably parsed ==>
XML makes things very rigid & predictable ==> easy on
programs to parse and 'take apart.'
- Question:
what
are some examples of a not well-formed XML tree?
- We can 'easily' build validators that act as 'gatekeepers,' preventing invalid
and/or not well-formed documents from entering our systems.
- Interoperability with XML & Web services.
- Traditional: Application X running on platform P cannot
(easily) communicate with application Y running on platform Q.
- Similar: Application X running on my computers does not have
access to service Y running on yours.
- Yet, we need to exchange information.
- So how to make these apps talk to each other?
- Proprietary data exchange standard (CORBA, COM, ActiveX, etc.)
- Web services:
Open (nonproprietary) standard-based data provider; e.g.,
HTTP/XML. Two types:
- Yahoo REST search service: http://search.yahooapis.com/WebSearchService/V1/webSearch?appid=foo&query=eggplant
- Note: XML & HTTP are 'open standards' maintained by W3C.
- ==> free, open and shared access and use of these
standards.
- ==> basis for consensus; general agreement on how to
exchange information.
- No need to access each other's core functions.
- 'Just' expose a Web service through a Web server.
- Once you have consensus, everyone can play; competition
is by product quality not by channel access.
- Example: www.teachengineering.org:
- Notice how all TeachEngineering documents are XML documents asynchronously contributed (checked into a repository) by different institutions:
- We can enforce document integrity (well-formedness & validityi) at the source!
- We can automatically notify contributors or errors & problems.
- We can easily 'pull out' the various components and index and render them.
- We can centrally control rendering conventions.
- We can manually make repairs (rare but very nice when needed).
- Notice how TeachEngineering
knows about search results in NSDL.
- Notice how TeachEnginering
knows about search results in TeachersDomain (RSS feed).
- Notice how NSDL
'knows' about TeachEngineering curriculum.
- Standard Alignment:
- Problem: Can
a teacher in Massachusetts use this curriculum as well?
- So how does TeachEngineering know that a specific item
of curriculum that was written for state X aligns with standards of
state Y?
- Solution 1: Align your curriculum to each and every
state.
- Solution 2: Standards crosswalking. If
standard X of
state P aligns with standard Y of state Q, then any curriculum that
aligns with X aligns with P.
- Syracuse University's Center for Natural Language
Processing (CNLP) offers Web services for solution 1 (CAT - Curriculum
Alignment Tool) and 2 (SAT - Standard Alignment Tool).
- But wait a second...
- Do all states have standards? Yes
- Are they different for each state? Yes
- So there is no coordinated effort between the states
to have one standard body? Indeed, there is none.
- And each state publishes its standards in its own
format on its own Web site? Yes.
- And how many standards do we have? About 60,000 for
math & science alone.
- And do they change often? States change their
standards about once every five years.
- Then how do TeachEngineering and CNLP know that they
are talking about the same standard?
- Because there is a third party (Jes&Co - ASN)
which makes available all standards in one, published and documented
XML(!!) format.
- So if TeachEngineering & CAT & SAT all use
the ASN standard identifiers, there is never a standard identification
problem.
- ==> Recall TeachEngineering making available
its metadata to NSDL?
- If NSDL also uses the ASN service,
TeachEngineering only has to communicate the standard identifiers and
NSDL can resolve them to text!
- ==> TeachEngineering, NSDL, ASN CNLP and
Teachers'Domain are linked together in a web of Web services.
- Consider the above diagram:
- Different computers and organizations provide different
services.
- The services are exposed through Web services.
- Each organization can call the other organization's
services.
- Each organization adds value.
- Each 'node' in the network is autonomous and knows what
to do when asked.
- Each node in the network has state, data and behavior.
- Question: Does this remind you of anything?
- Service-oriented architectures (SOA): division of
computational services over different computers, connected through
networks and communicating through Web services.
- Question: Can you see this concept applied between and/or within companies or information systems?
- Notice how in both the DLESE and yahoo requests the search
strings are passed through the URL ==> works well, but not very
elegant:
- Message reply is pure XML, but request is a mixture of
HTTP & XML.
- Whereas the full functionality of XML is available for
sending the message reply, it is not for the message request.
- In addition; the documentation of a REST Web service is
typically in natural language; e.g., English, and is stored
separately and independently from the Web service.
- How about an all-XML-based message protocol: message,
reply and documenttation all in XMl, all bundled together?
- Service-Oriented
(previously: Simple Object) Access Protocol (SOAP):
- XML specification for messaging (Web services) on the Web;
governed by W3C.
- Provides a structure for Web-based messaging; both
request
& response.
- All of the messaging carried by but not 'spread over' HTTP.
- Example (Snell, Tidwell, Kulchenko(2001) Programming Web Services with SOAP. O'Reilly):
- <env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<n:purchase
xmlns:n="soapPurchase">
<purchase_id>1234</purchase_id>
</n:purchase>
</env:Header>
<env:Body>
<n:purchaseOrder
xmlns:n="orderService">
<from>
<name>Mike Cook</name>
<dept>Cafetaria</dept>
</from>
<to>
<name>Mary Jones</names>
<dept>Ordering</dept>
</to>
<order>
<quantity>50</quantity>
<SKU><1001</SKU>
</order>
</n:purchaseOrder>
</env:Body>
</env:Envelope>
- Often used in conjunction with Web Services Description Language (WSDL).
- UDDI (Universal Description and Discovery Integration now defunct?):
- Web services registry/directory service (sponsored
by OASIS).
- Applications can
- Search the UDDI for applicable services,
- then use their WSDLs to find out how to use them,
- then use SOAP messages to use them.
