This document discusses middleware classification and architecture. It covers the following key components of middleware: 1. The communication link, which is typically TCP/IP or SNA. 2. The middleware protocol, also called the wire protocol, which defines the message format and state transitions. 3. The API, which can be object-oriented, operations-based, or language-based. APIs may block or not block the processing thread. It then discusses Microsoft's DNA and Java EE architectures, which both utilize web servers, transactional middleware engines, and services like messaging and directories. Both architectures partition applications into presentation, business logic, and data tiers, though DNA uses COM and Java EE uses Java

1. KLASIFIKASI MIDDLEWARE DAN
ARSITEKTUR

2. 
Middleware is more complex than most IT
people recognize
1.
2.
The Commucication Link
The Middleware Protocol
A
B
3. The API
4. A Common Data Format
6. Naming/Directory Services
7. Security
8. Administration
5. Server Process Control

3. • The communications link
restricted to use one or a few networking standarts, the dominant
standarts at the moment being TCP/IP and SNA
• The middleware protocol
often calles wire protocol;
- the format of message over the communications link
- the state transition diagrams of the entities at each end
Chapter 5 – Middleware Classification & Architecture
Magister Teknologi Informasi - ITB

4. • The application programmatic interface (API);
- API can be Object Oriented of conventional
- can be fixed or can be compiled for specific
application
- can be operations-based or language-based
- API calls may or may not block the processing
thread until the server replies
• Common data format
e.g. ASCII, EBCDIC, UNICODE

5. 3 main tasks server controls
- process and thread control
when load is heavy  additional processes & thread started
when load is lightens  desirable to lessen the number of
processes and/or threads
- resources management
database connection polling
- object management
may be activated or deactivated

6. • Naming/Directory Services
Network access point to a middleware server us typically a 32-bit
number defining the network access and a port number that allows
the operating system to route the message to the right progam
• Security
Valid users may be allowed to use the server resources and may
be given to only a limited selection of the possible services
• Administration
Human interface to all this software for operational control,
debugging, monitoring, configuration control

7. • What is communicating ?
First dimension  classification according to what entities are
communicating. Nowadays, process communicated with process.
Observe Layering:
- Physical
- Data link
- Network
- Transport
• How they communicate ?
Each layer has protocol. 2 major categories of protocols :
- session protocols
- sessionless protocol

8. Inisiator / Requester
Client/Server
Peer-to-Peer
Push
Responder

9. Transaction & Information retrieval middleware must be
- no messages lost
- no messages received in the wrong order
- no messages corruption
- no messages duplication
The real characteristic of middleware protocol :
- the middleware should have a protocol that is convenient for
the structure of the application (for instance, client/server or
queuing)
- the middleware can implement additional application-level
integrity like two-phase commit

10. Many different style of API-based middleware interface :
 message-based : API has a message and message type
 command language-based : the command is encoded into a
language
 operation call-based : built up by a series of middleware
procedure calls
Classification of impact on process thread control :
 blocked – thread stops until reply arrives
 unblocked – client every now and then has a look to see if reply
has arrived
 event based – when the reply comes, an even is caused, which
wakes up the client

11. Two architectures that are grabbing attention now :
 Microsoft Windows Distributed interNet Applications Architecture (DNA)
 Java 2 Enterprise Edition (Java EE) by Oracle Sun
DNA consists of
Presentation services (HTML,DHTML, scripting, ActiveX COM)
Application services (Internet Information Server-IIS, COM+)
Data services (ADO, OLE DB)
System services (directory, security, management,networking)
Java EE consists of
client tier (browser, Java Applets, standalone Java program)
web tier (JSP, Java Servlets)
enterprise java beans tier (EJB container)
enterprise information systems tier (database/mainframe application)

12. Rich Client (GUI application)
Thin Client (Web Browser)
ADO&OLE DB
DCOM
MSMQ
HTML, DHTML, XML
Presentation
Tier
IIS Web Server
DCOM
ASP
Universal Data Access
(ADO & OLE DB)
Business
Logic
Tier
Data
Tier
Mainframe
COM
object
COM+ Container
COMTI
MSMQ
DCOM
Universal Data Access
(ADO & OLE DB)
E-mail &
Messaging
Directory
MSMQ
SQL
Database
File System

13. Presentation
Tier
Java GUI Application
Web Browser + Applets
JDBC
JMS
HTML, DHTML, XML
Java
Servlet
Web Container
JDBC
JMS
Business
Logic
Tier
EJB Container
Data
Tier
Mainframe
RMI-IIOP
Connector
JSP
JNDI
Java Mail
EJB
JDBC
JMS
RMI-IIOP
Data
JNDI
Java Mail
RMI-IIOP
JNDI

14. • DNA has number of alternative presentation
technologies, ranging from “rich client” to “thin client”
• DNA & Java EE architecture are similar (in many ways)
 have web server
 have transactional component middleware engine
• But...
One is COM-based, and other is Java-based

15. • Both of them  offer message queuing & transaction
service
 but not given equal prominence
• The implication of architecture
 set of tools from DNA bag will work together
 set of tools from J2EE will work together but if mix
and match from both bags, are on our own
• Both of them are silent on the subject of batch
processing

16. • The biggest problem is bafflement
by its very nature when explaining an architecture that have
to explain a range of very complex software
• If the architecture;
too complex  hard to explain
too simple  no substance

17. • We can buy application such as SAP, Baan, PeopleSoft
but we have to think about integration
• A way accessing the architectural implication of product
is to ask ourself about these question :
 what impact does this product have on the positioning
of existing appliations?
 what impact does this product have on future
development? What tools do we use and where? How do
we partition the functionality between the tiers?
 what is the vendor’s vision for the future?