WebSphere AS Architecture

Three-tier architecture

- Presentation Layer (Client)

- Application Logic Layer

- Network Resources

Packages

WAS-XD improves system availability, maintaining multiple instances of key components so that services can be switched from one server to another.

WAS-EE improve many different aspects of the network's operation. For example, the APIs included in Extended Messaging Support make it easier to deal with incoming asynchronous messages. Other extensions allow you to process query statements at runtime, support interruptible and compensated workflows, and manage transactions better.

WebSphere components

- EJB Container

- Web Container

- Application Client Container

- Applet Container

- Embedded HTTP Server

- Virtual Host (Fence off data, only makeing it accessible to resources installed on the same virtual host)

Support for EJB

- Local, remote, and message-driven beans

- Container-managed relationships and association relationships

- Portable finder query language

- Programming model

- Abstract and Concrete entity beans

- Local Home and Local Entity Interfaces

- EJB query language

Enhancement Features

- Changing semantic behavior

- Entity bean inheritance

- Optimistic concurrency control

- Read-ahead (minimize the number of database roundtrips by retrieving a working set of container-managed persistence (CMP) beans for the transaction within one query)

- Intent mechanism support

- Backend access support

- SQLJ

- Data caching

Enhance CMP performance

- bean data caching

- long lifetime caching

- optimistic currency control

- read-ahead

Activity Session (enables the user to group transactions into work units. You can associate various properties and configurations with an activity session)

Web Services Functionality

- Application lifecycle events

- autoRequestEncoding and autoResponseEncoding

- Classes and servlets

- Filters

- HTTP session support (in-memory, persistent-to-database, memory-to-memory)

Common Object Request Broker Architecture (CORBA) clients can access WebSphere Application Server CORBA C++ servers and WebSphere Application Server EJB servers. WebSphere also provides a basic CORBA environment that can bootstrap into the J2EE name space and invoke J2EE transactions. New support features include SSL security for CORBA C++ clients.

Web Service Support

- XML

- UDDI

- SOAP

- WSDL

Naming Support

- Instead of binding an object, it is bound to the server root context, or a context specific to the server associated with the object.

-Name Server runs in its own process instead of the administrative server's process

Changes to dynamic caching

- caching support (servlet and JSP results caching, command caching, pattern caching, and web services caching)

- dynamic caching engine (disk overflow, Least Recently Used (LRU), mgmt, XML cache policy mgmt, invalidation mgmt, and external cache support for IBM WebSphere Edge and IBM HTP Server Fast Response Cashe Accelerator)

- dynamic network caching (caching is performed within the context of J2EE and caching behavior is described in XML cache policy files)

- dynamic servlet caching (by configuring caching through the cachespec.xml file format)

I18N

- Change Currency

- Change character sets

Application and Service choreography

WebSphere Platform Infrastructure

- node

- configuration repository

- virtual hosts (is not linked to a specific node, it can be created, but cannot be started or stopped)

- admin service

- session database (for multiserver environment)

- scripting client

Network Deployment platform components

- Support multiple nodes. Each node has a node agent component and a number of application servers. These are all run within an administrative unit called a cell, which resides within the Deployment Manager. You can use a Network Deployment cell to configure clusters of load-balanced application servers.

- The Deployment Manager administers the configuration and application binaries of the components in a cell. They are divided out to local copies on each node.

Edge Components offer an efficient and economic means of hosting web-accessible content and providing Internet access. The software typically runs on machines that are in proximity to the boundary between an enterprise intranet and the Internet.

Edge Components include the caching proxy and load balancer, which help administrators to provide improved levels of service to internal and external users with access to documents on enterprise server machines.

A cluster is a logical arrangement of application server processes designed for workload balancing. Application servers that are part of a cluster are "members" of that cluster and must have identical application components deployed on them. Cluster members are not required to share any configuration data.

Cluster members can be situated on a single node (vertical cluster), over a number of nodes (horizontal cluster), or a mixture of the two.

Managed Servers or Processes

- Deployment Manager (Network Deployment Only)

- Node Agent (Network Deployment Only)

- Application Server (Base and Network Deployment)

- JMS Server (Network Deployment Only)

