CSI 2004
“If you have great engineers and you have capital and
entrepreneurial skills, you've got to eventually get some
successes. I expect in the next couple of years there could
be an Indian software company that has a household name
in the U.S.”
– James Governor, Illuminata Analyst, Mar 2002
.
… The Opportunity for the Indian Software Industry!
CSI 2004
Tutorial on:
Middleware & Web Technologies
Ramesh Loganathan, VP Engineering,
Pramati Technologies
Speaking at CSI 2004, Mumbai
Scope of this Tutorial
• Overview of the Middleware & Web Technologies
– State-of-the-technology 
• Briefly trace the functional Evolution
• Understand the J2EE Space
– The standards and the Application models
• Glimpses into Current Trends
–
–
–
–
Service Oriented Architecture
Enterprise Services Bus
B2B Collaboration – Ebxml
Grid Computing
3
Outline
•
What is middleware
– RPC & EDI; Advent of the web
•
•
Anatomy of a middleware request - RPC basics
J2EE – Evolves with Web
– Web; EJB;JMS & MDB
•
•
•
J2EE Tech Trends
Web Services
Service Orientation, Integration & ESB- the next wave
– SOA; JCA; Adapters
– Ebxml
– ESB- Enterprise Services Bus
•
Case study:
Dashboard- how XML based minimal data exchange is used for live
monitoring of real-time data changes
4
CSI 2004
So.. What is Middleware?
What is Middleware
Remote Procedures/Objects
J2EE- Evolves with Web
Web Services
SOA & ESB
B2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
The Changing Landscape
Client-Server
The Desktop
TheThe
Distributed
Web Application
Client
Client
Internet
LAN
Web
Server
Database
Server
6
Moving to Server Helps...
• “Power” components no more limited by client
capability
• Pooling, sharing of scarce resources now possible
from server-side
• Replication and distribution of application
• High scalability
• Design efficiency only limit to performance
• Support hundreds to millions of concurrent users
– Incremental support from server-side for
increasing number of concurrent users
7
…Multi-tier?
• Simplify the enterprise application scenario
• Remodel application development in three tiers
– Tier I: Presentation Logic Layer
– Tier II: Business Logic Layer
– Tier III: Data Access Logic Layer
• Move business and data access logic to same/separate
servers
• Keep only presentation logic on Client
8
...But new challenges appear
• Middleware systems are complex
• To build a proprietary middle-tier framework,
considerations are:
–
–
–
–
–
Multi-threading
Resource sharing
Replication
Load balancing
Various services to be able to work with each other
• Compatibility with widely heterogeneous middleware
services
9
Solution: the application server
• Application Server Sits in the middle tier
• Automates complex multi-tier features
• Manages, recycles scarce system resources
– processes, threads, memory, db links, network sessions
• Load balances to share processing across multiple systems
• Access to infrastructure services
– naming/directory, txn, persistence, security
• Specific runtime environment
10
Where it fits in
Client
Internet
Client
LAN
Web
Server
Application
Server
Database
Server
11
Options in the market
• Common Object Request Broker Architecture (CORBA)
• COM Architecture (M Transaction Server)
• Java 2 platform, Enterprise Edition (J2EE, whose core
consists of Enterprise JavaBeans)
Which do we choose?
We Chose J2EE! 
12
CSI 2004
Basics: Remote Procedures/Objects
What is Middleware
Remote Procedures/Objects
J2EE- Evolves with Web
Web Services
SOA & ESB
B2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
What are we trying to achieve?
• Distributed applications
– Applications that exist on different machines and provide useful
functionalities
Machine1
Machine2
Machine2
A way of using such applications from another application!
14
Middleware systems?
• A connectivity software
• Provides set of services to enable multiple processes on
different machines to communicate.
• Promoted by
– Object Management Group(OMG) [CORBA]
– Sun/IBM etc [J2EE]
– Microsoft [COM/DCOM]
A set of distributed software between Application/OS/Network
15
Middleware continued…
Application
Application
API’s
API’s
Middleware(Distributed System Services)
Platform Interface/ JVM
Platform Interface/ JVM
Platform / OS
Platform / OS
Middleware provides communication between distributed applications.
16
Middleware services
• To locate transparently another application across the
network providing the required interaction
• To be independent from network services
• To be reliable and available
• Scale up in capacity without loosing function
Keywords: Integrity, Reliability, Scalability, Security, Manageability
17
Middleware types
•
•
•
•
•
Transaction processing (TP) monitors
Remote Procedure Call (RPC)
Message-Oriented Middleware (MOM)
Object Request Brokers (ORB)
Remote Method Invocation (RMI)
Examples: J2EE, CORBA, JMS etc.
18
TP monitors
• Tools and environment for developing and deploying
distributed applications.
• Manage Transaction
• Load balancing and failover
• Usage
– Data management
– Network Access
– Security Systems
• Vendor specific
• Detail coverage in Seminar
One of the topics for seminar
19
Remote Procedure Call (RPC)
• Enable the logic of an application to be distributed
across the network.
• Program logic on remote systems can be executed as
simply as calling local routine.
RPC runtime
RPC Runtime
Application
Client
Server
20
Message-Oriented Middleware (MOM)
•
•
•
•
Program-to-program data exchange
Asynchronous – No wait after message is sent.
Analogous to e-mail
Recipient interprets the message and take appropriate
action.
MOM
message/data
sent
Application1
message/data
delivery
Virtual Connection
Application2
21
Object Request Broker (Orb)
• Interface definition
• Location and activation of remote objects
• Communication between clients and objects
ORB
locate
service
Client
Application
establish
connection
communicate
activate
service
Remote Service
(Object)
22
CSI 2004
Overview of J2EE
- Evolution with Web
What is Middleware
Remote Procedures/Objects
J2EE- Evolves with Web
Web Services
SOA & ESB
B2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
What is J2EE
• Java™ 2 platform, Enterprise Edition
• Middleware layer on top of standard Java
• A set of specifications
– Collectively drawn up by companies like Sun, IBM
– Pramati a member of the standards body for 5 years
• A definition of how middleware should work
• Independent vendors build application servers using J2EE
standard
• Application server is central to all browser-based
applications
– e-commerce, e-business, e-governance, web services
24
The big picture..
25
Why J2EE
• Open standards driven by a rich community process
– Ground-up industry support with no vendor lock-ins
• Significant market awareness and popularity
– Large-scale adoption
• OS and hardware independence
• No application boundaries - Web interface
• Reliability, scalability and re-usability
– Component model on top of object model
26
Enterprise Platform Evolves
CSI 2004
HTTP Server
Java Clients
Transaction
Service
Resource
Service
Naming
Service
Load
Balancing
Web-based Administration
via JMX Console
Cluster
Manager
Remote Admin
SFS
CORBA
Clients
Resource
Pooling
JMS Server
(Async Messaging)
Enterprise Java Applications Elsewhere
Mainframes
Lifecycle
Handling
LDAP
Fail over
MDB
Connector API
DB
Connectivity
Persistence Management
Legacy Applications (like ERP)
Session Management
Enterprise JavaBeans
Mail
Server
Web
Browsers
RDBMS
Servlets
Enterprise Level Security
Framework
JSPs
HTTP Server
Java Clients
JMS Server
Asynchronous Messaging
Fail over
Load
Balancing
Persistence
Management
EJB
Container
Lifecycle
Handling
Cluster
Manager
Resource
Pooling
LDAP
Remote Admin
Enterprise Services
SFS
CORBA
Clients
Session Management
Mainframes
Web Container
Enterprise JavaBeans
Legacy Applications (like ERP)
Servlets
DB
Connectivity
Mail
Server
JSPs
Resource
Service
RDBMS
Transaction
Service
Connector API
Naming
Service
Enterprise Level Security
Framework
Web
Browsers
Complete Enterprise Runtime
Environment
Web-based Administration via JMX Console
Enterprise Java Applications Elsewhere
28
J2EE Market Acceptance
52.38%
of Survey
Respondents
J2EE and MS.NET
Development
MS.NET
Only
14.29%
of Survey
Respondents
J2EE
Only
33.33%
of Survey
Respondents
29
J2EE: Where does it fit
Your Application
Web
Browser
Database Server
J2EE Application Server
Java (free)
Operating System
Multiple
choices
WebLogic/ WebSphere/ Pramati
30
Preserve your freedom to choose
MacOS
Solaris
HP/UX
Linux
Windows
Any OS
MySQL
Oracle
SQL Server
Any Database
Sybase
Any Hardware
Your Tools
Intel
HP PA-RISC
Sun Sparc
DB2
All Clients
Eclipse
Rational
JBuilder
Pramati Studio
Netscape Mobile Phones
Internet Explorer
31
Technology Trends- 2004
•
Web based application architectures
• Internet or Intranet de-facto part of App Architectures
•
Component based Applications
• Biz App broken down into smaller units
• Easier to manage, deploy and maintain
•
Web Services
• Extended Enterprise
• Across the Enterprise and between Enterprises
•
Access from Mobile Devices
• J2ME
32
J2EE in 2004- Enterprise wide computing
• J2EE 1.4- next iteration of the technology
– EJB 2.1
– Improved Servlet & JSP specs
– Web Services
• ebXML
– Workflow
– Security
– Transactions
• J2ME/ Wireless devices
– Elaborate set of specs to enable J2ME to J2EE integration
• Grid Computing
– Extended clusters- better server resources utilization
33
CSI 2004
SOA, Integration & ESB
What is Middleware
Remote Procedures/Objects
J2EE- Evolves with Web
Web Services
SOA & ESB
B2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
An ESB is a standards-based, service-oriented backbone
capable of connecting hundreds of application endpoints.
A highly Scalable platform.
ESBs combine messaging, Web services, XML,
data transformation and management to reliably connect
and coordinate application interaction.
35
Enterprise IT- integration using ESB
User
ESB Process
ESB Bus
Write “new” ESB
service ground-up
Java/
J2EE
Legacy
XSLT/
Xquery
DB
Wire “existing” WS
off the net
“Wire” legacy fn() as
service onto ESB Bus
SAP
COBOL
.NET
Off
UDDI?
WSDL
J2EE
36
What Is ESB?
• ESB- Enterprise Services Bus
• A Distributed Runtime platform for Services/Integration
• Provides an integration infrastructure (consistent with SOA)
• Transparent & multiple communication protocols
• Service messaging and interfacing model
• Open and implementation-independent
• Service and Consumer distinctly separated
• Service definitions relatively coarse-grained
• Location-transparency and interoperability of Services
• Should isolate application code from the specifics
• Unaware of routing services and transport protocols
• Allow service implementations to be substituted
• Manage service infrastructure
• in the distributed, heterogeneous environment of today
37
ESB vs. Integration
• Why ESB is different from EAI
– EAI is more focussed on just “connecting” to the back-ends
• The shortcomings of a simple Integration approach
–
–
–
–
Orchestration is programmatic
Implementation Tightly bound to back-ends
Maintenance gets complicated
No inherent distribution of the Integration Tier
• All orchestration & back-end access logic localized
– May have scalability limitations
• Solution: ESB
38
Quick Peek
ESB’s internal Transport could be
one or many. But, transparent to Apps!
Evolution: http://www-106.ibm.com/developerworks/webservices/library/ws-esbscen/
Overvew: http://www.nwfusion.com/news/tech/2003/0602techupdate.html
39
Sample Scenario..
40
Why Web Service is NOT ESB
• SOAP/HTTP is just point-to-point integration
• No administration capability to control service addressing
and naming exists
• Service names are controlled individually by each adaptor
• Service routing not evolved WS-Routing)
• Control is dispersed between various components
• Upside- will work well on internet & heterogeneous infra
• Harder Service Implementation dependency
• Difficult to substitute service implementations
• Though- possible with UDDI abstracting the service
location
WS is one “component” of ESB
41
Key Services in ESB
• SOA implementation
– “Services” tie into the “bus”
– Support for standards
• “Bus” services
– XML support
– Transformation
– Intelligent routing
Legacy Systems to Connect
• DBMS access
• Legacy systems
–
•
EAI Adapters
–
•
CICS;IMS;Tuxedo
JCA; Custom;
Application servers
–
–
J2EE Servers • Other
‘standards’
.NET ; COM / CORBA
• Communications services
–
–
–
–
Asynchronous/Messaging
Pub / Sub
Store and Forward
JMS-based
• Orchestration & Collaboration
• Canned Services/Utilities
Enterprise Class Security
• Access control
–
–
–
•
Information security
–
–
•
User authentication
Component
authorization
Non-repudiation
Privacy (encryption)
Integrity checking
Secure Communications
42
Typical Flow- Developer adopting ESB
Service Design/Definition
Service Definition
•Service Name+Type
•Service Contract
•Service properties
Service Implementation
•Details based on type
•Write Java/Xquery/..
Service Simulation
•Based on Contract
•For testing process without
service implementation
Write ESB ‘app’
Define ESB Process
ESB Invocation
•Decisions
•XPath
•Call Services
•Custom Services
•Web Services
•DB Services
•XML Services
•Transformation
•XSLT
•Xquery
•SubProcesses
•Collaboration steps
•Simple Clients
•Invoke an ESB Service
Services ‘wired’ into process
•Invocation mapping
Can Define Services on the fly
•As Process is defined
•With or without service details
43
Inside JBI
44
SOA & ESB- Standards At A Glance
ebms
Orchestration
WS-BP
ebxml
BPEL
Collaboration
rosettanet
Ws-rm
Messaging
JMS
WS-RM
Ws-S
SOAP
Internet
Partner
Organizations
Service Containers
JBI
WSDL2
JCA
J2EE
Legacy Systems
.NET
45
JBI: Service invocation
Process
Service
Service Invocation
• All Services used in the
Process will have common
interface
– XML in
– XML out
– WSDL2 based contract
• Service implementation is
abstracted out from
Process definition
Map Process variables
onto Service contract
Input Contract (specified per WSDL2)
Service Impl
Extract required Vars from Input
Actual Service
(Java, DB, XQuery,..)
Place Output values
Output Contract (per WSDL2)
Copy output onto
Process variables
Service Return
46
CSI 2004
SOA- Collaboration Beyond the
Enterprise
WS for B2B, Ebxml
What is Middleware
Remote Procedures/Objects
J2EE- Evolves with Web
Web Services
SOA & ESB
B2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
ebXml (upcoming) specs at a glance
Ebxml- BSI
Ebxml- RS
(Biz Service Interface)
(registry services)
Ebxml- BP
(Biz Process)
Ebxml- BPSS
(Biz proc schema spec)
Ebxml- CPPA
Ebxml- MSG
Ebxml- RIM
(registry info model)
Ebxml- MSH
(msg srvc Handlers)
CPA- Collaboration partner Agreements
CPP- Collaboration partner Profiles
48
ebXML Functional Service View
Business Process and Information Models
(Compliant to the ebXML Meta Model)
• Functional capabilities
Model to XML Conversion
• Business Service Interfaces
Registration
Retrieval of Profiles &
new/updated ebXML Models
Retrieval of Profiles &
new/updated ebXML Models
Registry Service
Interface
Register
Collaboration Protocol
Profile(CPP)
Register
Collaboration Protocol
Profile(CPP)
Retrieval of ebXML
Models and Profiles
Internal
Business
Application
Build
Implementers
CPP
Collaboration
Protocol
Agreement(CPA)
Business Service
Interface
Internal
Business
Application
Governs
Business Service Build
Interface
CPA
• Protocols and
Messaging Services
Registries
Payload
49
WS, ebXML & J2EE/ arch scenario
ebXML
SOAP
ebXML
MSH
Legacy
Apps
EJB
Business
Services
Internal
Firewall
ebXML
Process
Server
Business Process
Collaboration
EJB
Business
Services
DB
Orchestration Services
J2EE Application Server
Container
COTS
Apps
Legacy
Apps
Apps
J2EE Web
Container
Systems Interface
ebXML
BSI
DMZ
Internet
B2B—
Trading
Partner
CPA
BPSS
50
How ebXML works?
• ebXML is a messaging infrastructure:
– defining a reliable business message based communication
protocol.
– The protocol can be used to carry any third-party payload (i.e.
business document) for business transaction
– such as purchase order and so on.
• The complete protocol suite consists of:
– 1. Message Service (ebXML MS)
– Msg Service Handlers- ebXML MSH
– 2. Collaboration Protocol Profile/Collaboration Protocol
Agreement (CPP/CPA) ebXML-CPPA
– 3. Registry (ebXML-RS)
– 4. Business Process Specification Schema (ebXML-BPSS)
– 5. Core Component
– The above 1, 2 and 3 are under OASIS's development, while
– 4 and 5 are under UNCEFACT/ebTWG.
51
CSI 2004
Some Buzz.. : Grid Computing
Case: J2EE Grids
What is Middleware
Remote Procedures/Objects
J2EE- Evolves with Web
Web Services
SOA & ESB
B2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
J2EE Beyond 2004
• J2EE 1.5 (5.0)
– EJB3
– Java Metadata driven (no painful XMLs)
– Better Persistence
• Service Oriented Architecture
– Mainstream Acceptance
• Enterprise Integration
– ESB- Enterprise Services Bus
– ebXML
• Grid Computing
– J2EE Grids
– Utility Grids
53
WS, ebXML & J2EE/ arch scenario
ebXML
SOAP
ebXML
MSH
Legacy
Apps
EJB
Business
Services
Internal
Firewall
ebXML
Process
Server
Business Process
Collaboration
EJB
Business
Services
DB
Orchestration Services
J2EE Application Server
Container
COTS
Apps
Legacy
Apps
Apps
J2EE Web
Container
Systems Interface
ebXML
BSI
DMZ
Internet
B2B—
Trading
Partner
CPA
BPSS
54
Onto Grids.. What is Grid Computing?
• Common definition of grid:
• Loosely coupled autonomous ‘cells’
• Each cell has independent existence
• Geographically distributed
• Parallel and/or distributed
• Flexible resource selection & usage
• Each cell specifies the availability, performance & Cost
• The ‘consumer’ chooses. ‘Quality of Service’ primary basis
• Each ‘cell’ manages its own resources
• No single ‘system’ or ‘central manager’
• Resources & Consumers join & leave the grid at will
• "A computational grid is a hardware and software infrastructure that
provides dependable, consistent, pervasive, and inexpensive access to
high-end computational capabilities” - Ian Foster
55
Grid Types- The buzz words..
•
•
•
•
•
•
•
•
•
Compute Grids
Data Grids
Science Grids
Access Grids & Knowledge Grids
Bio Grids & Sensor Grids
Cluster Grids
Campus Grids
Tera Grids, and
Commodity Grids.
And… Application Grids
56
Grids vs. Clusters
• Most server platforms offer Cluster Solutions
• Clusters are tightly knit
– Logically, a single “processing entity”
– Presents an integrated single view to the applications
• Central resource management
– Unlike in grids, where each cell manages itself
• Consumers of clusters are known in advance
– Grid consumers can tap into a grid dynamically- utility model
57
Where J2EE fits into Grids
• J2EE- complete enterprise application runtime
– J2EE is a well-understood Biz runtime
– Pure Standards- high level of compliance
• Well defined work-units
– Application Servers have well-defined work-units
• Unlike SETI or Globus type grids,
• Work-units are distributes across grid nodes
• In-built mechanisms to ‘locate’ components
– Say, EJBs thru the naming service, or web thru a LB
• Well positioned to form a good ‘grid-fabric’
58
Application Grids
• A grid of generic App Server cells (J2EE or .NET)
– Each cell is out of the box J2EE server- with any OS & VM vendor.
– The app server grid component will run on each cell
– Cells can go down and come up at will- grid will be unaffected
• The work-units that runs on the grid will be a J2EE app
– the grid presents one logical processing environment
– with a bunch of loosely coupled cells
• Load distribution & fail-over dynamically managed by the grid
• No single point of failure in the grid
– the app server will manage the grid abstraction
• Applications available on the grid
– Distribution strategy specificable (what app available on how many
nodes)
• Scheduling & Provisioning managed by the grid
59
J2EE Grid Constituents
• The grid can be composed of the following node types
– Standalone servers; J2EE (web+ejb) nodes
– Web nodes; EJB nodes; JMS server nodes
– Web Loadbalancer
• Implicit Service/framework components
–
–
–
–
Grid aware naming service
Application repository- what & where
Distributed Admin service- for remote administration
Cluster service- self-organising, app management, failover++
• Missing Pieces
–
–
–
–
Smart Provisioning
Ease of Management/Administration of the Grid
Binary management of all nodes on the grid
We need a Federated Naming Service and a Federated App
naming service.
60
J2EE Clusters- Very “grid ready”
• Most vendor’s Cluster solutions are “grid ready”
• Pramati’s clustering solution has all these attributes
–
–
–
–
–
self organizing cluster- nodes can join/leave at will
no single point of failure and no master
remote administration
Pure TCP connectivity between nodes
Load-distribution (scheduling)
• Single-click remote administration
– distributed non-master lock server and clustrer administration
61
J2EE ‘grid fabric’
• J2EE Grid-Fabric- a set of J2EE aware agents
– Much like the cluster service in today’s J2EE clusters
• Grid platforms have ‘agents’ at its core- as the ‘grid fabric’
– For discovery, resource management & scheduling
– Consumers, poll thru the agents
– Resources, notify availability and pick up work thru agents
• Scheduler- managed by the fabric
–
–
–
–
A basic load-scheduling mechanism
Scheduler can discover present ‘active ‘ cells
Distribute the load based on the Provisioning & QOS requirements
Partitioning of the grid for various apps
• specify %ge of resources or minimum num of actual cells per app
• get the resource partitioning at a logical level (grid as a whole)..
• .. without actually specifically marking out specific cells
• Manage resources- CPU, Memory, Object-pools, Persistence
62
What to expect
• J2EE Vendors extending to ‘grids’
– IBM, Oracle & Sun
• J2EE Grids will be relatively closer-knit
– Will not function in same mode as SETI
– Enterprises are wary of Application Security
• Value from J2EE Grids
– J2EE already popular
• Biz Applications widespread
• These apps can run as-is on the J2EE Grids
– Lower cost of ownership
– Higher availability
– Ready, reliable, Extendible Secure platform
63
CSI 2004
What we do in middleware space..
Pramati Products
What is Middleware
Remote Procedures/Objects
J2EE- Evolves with Web
Web Services
SOA & ESB
Middleware technology Trends
Pramati in Middleware space
Little about Pramati
The Vision
• Infrastructure products for global markets
– Excellence in Design and Execution
• Knowledge-based rather than cost-based
– Leverage India’s strengths and true value
– If we can do it in the Bay Area, we can do it here
• Invest in R&D for cutting-edge products
• Partner with the best, go to market together
The Result
• Global recognition of Engineering capability
• Technology leadership
• Talent Magnet
65
Key achievements
• Technology Intensive products
– Specifications still evolving
– Pramati a pioneer in server side Java space
• First server to Java Enable HTML (now, JSPs)- 1998
• First EJB1.0 implementation in 1999 (along with BEA)
• First J2EE 1.3 certified in Dec’ 2001
• Active in Standards Bodies
– Java community Process (JCP)
• Member of EJB & J2EE expert groups
– Standard Performance Evaluation Corp (SPEC)
• People: Full Product life-cycle expertise
– Strengths in Conception thru delivery, selling and support
– Only Indian company in the Infrastructure Products space!
• Process: Home grown
– Products development diff from projects
66
Product goals
•
•
•
•
Standards compliance > no proprietary lock-ins
Run time performance > best bang for the buck
Developer productivity > complexity suppression
Manageability > challenge of distributed systems
Object Designers
App Assemblers
System Admin
Java Designers
Project Managers
Database Admin
Web Designers
Create
Assemble
Deploy
EJB
Assemble
Deploy
JSP
Test
Monitor
Servlet
Package
Manage
Manage
J2EE Server
67
Design : Develop : Debug : Deploy
Model
Review
Create
Refactor
Test
Debug
Deploy
Manage
68
CSI 2004
Thank You
rameshl@pramati.com
www.pramati.com