Session Date: April 10, 2006

1
Internet Supply Chain Management ECT 481
Spring 2006
Session Number 3

• Session Date April 10, 2006
• Session Outline
• Administrative Items
• Session Topics
• B2B Systems Architecture Key Technologies
• Architectural Considerations
• Design Development Processes
• Key Technologies
• Middleware
• XML
• Web Services
• XML Essentials

2
Administrative Items

• Project Info
• Team Formation
• Project Deliverables
• Technology Options

3
(No Transcript)
4
Architecture Design ConsiderationsEstablishing
a B2B System Technology Baseline

• Necessary B2B ecommerce system building blocks
• Hardware
• Software
• Policies
• Procedures

5
Fundamental B2B Extranet Technology Components

• Network (i.e., connection to the Internet
  backbone)
• Connectivity Equipment
• Internet Server Hardware and Software
• Application Server
• Database System
• E-mail Gateway
• Firewall
• Internet Server/Intranet Server
• Authoring/Web Development Server
• Browsers

6
Fundamental B2B Extranet Technology Components
7
B2B Extranet Technology Components (contd)
8
Web Site Technology Deployment Examples
Circa 2002-2003
9
End-user Experience Significantly Determined By
Browser
Browser Technology Compatibility
Partial support
10
Browser Options

• AOL, AOL-Compuserve, AOL-Netscape
• Apple Safari
• IBM Home Page Reader
• iCab
• Konqueror
• Lynx
• Microsoft Internet Explorer, Microsoft MSN-TV
• Mozilla, Mozilla Camino, Mozilla Firefox
• OmniWeb
• Opera
• W3C Amaya

11
Recent Browser Market Share
Browser market share in July 2005 IE -
87.2 Firefox - 8.07 Safari 2.13 Netscape
1.5 Mozilla Suite - 0.52 Opera - 0.49 Other
0.09 NetApplications August 12, 2005
12
Client Side Technologies

• CSS
• JavaScript
• VBScript
• DHTML
• Java
• Flash

13
Server Side Technologies

• CGI
• Server Side Scripting languages
• ASP
• PHP (or Hypertext Preprocessor)
• JSP
• MySQL
• ColdFusion

14
Server OS - Scalability is the Primary
Consideration Despite Pros Cons
Pros
Cons
Commercial Unix
High reliability and scalability vendor support
professional services available
High cost few commercial applications growing
but still limited
Server OS
Apache-Linux
Low cost large numbers of developers innovating
choice of distribution community support
No accountability varying levels of quality.
NT-2000
High hardware support market momentum excellent
commercial software support.
Scaling limitations.
15
Web Development Software - Scalability is the
Primary Consideration Despite Pros Cons, Cont.
Pros
Cons
JavaScript
Allows for simple interactivity and dynamic
effects.
Divergence in standard across browsers harder to
learn than HTML.
Perl/CGI
Large installed base of developersmany
easy-to-use examples
Poor reuse CGI is slow, doesnt scale well.
Languages
Dynamic HTML
Extends HTML for more interactivity, better Web
page design
Incompatible implementations in major browsers
low penetration rate
XML
Will enable new markup languages better capable
of representing new types of media.
Standards still evolving Although being
addressed, security is an issue.
Cold Fusion
Strong development community allows for easier
databaseintegration inexpensive.
Requires proprietary application server.
16
B2B Extranet Systems Focus on Key Technologies

• Message-oriented Middleware
• XML
• Web Services

17
Middleware Overview

• Middleware Benefits
• Isolates business logic from communications
  logic.
• Enables loose coupling of processes and related
  applications.
• Manages system risk by isolating communication
  services in fewer, proven modules.
• Reduces development time.
• Reduces overall solution cost (potentially).
• Provides additional migration flexibility and
  functionality.

18
Middleware Overview - Middleware Alternatives
(continued)

• Message-Oriented Middleware (MOM) - software
  level services that enable inter-process info
  exchange on the same or different platforms.
• (This class of middleware (MOM) will be our
  focus.)
• Database Gateways DB products that provide the
  ability to access data on other platforms,
  transparent to the source datas physical
  environment and structure.
• Object Request Brokers (ORBs) - ORBs support the
  distribution of objects across an enterprise.
• Data Replication - technology that supports
  periodic synchronization of remote databases.
• Function-based (RPC-based) Middleware - a set of
  programming services that extend the familiar
  procedure call mechanism across the network.
• (Distributed) Transaction Processing Monitors -
  allows RPCs to be grouped into transactions,
  providing increased support for commit and
  rollback processing.
• Point-to-Point - Point-to-Point is the
  implementation of simple file transfer and custom
  application interfaces on a per interface basis.

19
Message-Oriented Middleware (MOM)

• MOM products can be broken into the following two
  categories
• Message Passing
• The direct exchange of information between a
  sending and a receiving process.
• Requires the sending and the receiving product
  to be available and connectable at message
  transmission time.