Network Deplyment

- Multiple WAS instances

1. Application Servers (multiple instances from a single installation of WAS)

2. Deployment Manager (multiple instances from a single installation of Network Deployment)

- Multiple server instances using a single installation (It is possible to configure multiple Deployment Managers for a single Network Deployment installation but these Deployment Managers are incapable of providing mutual failover or clustering support)

- Coexistence of WAS and ND

- Disadvantage: if something happens to either the WebSphere Application Server or Deployment Manager that results in the reconstruction of the node, the other component needs to be relocated

- A Single web server for coexisting, multiversion application servers on one machine

- A Single web server for multiple instances of WAS

- Standalone web servers for each application server instance when running multiple instances of WAS

Topology Considerations

- Availability (Horizontal scaling, Vertical Scaling, IP sprayer)

1. Hardware and process redundancy

2. Process Isolation

3. Load balancing

4. Failover support

5. Hardware-based high availability

- Maintainability (Inherent considerations for updating system hardware and software. Maintainability can clash with other topology considerations and can lead to shortcomings in throughput, performance, and availability)

- Performance

1. Vertical scaling: provision of software/application server failover as well as load balancing over a number of JVM application server processes. It enables an administrator to examine an existing application server for performance holdups.

2. Horizontal scaling: Creation of extra application server processes on multiple physical machines, harnesses additional processing power from each machine. This provides hardware failover support, and an administrator can apportion implementation costs among multiple physical machines.

- Security (A recommended security configuration is to use two firewalls to create a demilitarized zone (DMZ). Information in the DMZ is somewhat protected due to protocol filtering between the Internet and the DMZ. A web server can intercept requests and direct them through the next firewall. The vulnerable application and business data elements exist intthe space behind the second firewall, which filters by IP address or domain)

- Session Management

1. Database persistance

