Using SOAP

Message Framework
•Version 1.1
•Written in XML infoset

Principal features
•A message structure: envelop, body, header(s)
•A mechanism for data representation: data structures in XML (abstract data structure)
•An RPC mechanism: XML form in SOAP msg
•A processing model: rules that SOAP msg dealt with
•A protocol-binding framework: different transport protocols (HTTP etc)
•Extensibility mechanisms: place in header(s)
•An error-handling mechanism: fault messages can transfer error data


Features not supported by SOAP
•Activation: remote server object is activated only when a call to server is made
•Distributed garbage collection: disposal from memory of remote objects when local and remote reference are no longer active
•Message batching: grouping of multiple messages in to a batch and send to message dispatcher (use same TCP packet)
•Objects by reference: object resides on the remote machine

Syntax
•An envelope: entire SOAP message
•Message headers: supplementary information not part of the message itself
•Header entries: supplementary data (such as security or policy settings, extend basic functionality)
•Message body: holds message payload, follows the headers, if there are any
•Message payload: data or instructions in XML need to be passed. Can also be SOAP fault if an error occurs during processing


Message structure (data model)
•Simple-value node: incoming edges
•Compound-value node: outgoing edges
•A named edg is the equivalent of an XML element
























Encoding
•Provides a set of rules that translates a SOAP data model graph into XML code
•Transform grogrammatic entities (objects, arrays, variables, etc) into XML

Message Exchange Pattern (MEP)
•How SOAP message are exchanged between SOAP nodes
•Specifies number of messages inolved, where messages originate, and where they go
•Each SOAP binding must support at least one MEP


MEP type supported (SOAP 1.2)
•Request-Response: both SOAP message
•SOAP Response: requesting node sends an initial non-SOAP message; the responding node replies with a SOAP message. (respond to an HTTP request with a SOAP message)

Communication styles
•RPC: can be synchronous or asynchronous; no easy XML schema validation; data structure depends on structure of the method being called-limits the extent; tighter coupling between message structure and WS implementation code
•Document-style: can be synchronous or async; unencoded XML; XML schema validate; can be extended more easily

Transport bindings
•Infoset should be serialized using XML 1.0 serialization specification
•Bindings also use custom serializations (data compression, security)
•SOAP HTTP binding URI: W3C web site
•Java Message Service: guarantee arrival
•HTTPS: security
•HTTP: support both MEPs; encapsulated in HTTP request/response; SOAP Response MEP uses HTTP GET as request


HTTP
•HTTP binding can use the value held by Web Method (defined by SOAP 1.2) instead of the default POST method
•SOAPAction: custom HTTP header in SOAP 1.1; In SOAP 1.2 is replaced by media type application/soap+xml (can be used in HTTP Content-Type header)


Summary
Specification: processing model, data representation mechanisms, error-handling mechanisms, extensibility mechanisms, protocol-binding framework, RPC mechanism and SOAP-message definition.

Message Structure
•Not used to create application functionality
•But to transmit data or remote procedure calls in a technology-neutral way


Basic Structure
Java Class















Request / Response
















RPC Style SOAP
•Request – method: orderProduct;
•Serialized according encodingStyle
















•Response
•orderCode has return value
•orderTrackingURL is an out parameter (supplementary parameter)














Document-style SOAP
•Unencoded XML in SOAP envelope
•Header to connect the response


















Document-style Response
Header: same reference