• Can be synchronous or asynchronous.
• Message Queuing
• Queues are used to support store-and-forward
  processing.
• Inherently asynchronous.
• Common uses
• Triggering events at remote locations or in
  external applications.
• Notifying users when something of interest to
  them occurs.
• May be used in conjunction with remote data
  access to tell application data is ready for it
  to retrieve.
• Primary Message Queuing MOM technology
  resource available to ECT 581 is Microsofts MSMQ.

20
Message Queuing MOM - MSMQ Concepts
21
MSMQ Message Queuing MOM - Mission Critical
Terminology

• Message a unit of information exchanged by MSMQ
  applications.
• Queue a temporary storage medium that stores
  messages passed between applications.
• Queue manager the process that manages the
  queues on a host processor.
• Transaction a logical unit of work that
  comprises one or more operations that all succeed
  or all fail.
• Source machine - the MSMQ independent client from
  which a message is sent.
• Target queue - the queue to which a message is to
  be sent.
• Destination machine - the MSMQ independent client
  or server on which a messages target is
  maintained.
• Sender - an MSMQ application that places messages
  in a queue.
• Receiver - an MSMQ application that removes
  messages from a queue.

22
MSMQ Concepts - Messages

• Message properties can be defined to control
  several messages characteristics including
• Message security,
• Source and destination info,
• Labeling, and
• Time-to-live
• Two types of messages supported
• Express messages stored in memory until they
  can be delivered.
• Recoverable messages not lost if a machine or
  queue crashes.
• MSMQ also supports transactional messages.

23
MSMQ Architecture

• Messages are kept in queues

MSMQ

• Queues are managed by queue managers

• Applications access MSMQ via a simple client API

Machine 1

• MSMQ enables program-to-program message queuing

24
MSMQ Application Model Summary

• Sender
• Opens a queue by name
• Creates message object
• Sets attributes such as body, timeout, delivery
  mode, response queue name, etc.
• Invokes send method on message object passing
  destination queue as a parameter
• Receiver
• Opens a queue by name
• Receives a message (or Peeks at a message)
• Sends any required response messages

25
XML Highlights

• A markup language for documents containing
  structured information.
• XML is really a meta-language.
• XML provides a facility to define tags and their
  structural relationships.

26
XML Timeline of Evolutionary Events

• 1980 - 1st draft of SGML specification is
  issued.
• 1986 - SGML made standard by ISO via ISO 8879.
• 1989 - Tim Berners-Lee proposes WWW.
• 1996 - XML working group formed 1st draft of
  XML std. released
• Cascading Style Sheets (CSS), level 1 spec is
  released.
• 1997 - HTML 4.0 appears.
• 1998 - XML 1.0 spec recommended by W3C working
  drafts for XML
• Linking Language (XLink), XML Pointer Language
  (Xpointer)
• are released CSS level 2 spec is released.

27
XML Distinctions from SGML HTML
HTML defines the look and feel of your document
in a reader or browser. HTML includes elements
like FONT, B, and I to define how the document
looks. With HTML, the browser itself doesn't
know or care what the document is. If you write
a recipe in HTML, the browser will not know that
it has a semantic difference from a list of stock
quotes. Using XML to markup your document, you
would tell the browser computer that it was
looking at a recipe or stock quotes. XML markup
would include definitions of the parts of the
recipe or the stock information. XML doesn't
come default with markup for recipes or stocks.
You write it yourself and include it in the
document. XML allows you to define what a
document is to the computer.
28
XML Essentials Documents, Elements, Attributes

• XML is specified in XML documents.
• Elements are the fundamental building blocks of
  XML documents.
• Attributes specify the characteristics of
  elements.
• XML documents are made up of markup and
  character data.
• XML markup is the instruction to the programs
  (for example, browsers) that process and build
  XML documents.
• Character data is everything else the content
  consisting of the text images that appear on
  the page.

29
XML Essentials DTDs

• A Document Type Definition (DTD) is a set of
  syntax rules for tags.
• DTDs tells you
• what tags you can use in a document.
• what order they should appear in.
• which tags can appear inside other ones.
• which tags have attributes.
• etc.
• DTDs were originally developed for use with
  SGML.
• DTDs can be part of an XML document, but it's
  usually a separate document or series of
  documents.

30
XML An Example

• Assume you have access to a computer that can
  make food
• The computer has stored in it the following
  details
• about the ingredients,
• how to cook things,
• how to serve, etc.
• Assume you loaded (scanned and OCRs) a text
  version of an old-fashioned, Good Housekeeping
  recipe,
• Without assistance, the computer will not be able
  to read and decipher it.

31
XML An Example (continued)
But if you gave loaded something like the
following, a smart XML parser in the computer
would know what ingredients to look for and then
know how to put them together and cook them.
Mix flour and salt.
Slowly stir in
water until dough is moist.
Put in microwave safe bowl.
Microwave
on
high for 10 minutesment

Dough
1
cup flour
1 tsp. ingredsalt 1/2
cup water

32
What is a Web Service?

