Embed Size (px)
Citation preview
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
3
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
4
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
CSI 2004
So.. What is Middleware?
What is MiddlewareRemote Procedures/Objects
J2EE- Evolves with WebWeb Services
SOA & ESBB2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
6
The Changing Landscape
The Desktop Application
DatabaseServer
LAN
ClientClientThe Client-Server Application
InternetWebServer
The Distributed Web Application
7
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
8
…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
9
...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
10
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
11
Where it fits in
DatabaseServer
LAN
ClientClient
Internet
WebServer
ApplicationServer
12
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?Which do we choose?
We Chose J2EE! We Chose J2EE!
CSI 2004
Basics: Remote Procedures/Objects
What is MiddlewareRemote Procedures/Objects
J2EE- Evolves with WebWeb Services
SOA & ESBB2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
14
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!
15
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
16
Middleware continued…
Application
Platform / OS
Platform Interface/ JVM
Application
Platform / OS
Platform Interface/ JVM
Middleware(Distributed System Services)
API’s
Middleware provides communication between distributed applications.
API’s
17
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
18
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.
19
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
20
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
Client Server
Application
21
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
Application1 Application2
message/data sent
message/data delivery
Virtual Connection
22
Object Request Broker (Orb)
• Interface definition• Location and activation of remote objects• Communication between clients and objects
ORB
ClientApplication
Remote Service(Object)
locate service
activate service
establish connection
communicate
CSI 2004
Overview of J2EE- Evolution with Web
What is MiddlewareRemote Procedures/Objects
J2EE- Evolves with WebWeb Services
SOA & ESBB2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
24
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
25
The big picture..
26
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
CSI 2004
Co
nn
ecto
r AP
I
Le
ga
cy Ap
plica
tion
s (like E
RP
)
Ma
infra
me
s
En
terp
rise L
eve
l Se
curity
Fra
me
wo
rk
Naming Service
Fail overLoad
BalancingCluster
ManagerRemote Admin
Web-based Administration via JMX Console
Transaction Service
DB Connectivity
RD
BM
S
Resource Service
Ma
il S
erve
rL
DA
PS
FS
Persistence Management
Lifecycle Handling
Enterprise JavaBeans
Resource Pooling
Java
Clie
nts
CO
RB
A
Clie
nts
JSPs Servlets
Session Management
HT
TP
Se
rve
r
We
b
Bro
wse
rs
JMS Server(Async Messaging)
Enterprise Java Applications Elsewhere
MDB
Enterprise Platform Evolves
28
Complete Enterprise Runtime Environment
Co
nn
ecto
r AP
I
Le
ga
cy Ap
plica
tion
s (like E
RP
)
Ma
infra
me
s
Asynchronous Messaging
Enterprise Java Applications Elsewhere
Transaction Service
Resource Service
En
terp
rise L
eve
l Se
curity
Fra
me
wo
rk
DB Connectivity
Naming Service
Fail overLoad
BalancingCluster
ManagerRemote Admin
Web-based Administration via JMX Console
RD
BM
SM
ail
Se
rver
LD
AP
SF
S
Persistence Management
Lifecycle Handling
Enterprise JavaBeans
Resource PoolingJa
va C
lien
tsC
OR
BA
C
lien
ts
HT
TP
Se
rve
r
JSPs Servlets
Session Management
We
b
Bro
wse
rs
EJB Container
Enterprise Services
Web Container
JMS Server
29
J2EE Market Acceptance
52.38%of Survey
Respondents
J2EEOnly
MS.NET Only
14.29%of Survey
Respondents
33.33%of Survey
Respondents
J2EE and MS.NETDevelopment
30
J2EE: Where does it fit
J2EE Application ServerJ2EE Application Server
Operating SystemOperating System
Your ApplicationYour Application
Java (free)Java (free)
Database Server
WebBrowser
Multiple choices
WebLogic/ WebSphere/ Pramati
31
Preserve your freedom to choose
Your Tools
Any Database
Any Hardware
All Clients
Any OSWindows
Solaris
HP/UX
MacOS MySQL
Oracle SQL Server
Linux
DB2Sybase
Eclipse
JBuilderIntel
Sun Sparc
Internet Explorer
Netscape
RationalHP PA-RISC
Pramati Studio
Mobile Phones
32
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
33
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
CSI 2004
SOA, Integration & ESB
What is MiddlewareRemote Procedures/Objects
J2EE- Evolves with WebWeb Services
SOA & ESBB2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
35
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.
36
Enterprise IT- integration using ESB
User
SAP
COBOL
J2EE.NET
Legacy
“Wire” legacy fn() as service onto ESB Bus
ESB Process
Write “new” ESB service ground-up
DB
XSLT/ Xquery
Java/ J2EE
ESB Bus
Wire “existing” WS off the net
WSDL
Off UDDI?
37
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
38
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
39
Quick Peek
Evolution: Evolution: http://www-106.ibm.com/developerworks/webservices/library/ws-esbscen/Overvew: Overvew: http://www.nwfusion.com/news/tech/2003/0602techupdate.html
ESB’s internal Transport could be one or many. But, transparent to Apps!
40
Sample Scenario..
41
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
42
Key Services in ESB
• SOA implementation – “Services” tie into the “bus”– Support for standards
• “Bus” services – XML support – Transformation – Intelligent routing
• Communications services – Asynchronous/Messaging– Pub / Sub – Store and Forward – JMS-based
• Orchestration & Collaboration• Canned Services/Utilities
Enterprise Class Security• Access control
– User authentication – Component
authorization – Non-repudiation
• Information security – Privacy (encryption) – Integrity checking
• Secure Communications
Legacy Systems to Connect
• DBMS access • Legacy systems
– CICS;IMS;Tuxedo
• EAI Adapters– JCA; Custom;
• Application servers – J2EE Servers • Other
‘standards’ – .NET ; COM / CORBA
43
Typical Flow- Developer adopting ESB
ESB Invocation•Simple Clients•Invoke an ESB Service
Write ESB ‘app’
Define ESB Process•Decisions
•XPath•Call Services
•Custom Services•Web Services•DB Services•XML Services
•Transformation•XSLT•Xquery
•SubProcesses•Collaboration steps
Can Define Services on the fly•As Process is defined•With or without service details
Services ‘wired’ into process•Invocation mapping
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
Service Design/Definition
44
Inside JBI
45
SOA & ESB- Standards At A Glance
JBI
BPEL
JCA
Collaboration
ebxml
rosettanet
WS-BP
ebms
Ws-rm
Ws-S
Service Containers
Legacy Systems
Orchestration
WS-RMJMS
Messaging
WSDL2
J2EE .NET
SOAP PartnerOrganizations
Internet
46
Service Impl
JBI: 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
Extract required Vars from Input
Place Output values
Actual Service(Java, DB, XQuery,..)
Input Contract (specified per WSDL2)
Output Contract (per WSDL2)
Process
Service Invocation
Map Process variables onto Service contract
Service Return
Copy output ontoProcess variables
Service
CSI 2004
SOA- Collaboration Beyond the Enterprise
WS for B2B, Ebxml
What is MiddlewareRemote Procedures/Objects
J2EE- Evolves with WebWeb Services
SOA & ESBB2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
48
ebXml (upcoming) specs at a glance
Ebxml- RS Ebxml- RS (registry services)
Ebxml- MSGEbxml- MSG
Ebxml- CPPAEbxml- CPPA
Ebxml- RIMEbxml- RIM(registry info model)
Ebxml- BPSSEbxml- BPSS(Biz proc schema spec)
Ebxml- BPEbxml- BP(Biz Process)
CPA- Collaboration partner Agreements CPP- Collaboration partner Profiles
Ebxml- BSIEbxml- BSI(Biz Service Interface)
Ebxml- MSHEbxml- MSH(msg srvc Handlers)
49
ebXML Functional Service View
• Functional capabilities
• Business Service Interfaces
• Protocols and
Messaging Services
Business Process and Information Models(Compliant to the ebXML Meta Model)
Model to XML Conversion
Registry ServiceInterface
Registries
Implementers
Retrieval of Profiles &new/updated ebXML Models
Retrieval of Profiles &new/updated ebXML Models
Retrieval of ebXMLModels and Profiles
RegistrationRegistration
Internal Business
Application
Business ServiceInterface
Internal Business
Application
Business ServiceInterface
Collaboration Protocol
Agreement(CPA)
Payload
CPPCPP
DrivesDrives
CP
AC
PA
Gov
erns
Gov
erns
BuildBuildBuildBuild
RegisterCollaboration Protocol
Profile(CPP)
RegisterCollaboration Protocol
Profile(CPP)
50
WS, ebXML & J2EE/ arch scenario
DB
LegacyApps
COTSApps
Legacy
Apps
J2EE Application Server Container
Orchestration Services
EJBBusinessServices
Syst
em
s In
terf
ace
ebXML
MSH
ebXMLProces
sServer
ebXML
BSI
Apps
B2B—Tradin
g Partner
CPA BPSS
J2EE Web Container
ebXML
SOAP
Business Process
Collaboration
DMZ
Internal Firewall
EJBBusinessServices
Inte
rnet
51
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.
CSI 2004
Some Buzz.. : Grid ComputingCase: J2EE Grids
What is MiddlewareRemote Procedures/Objects
J2EE- Evolves with WebWeb Services
SOA & ESBB2B Collaboration - ebxml
Middleware technology Trends
Pramati in Middleware space
53
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
54
WS, ebXML & J2EE/ arch scenario
DB
LegacyApps
COTSApps
Legacy
Apps
J2EE Application Server Container
Orchestration Services
EJBBusinessServices
Syst
em
s In
terf
ace
ebXML
MSH
ebXMLProces
sServer
ebXML
BSI
Apps
B2B—Tradin
g Partner
CPA BPSS
J2EE Web Container
ebXML
SOAP
Business Process
Collaboration
DMZ
Internal Firewall
EJBBusinessServices
Inte
rnet
55
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
56
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
57
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
58
Where J2EE fits into Grids
Browser
Web-based Console
JavaClient
CORBAClients
HTML, JSP, Servlets
Web Container EJB Container
EJB 2.0, MDBs
DeployTool
Security DataRepositories
MessagingClients
FastRMI
RDBMSMail ServerLegacySystems
SSL
SSL
RMIRMI/IIOP
Interoperability over RMI/IIOP
Connector Message Server
Resources
POP, SMTPIMAP
JDBC
TransactionNaming Security
Load Balancing Administration &MonitoringFailover
LoginModules
RMI
HTTP
Request Dispatcher
Dynamic Caching
DashboardDiagnostics
• 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’
59
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
60
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.
61
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
62
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
63
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
CSI 2004
What we do in middleware space.. Pramati Products
What is MiddlewareRemote Procedures/Objects
J2EE- Evolves with WebWeb ServicesSOA & ESB
Middleware technology Trends
Pramati in Middleware space
65
Little about Pramati
• 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
• Global recognition of Engineering capability• Technology leadership• Talent Magnet
The Result
The Vision
66
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
67
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
Java Designers
Web Designers
EJB
JSP
Servlet
App Assemblers
Project Managers
Assemble
Test
Package
System Admin
Database Admin
Deploy
Monitor
Manage
CreateCreate AssembleAssemble DeployDeployMonito
r
Monitor
ManageManage
Analyze
AnalyzeJ2EE Server
68
Design : Develop : Debug : Deploy
Model Review Create Refactor Test Debug Deploy Manage