2. Memory-to-Memory Replication (replication of session data between the memories of individual application server JVMs. WebSphere internal Messaging is a JMS publish/subscribe mechanism that provides assured session replication between the JVM processes. It does this by leveraging the internal JMS provider provided with WebSphere Application Server and so a database product is not essential for persistence.

- Scalability (Configure multiple machines to boost processing power, enhance security, maximize availability, and balance workloads)

1. WebSphere Application Server cluster support

2. WebSphere workload management (WLM) (in front of clustering)

3. IP sprayer (Redirects incoming HTTP requests transparently from web clients to a group of web servers. Intercepts all requests and disseminates them to the full range of web servers in the group. IP sprayers such as Cisco Local Director provide scalability, load balancing, and failover for web servers)

Topology Terminology

1. Web Presentation Server Node

2. Database Server Node

3. Domain and Protocol Firewall Nodes

4. Directory and Security Services Node

5. Web Application Server Node

6. Web Server Redirector node and application server Node

7. Load Balancer Node

8. Deployment Manager

Supported Network Topologies

1. Vertical Scaling (multiple app server instances on a single machine)

2. HTTP server separation

2.1 Supporting Network Address Translation (NAT) firewalls

2.2 Preventing data access from DMZ

2.3 Underpinning load balancing and failover

2.4 Simplifying administration

2.5 Alleviating congestion

2.6 Supporting Secure Sockets Layer (SSL) encryption

3. Reverse Proxy (resides in DMZ and forwards traffic to and from a web server, which now resides on the same machine as the application server)

4. Multi-Tiered (Divides the application server processes into servlet application servers (close to HTTP server) and EJB application servers (close to application data). This is beneficial from security and performance perspectives)

5. Horizontal Scaling with Clusters

6. Horizontal Scaling with IP Sprayer

Simple IP Sprayer

Complex IP Sprayer

7. Multiple WebSphere cells

Advantages

1. Isolates hardware and software failure

2. Prevents outages

3. Improves Performance

8. Multiple Clusters on a node

Advantages

1. Enhanced throughput

2. Improved performance

3. Hardware failover

4. Application software failover

5. Process isolation

9. Combined

- Two WebSphere cells

- Two load balancer nodes

- Two HTTP servers for each cell with the web server plug-in

- Four application server machines for each cell

- The use of application server clusters for both vertical and horizontal scaling

- Two database servers for each cell, which host mirrored copies of the application database

Web Service Architecture and Models

Web Services Entities
- Provider Agent
- Requester Agent
- Discovery Service

Web Service Architecture Stack


Web Service Models



Service Oriented Model


- Is Concerned with the service provided and the actions necessary to provide it. A service is realized by an agent and used by another agent. Services are mediated by means of the messages exchanged between requester agents and provider agents. A service offers real-world functionality and is owned by a person or organization


Resource Oriented Model


- Is concerned with resources that are available over the Internet. The owners of a resource are responsible for ti. The resource-oriented model specifies the relationship between owners and resources


Policy Oriented Model

- Is concerned with constraining how agents and services behave. Policies are implemented to address concerns about quality of service, security, application, and management.


Message-Oriented Model


- Is concerned with the messages that are exchanged by web service agents. It focuses on their structure and how they are transported. It is not concerned with their significance.


Message Exchange Patterns
- request-response
- one-way request (from requester)
- notification (from provider)
- solicit-response (provider to requester and back)


SOA Roles
- Service Requester
- Service Provider
- Service Register


SOA Operations
- Publish
- Find
- Bind


Web Service Design Stages
- Vision document
- Conceptual Design
- Logical Design
- Physical Design
- Architecture (how to connect and installed)
- Security Design (Authentication, Privacy, Authorization)


Web Service Design Options
- Synchronous or asynchronous Communication
- Session State
- Transactions (actions in a group. Time-stamped data to enable rollback across independent web services)
- Caching (expiration time must be set)

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










UDDI

Universal Description Discovery and Integration

Discovering web services
•Service registry
•Service discovery: simple discovery; sophisticated discovery; something in between
•With UDDI, services can be categorized, identified, and crosschecked against technbical specifications

Point-of-Offering
•The requester uses HTTP requests as the main way of retrieving a service description
•The advantage of WSDL repository is the possibility of additional features

Types of service discovery
•Static: happens at design time (in application logic)
•Dynamic: occurs at runtime. Application itself performs the find operation on the service registry to discover and bind to the web service

UDDI specification
•UDI information model (describes UDDI data structures)
•UDDI API set (publish information to and obtain information from a UDDI registry)

Core components
•businessEntity
•businessService
•bindingTemplate
•tModel















High-level overview of service discovery process
•The registry receives tModel descriptions
•The registry receives service descriptions
•tModels and business registrations are given unique keys and registered
•The registry is queried
•Businesses use registry data

Main types of UDDI registries
•The public UDDI Business Registry (UBR, operator node) – replicated with the other implementations on a regular basis. (IBM, Microsoft, SAP, NTT) (white page: company info; yellow page: categorize by products or services; green page: tech info such as binding)
•Private registries – for internal web services

UBR limitations
•Security issues
•No last updated info
•No info about the quality of web service
•Alternative to UDDI is Web Services Inspection Language (WS-inspection) [faster that UBR, but need to know where the service provider is; not a standard]
•Alternative directory structure (ebXML):

Data Structure (2.0)











businessEntity (white page)














businessServices (group of web services)












•identifierBag: unique id
•categoryBag: category (yellow page)












bindingTemplates and tModel













tModel: how service requesters can invoke a web service















•publisherAssertion
- Details about the relationship between two businessEntity element
- keyValue can be paent-child; peer-peer; identity







Relationship between WSDL and UDDI

Relationship between WSDL and UDDI
•WSDL:interface – UDDI tModel
•WSDL:service – UDDI businessService

API sets
•Inquiry API
•Publishing API
•Implemented as SOAP for HTTP
•Publishing API calls use SOAP over HTTPS
•Inquiry API uses SOAP over HTTP (query patterns: [browse; drill-down; invocation])

Publishing API calls
•save_buysiness
•save_service
•save_binding
•save_tModel
•get_assertionStatusReporty
•get_authToken: Called before information publish
•get_publisherAssertions
•get_registeredInfo
•Add_xxx; delete_xxx; discard_xxx; set_xxx

Inquiry API calls
•find_business
•find_relatedBusinesses
•find_service
•find_binding
•find_tModel
•get_xxx

Integrate Single-Sign-On Web Service with Business Objects InfoView (JAVA)

Step 1: Query SSO Web Service
queryWebService
public boolean queryWebService(java.lang.String sUserID,
java.lang.String sPassword,
java.lang.String sPortalPassword)Use application request info and user credential to authenticate the user
With Webservice is already initialized, query the webservice, using application request info and user credential to get user response object back. Return true if succeeded.


Returns:
boolean Status of user authentication.


Step 2 Get SSO Session ID
getAWSSessionID
public static java.lang.String getAWSSessionID(HttpServletRequest oRequest)Get AWS session ID. The AWS session ID is stored by SSO login page.
This method retrieves AWS session ID cookie by using specific cookie name. It also uses UTF-8 to decode the session id.


Returns:
String UTF-8 decoded session id
Since:
0.1

Step 3 Get User ID by session
getUserIDBySession
public java.lang.String getUserIDBySession(java.lang.String sAWSSessionID)
throws java.io.IOExceptionReturn user id if existing AWS session of application request info is authenticated.
If AWS session is found, the session id will be used to check against application request info. If the session is still alive on AWS server the user id will be returned for further application authentication.


Returns:
String User id in the session with application request info.


Step 4 Forward to Internal BusinessObjects Logon Page
request.getRequestDispatcher("/" + oPropertyLoader.getPropertyValue("BOLogonPage").trim()).forward(request, response);

Step 5 Initialize Business Object Session Manager
init
public boolean init()Initialize BOUserInfo. Not related to specific user.
This method initializes Property Loader and gets session manager


Returns:
boolean Indicates the status of initialization
Since:
0.1


Step 6 Get Business Object Server Logon Token
getLogonToken
public java.lang.String getLogonToken()Get user logon taken.
This method uses userid, password, cms and authenticatio type to get logon token. If the userid and password is in specified cms database, it returns the token, otherwise it returns blank string. It also save the infoStore object for future usage.


Returns:
String Logon Taken
Since:
0.1

Step 7 Logon to Business Object InfoView
sHomeURL = oPropertyLoader.getPropertyValue("ServerURL") + oPropertyLoader.getPropertyValue("BoInfoviewString") + logonToken;
/*
* It is useful to store some frequently used objects in the session for
* easy access later on.
*/
// Store the IEnterpriseSession object in the session.
session.setAttribute("EnterpriseSession", oBOUserInfo.getEnterpriseSession());

// Create an IInfoStore object and store it in the session.
IInfoStore iStore = (IInfoStore)oBOUserInfo.getEnterpriseSession().getService("InfoStore");
session.setAttribute("InfoStore", iStore);
response.sendRedirect(sHomeURL

Microsoft SharePoint Services

2007 Microsoft Office System
- WSS 3.0 – Windows SharePoint Services V3.0
- MOSS – Microsoft Office SharePoint Server
- MOSS is part of 2007 Microsoft Office System (Desktop App: Access, Accounting, Communicator, Excel, FrontPage, Groove, InfoPath, OneNote, Outlook, PowerPoint, Project, Publisher, SharePoint Designer, Visio, Word; Servers: Forms, Groove, Live Communications, PerformancePoint, Project Portfolio, Project, SharePoint, SharePopint Server Search )

Operating System services:
- ASP.NET
- Windows Workflow Foundation

Enterprise Content Management
- More just managing documents in a library
- Per-item level permissions, recycle bins, full major/minor versioning, content types

Tiers
- Tier 1: Web Front End (WFE)
- Tier 2: Application tier
- Tier 3: Database tier

Deployment
- WSS 3.0 on single-server
- Onto multiple servers (server farm)
- Single server can host (WFE, application, database)

Site Framework
- Web-based application (under IIS)
- Site Collection (Sites)
- Site

Pages
- Master Pages
- Page Layouts
- Content Pages

Site
- Site Definitions – initial lists, libraries, views, Web Parts and pages (defined in XML files under SiteTemplates)
- Site Templates
- Features: Feature.XML

Storage
- Lists
- Libraries (physical document column)
- Different types (content type) of document in single libraries
- Library documents can be opened and saved directly from Office 2007 application

Administration
- Folders
- Recycle Bin
- AutoCopy
- List column limitation is 2000
- Generally, if display more than 1000 itemns in a single view, need to consider indexing certain columns

Versioning
- Major
- Minor
- Libraries support check-in and check-out

List Level Permission
- Manage Lists
- Override Check Out
- Add Items
- Edit Items
- Delete Items
- View Items
- Approve Items
- Open Items
- View Versions
- Delete Versions
- Create Alerts
- View Application Pages

Site Permission
- Manage Permissions
- View Usage Data
- Create Sbsites
- Manage Web Site
- Add and Customize Pages
- Apply Themes and Borders
- Apply Style Sheets
- Create Groups
- Browse Directories
- Use Self-Service Site Creation
- View Pages
- Enumerate Permissions
- Browse User Information
- Manage Alerts
- Use Remote Interfaces
- Use Client Integration Features
- Open
- Edit Personal User Information

Default Groups
- [Site name] Visitors - Read
- [Site name] Members – Contribute
- [Site name] Owners – Full Control

Authentication
- Active Directory
- LDAP
- SQL database
- Pluggable authentication is possible via ASP.NET provider model

SAP XI / PI Create Inside-Out Services

Overview



- Business application in java (POService.java) to handling purchase order requests
- Two Java bean classes for purchase order and purchase order line item (purchaseOrder.java, purchaseOrderLineItem.java)
- New->Project->Java->Java Project (yes to java perspective)
- Package: com.wavecross.sn.bl New->Package

Create a new Java class
Name: POService.java

package com.wavecross.sn.bl;
public class POService {
public POService() { }
public void handlePORequest(PurchaseOrder po) {
// process purchase data // ..
}
}

PurchaseOrderLineItem.java
public class PurchaseOrder implements java.io.Serializable { private String id;
private PurchaseOrderLineItem [] items;
private String buyer;
private String seller;
}

PurchaseOrder.java
package com.wavecross.sn.bl;
public class PurchaseOrderLineItem implements java.io.Serializable {
private String id;
private String product;
private String amount;
}

Both implement
java.io.Serializable
for Web Service usage.
The getter and setter methods
can be generated using the
context menu

Generating the Web Service
- Change Web Services Perspective: Window->Open Perspective->Java Explorer
- In context menu of POService.java, New->Web Service
- Enter WS name, modify config (SOAP)
- Wizard Created:
- Virtual Interface (VI)
- Web Service Configuration (WSC)
- Web Service Definition (WSD)

Activating and Deploying Web Service
- To deploy WS app to SAP WAS, first ensure connectivity info for J2EE engine is correctly set up.
- Window->Preference->SAP J2EE Engine
- The app can now be
- Deployed using the
- Deploy option in the
- Context menu of
- InsideOut.ear

Develop the Mediated Web Service
- Capture the WS metadata into SAP XI and then expose the metadata as a mediated Web Service
- Download WSDL using WebServices Navigator (used to view a listing of deployed WS in SAP WAS)
- Open: http://[hostname]:[port]wsnavigator/enterwsdl.html
- Click POWebService to see a overview
- Standard WSDL for all WS frameworks. SAP WSDL has additional features

Create Namespace in XI
- Design objects are built in Integration Builder: Design tool
- http://:/rep/start/index.jsp
- XI uses namespaces to avid naming conflicts. All design objects be part of Software Component Version (SCV)
- This is the only way by which the XI design objects can be shipped or moved from a dev system to a test system (SRM SERVER 5.5 SCV used)
- New namespace: http://yourcompany.com/xi/XI/InsideOut
- SCV context menu->Open

Create External Definition in XI
- SAP SRM SERVER->http://yourcompany.com/xi/XI/InsideOut->Interface Objects->External Definition
- Context menu->New->Enter SRM2SN_POService
- Select imported wsdl for Category (porttypes/POWSConfig_POWebServiceVi_document.wsdl
- Save and make a note of messages

Activate changes
- Objects edited or saved are not available for XI Integration Directory
- Changes must be activated
- Changed objects are organized by SCV in Change Lists tab

Create Message Interfaces in XI
- Message interfaces are the standard and platform-independent format for representing interfaces in XI
- XI is the broker, needs inbound and outbound interfaces. Modes: Synchronous or Asynchronous; types: Inbound, Outbound, Abstract
- InterfaceObjects->Message" hyperlinktype="url">InterfaceObjects->Message" target=_parent>http://yourcompany.com/xi/XI/InsideOut->InterfaceObjects->Message Interface
- New and enter name, select Category and Mode (Outbound)

Generate WSDL for Mediated Web Service
- All message interfaces can be exposed as mediated Web Services
- WSDL can then be used by clients to consume the Web Service
- Configuration objects are built in XI’s Integration Builder:Configuration tool
- http://[hostname]:[port]/rep/start/index.jsp
- Configuration objects to be built: sender and receiver Communication Channels, Receiver Determination, Interface Determination, and Receiver Agreement.
- After this, the Web Service Wizard can be used to generate the WSDL for mediated Web Service
- Tools->Define Web Service menu

- Specify the URL of Web Service
- http://[hostname]:[port]/XISOAPAdapter/MessageServlet/channel=[party]:[ServiceName]:[ChannelName]

- Make the selection
- Enter: Service-POService; Interface Name – SN_POService_Out; Interface Namespace – http://yourcompany.com/xi/XI/InsideOut

WCF

Overview
- Framework for Service-Oriented application
- API in System.ServiceModel namespace
- Unify distributed system technologies
- Single Window programming model for SOA
- Utilize .NET Framework

Fundamentals
- Set of APIs for sending messages between clients and services
- Unifies the features of COM+, .NET Remoting, MSMQ, Enterprise Services, Web Services(ASMX) and Web Service Enhancements(WSE)
- Interoperability with existing DSTs
- Built on .NET Framework
- .NET Framework through System.Net.Sockets.Socket and System.Messaging.MessageQueue etc.

Architecture

Architecture - Contracts

- Data Contract – Paremeters in message consumed by a service (metadata datatype)
- Message Contract – Message structure used for communication
- Service Contract – Service name, namespace and attributes
- Operation Contract – Member method of Service Contract interface returning operation type and parameters
- Service Runtime – Behaviors only occurred during operation
- Messaging – Formats and Message Exchange Patterns of the data
- Activation & Hosting – Either self-hosted or hosted in the contect of another application (EXE, Windows Service, COM+ component or IIS module)

ABCs

- Address – Identify Service
- Bindings – “Canned” Policies
- Contract – Expose Service

WSDL

WSDL describes
- What the service does
- Where it can be found
- How the service can be invoked

Two main elements
- Functional description: where, how and what of the service
- Nonfunctional description: why (service should be invoked); who (the service provider is)

- Root element is <definitions>
- Namespace URIs
- Use XML schema to describe datatypes

Abstract (service interface definition)
- Datatypes:
- Messages:
- Operations

Concrete
- Specific bindings:
- Service endpoint URLs:

Child elements of
- <types>(1): datatypes be exchanged in messages; no need if built-in simple XML schema datatypes used
- <message>: structure of message (parameters, return types); made up of (datatypes in )
- (1): web service operations (abstract interface definition); represented by (method); In WSDL 2.0, called
- : message encoding, transport protocol for
- : logical grouping of ports. defines service endpoints and associated addresses

<definitions>







<types>













<message> & <portType>















<binding>









In some cases, may be in interface definition. This is because Mbinding> is reusable when registering WSDL using UDDI









<service>








Across multiple files
Splitting documents into
- service interface definition: - placed on an established website that everyone can access
- Service implementation definition: - describes how the service interface definition has implemented at a specific network endpoint
* Ensure: with the same targewt namespace



SOAP fault msg, param in header














Fault information
- Abstract message format for error message
- Define fault Information in (regular message) or () or ( )
- <soap:header><soap:headerfault>








SOAP fault msg, param in header














Transmission primitives
- Request-response
- One-way operations
- Notification operations
- Solicit-response (endpoint “pushes” message and receive a correlated message)

Binding
- Using HTTP GET/POST operations
- MIME extensions