• Exposes business functions and business processes
  over the web
• Combines component-based development and the web
• New breed of web application
• All of the above!

33
What is a Web Service?
When considering Web Services.. think
Distributed Application Services!
34
Evolving Trends Web Services

• A Web Service is programmable application logic
  accessible via the Web.
• - Microsoft
• Web Services are a new breed of Web application.
  They are self-contained, self-describing, modular
  applications that can be published, located, and
  invoked across the Web. Web services perform
  functions, which can be anything from simple
  requests to complicated business processes. Once
  a Web service is deployed, other applications (
  other Web services) can discover and invoke the
  deployed service.
• IBM
• Web services is nothing more than a moniker
  for big honking API.. Web services provide a
  standard way to discretely package anything (a
  DB, a specific query, some business logic), and
  make it accessible to anything else (another DB,
  a WAP-enabled phone, or an external business
  partners business logic).
• - Gartner

35
Evolution From Application Services to Web
Services
36
Web Services The Next Phase of the Internet
1995
2001
Concept
Communicating Web Services
Hyperlinked Web Pages
Requester Application
Provider Application
Requesting Page
Requested Page
Model
Standards
Flow of Information
Flow of Transactions
Enables
Result
World Wide Web
Worldwide Digital Economy
37
Basic Standards

• XML format for data exchange and description
• SOAP protocol for calling web services
• WSDL format for describing web services
• UDDI repository for registering and finding web
  services

38
Web Services Key Technologies Basic Requirements

• Key specifications and technologies when
  building or consuming Web Services addressing
  four basic requirements
• A standard way to represent data XML.
• A common, extensible, message format SOAP.
• A common, extensible, service description
  language WSDL.
• A way to discover service providers UDDI.

39
Web Services Key Technologies - Expanded

• XML (Extensible Markup Language) - mechanism for
  creating distributed processing web services.
• SOAP (Simple Open Access Protocol) - protocols
  for document interchange.
• UDDI (Universal Description, Discovery,
  Integration) phonebook for discovering
  available Web Services. Variants include the
  following
• DISCO (Discovery of Web services) MS current
  thinking about discovery of SOAP/web services
  proposes a way that information about web
  services might be embedded in documents and
  recovered by a user agent.
• ADS (Advertisement and Discovery of Services) -
  IBM current thinking to allow web service
  providers to advertise the availability of their
  services.
• WSDL (Web Services Description Language) -
  provides the contract or the definition of Web
  Service objects schema.

40
The Promise of Web Services

• Allow pieces of software written in different
  languages, or running on different operating
  systems, to talk to one another cheaply and
  easily.
• Allow applications running in different parts of
  an organization, or in different organizations,
  to talk to one another and/or exchange data
  easily and cheaply.
• Use universal and non-proprietary data standards
  so that integration between new pieces of
  software and legacy systems will be simple.

41
Consuming Registering a Web Service
42
Instead of Web Services, Why Not Traditional
Middleware?

• No middleware product is the clear winner.
• Requires compatible architectures.
• Requires object-model specific protocols .
• Difficulty in getting through firewalls.
• All major vendors support web services, whereas
  with middleware it is hit or miss.

43
Web Services Benefits

• Relies on ubiquitous web infrastructure
• Everyone is connected to the Net
• Uses commodity software
• Broad industry support
• High levels of abstraction
• Maps to any existing technology or platform
• Service-oriented architecture
• Integrate supply chains
• Eliminate duplicate data entry
• Direct connection to trading partner IT systems

44
Caveats Regarding Web Services

• Web Services is not a panacea.
• Web Services will be valuable, but implementing
  them won't be easy.
• No magic bullet here.
• Require clear goals, careful planning detailed
  execution.
• Standards are still in flux.
• Interoperability isn't automatic.
• Besides universally adopted XML, higher-level
  standards are required to make Web Services work.
  
• For example, two banks that want to communicate
  need more than XML.
• Might agree on a higher-level standard such as
  OFX (Open Financial Exchange).
• Achieving coordination agreement on high-level
  data standards is the single biggest difficulty
  Web Services faces over the near term.
• Expect Web Services to be adopted within
  enterprises first
• Coordination issues can be simpler in-house than
  those between organizations.

45
Web Services Impact on SCM

• Enables capability to efficiently expose same
  services to suppliers and customers.
• Can fine tune order fulfillment through
  ubiquitous heterogeneous alerting capability.
• Improves prospect for cost-effective and timely
  implementation of SCM eBusiness initiatives.

46
B2B System Architecture Evolution Future Stage
UDDI ebXML
Beyond Web Services
Process to Process Integration Customization
Architecture Model Peer to Peer
Pushing the complexity out to the endpoints
47
Next Session Highlights

• Initial Exam Preview
• XML
• XML as a Content Development Tool
• Internet-based Electronic Data Interchange (EDI)
• Syntax Document Structure
• Emerging Standards
• Next Session Reading Assignment
• Chapters 2-4 of the Fitzgerald text