Using headers
•Vertical extensibility
•Extend the messaging structure: additional metadata; (relatedto routing, message correiation, security, etc); middleware can define infrastructure headers (transparent to end application)
•Define orthogonal data: separate from, but related to data in body. (use headers to send extra data to accompany non-extensible body elements (useful for recipient application processing the message)


Using <Header>
Must be first child of <Envelope>



















mustUnderstand
•If not, send SOAP fault back



















Using intermediaries
•Horizontally extending SOAP message
Value-added services
•Securing message exchanges: encrypts, digitally signs
•Notarizing messages: make third party record of the interaction. (explicit intermediaries = client is aware when sending a message)
•Tracing messages: find out path followed, time of arrivals and departures and intermeiaries used.

Intermediaries Type
•Forwarding: SOAP node based on the semantics of message headers and forwards it to another node
•Active: performs additional processing not based on message’s semantics (eg. Encrypt a message even though none of the message’s headers specifically request encryption)

<Header> address to Intermediary

Role for next/none/ultimateReceiver intermediary
Relay: mast relay headers targeted

























Processing Model
•Determine the roles that apply to it: scan body & header
•Identifying mandatory headers: mandatory header blocks targeted at the node
•Generating faults, if necessary: if fails to understand, single SOAP fault with thevalue of set to
•Processing mandatory headers:also process nonmandatory SOAP header blocks
•Relaying the message


Fault structure
•Not only indicates error, but also the reason for the failure to the originator of the message


Fault message



Headers for faults
•<NotUnderstood>: response to @mustUnderstand
•Upgrade

Attachments and implementations
•Using SOAP to send binary data
•MTOM (SOAP Message Transmission Optimization Mechanism): how serialization method be used for SOAP over HTTP
•XOP (XML-binary Optimized Packaging): how binary data be serialized as XML
•SOAP Resource Representation Header
•WS-I Attachments Profile 1.0










JSR 168 (Portlet Specification)

What is The Portlet Specification?
The Java™ Specification Request 168 Portlet Specification (JSR 168) standardizes how components for portal servers are to be developed. This standard has industry backing from major portal server vendors.

• The portlet container contract and portlet life cycle management
• The definition of window states and portlet modes
• Portlet preferences management
• User information
• Packaging and deployment
• Security
• JSP tags to aid portlet development
















Container Contract
•init()
•destroy()
•processAction()
•render()
GenericPortlet can be extended (called by render())
•doView()
•doEdit()
•doHelp()

The processAction(), render(), and specialized methods called by render() accept portlet requests and response objects similar to those passed to the Servlet service() method. Using these objects, the portlet class can do the following:
• Maintain state and communicate with other portlets, servlets, and JSP’s using the portlet session facilities.
• Receive user input from forms displayed in the portlet.
• Create the content for display by the Portal desktop that is sent back to the client via the response object.
• Query portal and portlet state information.

Portlet Mode and Window State
•Portlet Mode – current mode (View, Edit, Help)
•Window state – Amount of portal page space assigned to a portlet (minimized, maximized, normal)

Portlet Preferences
•Name-value pairs.
•Access - PortletPreferences interface, getValues(), setValues()
•Validate – PreferencesValidator interface, store() method invokes validate()

User Information
•In deployment descriptor; unmodifiable Map object (retrieved through USER_INFO in Request interface)
•Packaging and deployment as WAR
•In addition to web.xml, has portlet.xml

Security
•Flag to restrict to HTTPS
•Authentication (user, role)

JSP Tag Library
•A JSP Tag library is included to help display portlet pages with JSP technology.
•For example, a custom JSP tag automatically declares the portlet request and response objects so they can be used within the JSP
•Another JSP tag helps construct URL’s that refer back to the portlet.

Initialization Sequence Diagram

SAP EP

What is an Enterprise Portal
- The portal offers a single point of access to SAP and non-SAP information sources, enterprise applications, information repositories, databases and services in and outside your organization—all integrated into a single user experience.
- Via SAP Portal Organizations can provide their employees, supply chain partners, customers, and other communities with immediate, secure, and role-based access to key information and applications across the extended enterprise.
- Enterprise Portal is a web based business-critical system
-- Integrated information view and business applications
-- Unifies and aligns people, information and business processes with Knowledge Management Systems and collaboration.
-- A collaborative environment

Classes of Portals
- Information Portals
- Functional Portals
- Industry Specific Portals
- Enterprise Portals

SAP Enterprise Portal Architecture & Technology

The portal platform contains the following components:
- Portal Server
- Content Management and Text Retrieval and Information Extraction (TREX) component of the Knowledge Management platform
- Connector Framework
- Unification Server

Entrprise Portal Building Blocks

Enterprise Portal – Functional Components