The JBoss Extensible Serverreverbel/slides/mw2003-slides.pdfThe JBoss Extensible Server Marc Fleury...

1

1 Middleware 2003 – Rio de Janeiro – June 2003Marc Fleury & Francisco Reverbel

The JBossExtensible Server

Marc FleuryThe JBoss Group, LLC

y Francisco ReverbelCS Department, University of São Paulo


Outline� Introduction� JMX Foundation� Service Components� Meta-Level Architecture for Generalized EJBs� Ongoing and Future Work� Related Work� Concluding Remarks

2


Introduction


Application Servers� Middleware platforms for development and

deployment of component-based software� Application component models

� J2EE (Servlets/JSP and EJB), .NET, CCM� Component-based techniques should not be

applied on user applications only� Component-based application servers� Dynamically deployable middleware components� Two kinds of components

� Middleware components and application components

3


JBoss� Extensible, reflective, and dynamically

reconfigurable Java application server� At the confluence of research areas such as

� Component-based software development� Reflective middleware� Aspect-oriented programming

� Open-source and free (LGPL)� 2M downloads in 2002, 1.5M so far in 2003

� Includes a set of components that implement the J2EE specification


JBoss: Open-Ended Middleware� Users can extend middleware services by

dynamically deploying new components into a running server

� The foundation� Java Management Extensions (JMX) specification� Architecture for dynamic management of application,

system or network resources� The building

� Service components� A JMX-based model for middleware components

� The EJB subsystem� Invokers, containers, dynamic proxies, and interceptors

4


JMX Foundation


JMX Architecture

Java Virtual Machine

Agent Level InstrumentationLevel

MgmtClient

Browser

DistributedServices Level

Connector

ProtocolAdapter

AgentServices(as MBeans)

ManagedResources(as MBeans)

MBeanServer

5


The JMX Component Model� The instrumentation and agent levels define an

in-process component model� The MBean server provides a registry for JMX

components (MBeans)� Each MBean is assigned an object name that

is unique in the context of the MBean server� Clients use object names to refer to MBeans� MBean operation invocations always go

through the MBean server


Method invocation on a dynamic MBean

Java Virtual Machine

Client

�� !�� !�" "�#�$#�$ % %�&&�'�(*)�+'�(*)�+�,,�%�-�.�)%�-�.�)�//'' 0 012�312�3�4 45�687:95�687:9 ;�<�=*<;�<�=*<�>>@?? A AB�C�DB�C�D�E E�F�G8H:IKJ�E�G�FF�G8H:IKJ�E�G�F�LLC�MND*OC�MND*O�PP

MBeanRegistry

MBeanServer

MBean

E�F�Q�RS�OE�F�Q�RS�O�TTUB�C�DB�C�D�EE�F�GF�G R R�VV�O�D*L�CO�D*L�C�EE�R�F�W�LR�F�W�L�XXOO Y YZ[�\Z[�\�O O]�C8H:I]�C8H:I V�L�D*LV�L�D*L�XX@JJ Y YB�C�DB�C�D�E E�F�G8H:IKJ�E�G�FF�G8H:IKJ�E�G�F�LLC�MND*OC�MND*O�PP

^ The client holds no direct Java references to the MBean^ It does not need to know the MBean’s Java class/interfaces^ This very simple arrangement favors adaptation

6


Dynamic and Standard MBeans� JMX defines two kinds of MBeans

� A dynamic MBean implements a predefined Java interface and relies on metadata to specify its management interface

� A standard MBean implements a Java interface defined after – and determined by – the MBean’smanagement interface

� The kind of an MBean is an implementation detail hidden from clients


Dynamic MBeans

�� !�"!�"$##�%% & &�''�(*)(*)�((�(,+(,+*--�.�/.�/�((�''10032�(,+2�(,+*--�4�&4�& 5�6�65�6�6,7738�58�5�99�:: ;=<;=<> >�??�?,@?,@*AA�B�C�?B�C�?�DD�E�AE�A�FF�?? G G D�?D�?*>>H??�??@*A�B@*A�B�CC�?�D?�D�FF,I�J�?I�J�?,@@�A�KA�K GG LNMLNM O�PO�P�PPQQ�RR�O�S$TO�S$T�UU V=WV=WX X$YY�Z�[Z�[ \�]�^\�]�^*__H^�^^�^,`` Z�aZ�a�bb ^�]^�]1ccd__�^^�^,` Z^,` Z�aa�b ^b ^�]] e ê ^�^^`` f=gf=g_ _�^^�^,`^,` ZZ�a�b â�b ^�]]�h Zh Z \ \�^^ \ \�]�^]�^*__H^^�^^` Z�a` Z�a�bb ^�]^�]�\\,ci_�^ci_�^�^^1` Z` Z�aa�b ^b ^�]]�h Zh Z \ \�^ ^ e ^�ê ^�^,``j\\ f=gf=gk k a a�l ]l ]$mm�^^ n n�oo*p$qp$q�rr�s1ts1t�uu�v,wv,w*nn�oo�xx y�zy�z�{{|�}|�}�~~��jy��jy��$}��}��${{ � �

� ��N��N� � ��,��,�� *�� N��N� � �� $�� $� �� $�=��$�=�

� �� ¡¡ ¢ ¢ � �$£��£�� ¡ �¡ ¤¤�¥¥§¦¦¨ ¨

© The metadata class MBeanInfo supports MBean introspection© Management attributes and operations does not need to

correspond to Java fields and methods

7


Standard MBeans

��

� �!� �!""$#&%#&%''�(�"(�" ))****�++-, ", "''� . .� � �!! / /�01�201�233�4�54�5�11 6&7986&798: : 3 3�;�<;�< = 01= 01�22�3�43�4�55�1 61 6 ; ;�5�15�1 >> 7 7?88< <�33�4@4@�AA�00 B B�CC�D�CD�C�EE�FGFG�HH�IJIJ�KKMLLONN�C�J�KC�J�K P�QP�QSRRTQ EQ E U9VU9V

W W

X The FooMBean interface follows JavaBean-like rules to represent management attributes and operations

X A standard MBeanexposes its management attributes and operations by implementing a Java interface named after the MBean’sJava class, with the suffix MBean


MBean Server Interface

YTZ\[]^`_OabT]YTZ\[]^`_OabT] c�d&ec�d&eOff�g&hTeikj�eig&hTeikj�ei llm�n&oTpTqOr�sTtTu\rTvm�n&oTpTqOr�sTtTu\rTv�ttOqTpqTp w`xOy�zT{w`xOy�zT{\|| xxww~}��&xO��&�TxT�O|}��&xO��&�TxT�O| ��&�T�T�O��&�T�T�O�� O��T��O��O�O� ��O��O�O� � �\�O� �T�-��\�O� �T�-�� ¡\¢� �¡\¢ £T¤�¥`¦O§�¨£T¤�¥`¦O§�¨T©©&ª¦¥¬«�&¦O®�¤ª¦¥¬«�&¦O®�¤¯¯k°°�±±O²T¦T³Oª´O®Oµ ¦²T¦T³Oª´O®Oµ ¦ ¤\®Oµ ¦¤\®Oµ ¦T¶¶S··¸T¸T¸¸T¸T¸¹�º&»T¼T½O¾¹�º&»T¼T½O¾ ¿ÀOÁÃÂ¿ÀOÁÃÂ�ÁÁÁ�ÄÃÅTÆTÇ\ÁÀ�ÈÁ�ÄÃÅTÆTÇ\ÁÀ�È�ÉÉ�ÆÆ&ÊÊÀTËOÁÌOÍOÎ ÀÀTËOÁÌOÍOÎ À Ï ÍOÎ À-ÐÒÑOÁ�ÄÃÅ Ï ¿Ï ÍOÎ À-ÐÒÑOÁ�ÄÃÅ Ï ¿ Í ÍTÁ ÁÁÁ�ÄÄÓÌOÍOÎ ÀÌOÍOÎ À Ô-ÕÔ-ÕÖ�×T×�ØÃÙTÚTÛ\×Ü�ÝOÙÖ�×T×�ØÃÙTÚTÛ\×Ü�ÝOÙTÞÞ&×× ß ÜO×ÃÖ�×T×ß ÜO×ÃÖ�×T×�ØØ\ÙÙTÚÚÛ\×Ü Þà�á�Ú&âTÜTãO×äOåÛ\×Ü Þà�á�Ú&âTÜTãO×äOåOææ�ÜÜ ç\èOé ê-ëç\èOé ê-ëíììTîî�ïï\ðTç\ñ�òôóðTç\ñ�òôó èTîTî�ï`õOèOéèTîTî�ï`õOèOé êê�öö ÷-ø÷-øùú ð\ûùú ð\û ö&êOîÃü�îTîö&êOîÃü�îTî�ïï\ðTýTþ\îê�ÿ��ýðTýTþ\îê�ÿ��ý�� êê��TîõOèOé êîõOèOé ê ç\èOé ê-ë üç\èOé ê-ë ü�îî î�ïÃðTýTþ\îêî�ïÃðTýTþ\îê èè îîTîî�ïï ÷-ø÷-øü�îTî�ïÃðTýTþ\îê��Oðü�îTî�ïÃðTýTþ\îê��OðTöö&îî ö&êOîÃü�îTîö&êOîÃü�îTî�ïï\ððTýýþ\îê öÿ��ý��Tê��OîõOèþ\îê öÿ��ý��Tê��OîõOèOéé�êê ç\èOé ê-ëç\èOé ê-ë üüîîTîî�ïÃðTýTþ\îê��OðTö\îïÃðTýTþ\îê��OðTö\î èTîèTîTîî�ïÃöïÃö ÷-ø÷-ø��ý��Tê��Oî��ý��Tê��Oî �� ! ��#"$��! ��#"$��%% &('�)+*-,�.�/&('�)+*-,�.�/$&&�00�11�,�2�),�2�) 33

4�5�6 )�7�.4�5�6 )�7�.988;:: '�,#*-,�2(<'�,#*-,�2(< 3!= .#*$/�03!= .#*$/�0�>>?8@:A<�/�>�0�,8@:A<�/�>�0�,�..(BB(**�)�C�D)�C�DE(F )�,�0�G�0�H�&E(F )�,�0�G�0�H�& > > ))�. E(F )�,�0�G�0. E(F )�,�0�G�0�HH�&&JII 4�5�6 )�7�. 1�,�2�)4�5�6 )�7�. 1�,�2�) 0�,0�,�22()�C�D)�C�D

K K

8


Service Components


Issues not covered by JMX� Dependencies between MBeans� Service lifecycle� Packaging and deployment of MBeans

JBoss addresses these issues with the notions of service MBean and deployable MBean

9


The JBoss Component Model� Service MBeans:� MBeans whose management interfaces include

service lifecycle operations� Also called service components

� Deployable MBeans:� Service MBeans packaged according to EJB-like

conventions, in deployment units called service archives (SARs)� A SAR includes a service descriptor, an XML file that

conveys information needed at deployment time� Also called deployable services� They are a JBoss- specific extension to JMX


Service Lifecycle� A service component may be in the stopped

state or in the started state� At each state transition one of the following

lifecycle operations is invoked on the MBean:� F� UH�� D� W� H� V WD� � UW�� V� WR�� S�� G� HV�� W� U� R\

��

10


A Service Descriptor File (1 of 3)

��

�� !��" ��#!�$%�&('!��" ��#!�$%�&(' ))�)) * *+ + , ��-!&, ��-!& .�/#0.�/#0#11-2�32�3 4�57698;:�<4�57698;:�<=44?>>�>>@8BA?C�<D8FE�C�<�G�C�5�H?I8BA?C�<D8FE�C�<�G�C�5�H?I�JJ#CC K K

L(M-NL(M-N C C-O KO K P�Q=R�S�SDTP�Q=R�S�SDTUSS-VV�WW7X?Y�Z�VX?Y�Z�V [[ \ V�Q�]�V�W�X?Y\ V�Q�]�V�W�X?Y�ZZ#VV ^`_^`_a#b�c�c�d=e�fa#b�c�c�d=e�f�gg�c#hji(b-k�h�lc#hji(b-k�h�l�mm�nnpooqd7c?m`r�s-t#s�u`a-v�b�c�cd7c?m`r�s-t#s�u`a-v�b�c�c�dd�e�f�g(c#h�re�f�g(c#h�ra#b�c�c�d=e�fa#b�c�c�d=e�f�gg�c#hji(b-k�h�lc#hji(b-k�h�l�mm w w-xx�y�z�{�x#|�}#~��y�z�{�x#|�}#~��{{�|��|�� `�#��`�#� ��-�-��| �� =�� -��| �� =��

�-��-� � ��-|z� ��-|z ��

�� (��(��-��-�-��-�-�� -� ��-� ¡�¢#£¡�¢#£ � �-¤�¥¤�¥ ¦�§7¨9©;ª�«¦�§7¨9©;ª�«=¦¦?¬¬�¬¬@©®-¯°©B±�²(³?´pµ#¶--¦�§©®-¯°©B±�²(³?´pµ#¶--¦�§�·· ¸ ¸

¹ µ-¯¹ µ-¯�ºº-» ¸» ¸ ª�«=¦�¬�¬D¼ª�«=¦�¬�¬D¼U¬¬-ºº�§§7½?²�¶�º½?²�¶�º »» ±�²(³?´pµ#¶--¦±�²(³?´pµ#¶--¦�§§7· · ¸`¾¸`¾¿ µ��§=²�«¿ µ��§=²�«�ÀÀ�#º ¹ µ-¯�º�»#º ¹ µ-¯�º�» ¸¸�Á Á µ µ#³ ¸`¾ �§=À�º ¿-Â µ��§³ ¸`¾ �§=À�º ¿-Â µ��§=²²�«�À(#º ¾«�À(#º ¾¿-Â¿-Â ¯�«�º-µ ¹¯�«�º-µ ¹ ¾ ¾

©�©�©©�©�©



©�©�©©�©�©¿�Ã¿�Ã Ä�ÄÄ�Ä ÅDÆ7ÇÈ�ÉÅDÆ7ÇÈ�É(ÇÇ�Ê-ËÌ=Í�ÈÏÎ#ÇÊ-ËÌ=Í�ÈÏÎ#ÇÈÈ�ÇÇ�ÐÐ�Ñ�ÆÑ�Æ Ò�ÒÒ�Ò ÓÓÔ Ô Î�Õ�Ñ-ÇÈÎ�Õ�Ñ-ÇÈ Ê�Í#ÖÊ�Í#Ö#ÑÑ-×�Ø×�Ø Í�Æ7Ð9Ù;Ú�ÕÍ�Æ7Ð9Ù;Ú�Õ=ÍÍ?ÉÉ�ÉÉ@Ù®Ë-Î°ÙFÅDÆ7ÇÈ�É(Ç#Ê-ËÌÙ®Ë-Î°ÙFÅDÆ7ÇÈ�É(Ç#Ê-ËÌ=ÍÍ?È=Û#ÇÈ(Ç�Ð#Ñ�ÆÈ=Û#ÇÈ(Ç�Ð#Ñ�Æ`ÜÜ#ÑÑ�ÆÆ�Ý?Ì�Ê�ÑÝ?Ì�Ê�Ñ Ø Ø

È(Ç-ÎÈ(Ç-Î�ÑÑ-×�Ø×�Ø Ú�Õ=Í�É�ÉDÞÚ�Õ=Í�É�ÉDÞUÉÉ-ÑÑ�ÆÆ7Ý?Ì�Ê�ÑÝ?Ì�Ê�Ñ ×× ÅDÆ7ÇÈ�É(Ç#Ê-ËÅDÆ7ÇÈ�É(Ç#Ê-ËÌÌ(Í�È=Û#ÇÈ(Ç�Ð#ÑÍ�È=Û#ÇÈ(Ç�Ð#Ñ�ÆÆ Ø Ø Ó ÓÔ Ç�Ë�Ë�Æ=Ì�ÕÔ Ç�Ë�Ë�Æ=Ì�Õ�ßß�Ë#ÑjÈ(Ç-Î�Ñ�×Ë#ÑjÈ(Ç-Î�Ñ�×�ØØ Å ÅDÆÆ`ÇÈ�É(Ç#Ê-ËÌ=Í�È`Å�Ì=Î�ÑÇÈ�É(Ç#Ê-ËÌ=Í�È`Å�Ì=Î�Ñ�ÍÍ?ß(Ëß(Ë Ø Ó�àpá�á ÔØ Ó�àpá�á Ô-ââ Ç Ç�ËË#Ë�Æ=Ì�Õ�ß(Ë#Ñ ÓË�Æ=Ì�Õ�ß(Ë#Ñ ÓÔ Ö#Ñ�ã�Ñ�È(ÖÔ Ö#Ñ�ã�Ñ�È(ÖÉÉäÍ�ã(ËÌ=Í�È(ÇÍ�ã(ËÌ=Í�È(Ç#åå Ò Ò Ç Ç#Ë�Ë�Æ=Ì�Õ�ß(Ë#ÑjÈ(Ç-Î�ÑË�Ë�Æ=Ì�Õ�ß(Ë#ÑjÈ(Ç-Î�Ñ�××�ØØ æ Ì(Ö?çpÇ#Ê-Ëæ Ì(Ö?çpÇ#Ê-Ë-ÍÍDÆÆ�èè Ø ÓØ Ó

Ú�Õ=Í�É�ÉDÞUÉ�ÑÚ�Õ=Í�É�ÉDÞUÉ�Ñ�ÆÆ�ÝÝ?ÌÌ�Ê�ÑÊ�Ñ ×× æ Ì(Ö?çpÇ#Ê-Ë-Í�Æ�èæ Ì(Ö?çpÇ#Ê-Ë-Í�Æ�è ÔÔ�â Ö#Ñ�ã�Ñ�È(ÖÉâ Ö#Ñ�ã�Ñ�È(ÖÉ Ó ÓÔ-âÔ-â Î�Õ�Ñ-ÇÈÎ�Õ�Ñ-ÇÈ ÓÓÔ�éÔ�é Ò�ÒÒ�Ò ê-ë�ìê-ë�ì íí#î îï�ð�ñ�ò�î�óï�ð�ñ�ò�î�ó ô ô�ôô õ õö ö ÷�ø î-ùú÷�ø î-ùú û ñ#íû ñ#í#îî-ü�ýü�ý ñ�ó7þ9ÿ�� øñ�ó7þ9ÿ�� ø ñ ñ��@ÿ;î�� ø ÿ ê-ë�ì�� î�ï�ð�ñÿ;î�� ø ÿ ê-ë�ì�� î�ï�ð�ñ�òòî�óî�ó ýý

ú(ù ÷ú(ù ÷ î î-ü�ýü�ý � ø ñ��Dÿ� ø ñ��Dÿ;îî�� ø ø ��î�ó�� û î ��î�ó�� û î ü ü ê-ë�ì��ê-ë�ì�� î îï�ð�ñ�ò�î�óï�ð�ñ�ò�î�ó ý õý õö ù��ó� øö ù��ó� ø�� #îjú(ù ÷ î�ü�#îjú(ù ÷ î�ü�ýý � �� !! "$# ��%��&"$# ��%��&(''�))� � ��*�%� �� # ��*�%� �� #&�+��+&�+��+,!! # # - *��!�!/.0!- *��!�!/.0!��11��2��2�� 33 4 �5),��!�)�2( ,�4 �5),��!�)�2( ,��6�),��)�7��8��6�),��)�7��8� &&�' '�++��+,! #��+,! #&�+��+&�+��+,!! # # - *��!�!/.0!- *��!�!/.0!��11��2��2�� 33 9 ��*�:��8��1��29 ��*�:��8��1��2�� &('�+��+&('�+��+,!! # #

&('&(' ��*��(),��*��(),� ##

;�;�;;�;�;

11



�� ! "�� ! "� # ��$# ��$��!%'&%'& �(�*),+.- ��(�*),+.- � � ��//�//0+1�� # �2"��3+.-+1�� # �2"��3+.-'�� 4 +1/5�'�6�"��4 +1/5�'�6�"�'��++1 ��!��'��!��'� & &�� !%'&%'& - � �/�/37- � �/�/371//!��'��*�� # �� # � % % ��'�'8��'�'8922�: 4 �: 4 � % % -'� �4-'� �4 && � �� 2�2�� 2�2�� ;; 2��<�� 5%2��<�� 5%'&& � ��= � -�� # 2��(�*2�= � -�� # 2��(�*2 >@?>@?�AA�A�A�A!B!CED�F�FA�A�A!B!CED�F�F�GG�HH�IIEJ�F�K5?J�F�K5?B�L�KEM5KEN�LB�L�KEM5KEN�L"OO�?? P I�QO�O3R1OP I�QO�O3R1O5KK�GG6SS�H5T�KH5T�K UU V G*D"N�O�D�T!F"HV G*D"N�O�D�T!F"H�QQ�N�W�D"N�D�X�K'GN�W�D"N�D�X�K'G BB�C CELLEKEM5KEN�L"O�?KEM5KEN�L"O�?B!CB!C Y I5K!D"NY I5K!D"N ??

B!C�O5K'G6S"K'GZ?B!C�O5K'G6S"K'GZ?

[ Note the “depends” elements[ JBoss manages dependencies between deployable

MBeans


Dependency Management\ JBoss employs a variant of the component

configurator pattern to control the lifecycle of deployable services[ Deployment of SAR files with service MBeans are

handled by a 6] $5^`_

'a Hb Sc ORdfe \g

Hb Uhi The 6] $5^`_

'a HSbjc Od Re \g

Hb Uh plays the role of component configuratori A 6k Hl UYm�n Lo FHpql &

rRs

Qt WUuvm Rs

Ow Ow Hl Um plays the role of component repository

x Deployment/undeployment events drive the lifecycle of deployable services

12


Deployment and Undeployment� A 0

�D� L� Q� '� H� S� O� R \H

� U� handles all deployment units (SARs, JARs, EJB-JARs, WARs, RARs, etc.) by delegating the actual deployment tasks to sub-deployers:� 6 $5

��'� H� S� OR�� \

�H� U� , -� $

�5� '� HS�� O R

!\"

H� U# , ($ -% %'&(' H) S* O+ R\,.-

HU)0/ , … 1 The set of sub-deployers is open-ended1 Sub-deployers are service MBeans2 They register themselves with the 3547698;:3747698;:=<<?>9@BA>9@CAEDD5<GF<.F ,

which is also a service MBeanH 354=6=8;:9<=>3547698;:9<=>9@@IA?D5<A?DJ<GFF , K KMLLGNN;OO9P9Q9RBS?TJPP9Q9RCSETJPGUU , and V VXWZY;[9\W.Y;[9\=]]?^B_?`5\.a^B_?`J\Gaare not deployable components b All other deployers are deployable MBeans


Management interface of the MainDeployer

LQc5d We Hf Ug IDh=i Fj.kf 0Dl i Lc Qd 'Hm(f SOn5o Rp \

qHf U0g l %r Hf Di Qd

Hs [t

Wu Hs QGv?wyxz 6H{5s UY|~} L� F� Hs 0%�G�

Hs D� Qv �Y�

R� L� G�� D� G� G� 'H�5� S� O� R\�7�

HU�� 6� X� E'�?� H� S� O� R\�=�

H� U� G� HS�(� O� R�

\�

HU�� Y�

R� L� G�� U� H� P�

RY ?¡ H� '¢ HS��£ OR¤E \¥

H� U� �6¦M§ XE© '¢ HS�J£ O¤ R \H¥ � U� Gª H� S£ OR¤? \

¥H� U� ��«¬

&®

R O¤ OH¤9� FW° L±�²�³ � O¤ LV±5µ W'° ¢ H� S£ O¤ R\ ¥ H� U� Vµ ��¦X«¬Y¡ R L± G�ª G¶ H· SOR¹Eº \

»�¼ 85½(¾ /¿ XÀ UÁ O¹ ��ÂÃ

YÄ

Rº LÅ G�¶ XÀ QÆ G¶ HS·J O¹ Rº \�» ¼ 85½J¾ /¿ XÀ UOÁI¹ �Â �Ã

EÇ Rº Rº OH¹=· DÈ QÆ LVÅ7É 'Ê H· SO¸5¹ R\º » H· G¶ �¼ 85½J¾ /¿ XÀ UOÁI¹ �Â �Ã&Ë

Rº O¹ OH¹9· FÌ WÍ LÅ�Î�Ïº Æ O¹ LVÅ5É W'Í Ê H· SO¹ R\º » H· G¶ �¼ ��ÂÃ�Ð ��Ð7Ð

Ñ

13


Hot Deployment� Just drop deployment units into a well-known

directory� A '

�H� S� O� R

�\�

P�

H� Q� W6� F� D Q� Q� HU�� monitors the files in this directory� The '� HS�� O� R\�� D� P

�H� QW6�� F� DQ� � Q� H� U! is a deployable

MBean itself� A thread started by this MBean repeatedly scans

the deployment directory and invokes the 0"

DL�$# Q� '� H� SO�%� R� \H�&� U! whenever it detects a change

Class visibility is a function of time!


Class Loading Issues� A number of application servers use variants of

a class loading approach that could be called loader-per-deployment� This approach creates a namespace per

deployment unit� It hinders local interactions between separately

deployed parts� Acceptable for application components� Unsuitable for the dynamically deployed parts of an

extensible system such as JBoss

14


What is bad about the Parent Delegation Model?� Middleware components need to share non-

system classes in order to interact within a VM� So they must be loaded by a set of class

loaders with a common ancestor, which loads the classes they share

� This leads to a hierarchical deployment process (a “deployment tree”)� Cumbersome in dynamic environments� Does not match the DAG nature of component

dependencies


Unified Class Loaders� A collection of unified class loaders acts as a

single class loader� It places in a single (flat) namespace all classes

it loads� This is a significant departure from the hierarchical

class loading model introduced in JDK 1.2� Instances of 8QL

��I� L�

H� G & O� D� V V /� R� D� GH�� U� are registered with a 8

�Q�

L�

I� L�

H� G /� R� D� G HU�� 5� H� S� R� V L�

W� R� U\�� They behave as a single 8� 5� /&�� O� D� V� V/�� R

DG�"! HU#%$ that

allows its collection of URLs to be updated at any time

15


Dynamic Proxy Usage� A dynamic proxy is an object adapter that

converts the type-independent interface of its invocation handler into a list of interfaces specified at runtime

� Dynamic proxies bridge the gap between the interfaces that are application-specific and those exposed by middleware components


The Dynamic Stub Idiom� In Java RMI:

� Serializable types are normally passed by value� Remote types are normally passed by reference� What about a remote object that is also serializable?

� If it has not been exported through the RMI system, then it will be passed by value (in serialized form)

� This allows the creation of custom stubs, which interact over a custom protocol with the remote objects they represent

� JBoss uses dynamic proxies as custom stubs� The dynamic proxy implements application interfaces� Its customized part is the invocation handler

16


Meta-Level Architecture for

Generalized EJBs


Meta-Level Architecture

Server Virtual Machine

MBeanServer

ContainerMBean

Server-SideInterceptors

EJBComponent

Client Virtual Machine

Client-SideInterceptors

InvocationHandler

DynamicProxy

EJB Client

InvokerProxy

EJBContainer

InvokerMBeanClient-Side

Proxy

Meta Level

Base Level

17


Reified Method Invocations

� No interface along the reified invocation path depends on base-level application types

�� !��""#�%$�%$ � ��& �& � � � �� ('' � � ��)* ��)* �++ � � � � ��)* ��)* �++#�� -,/.�-,/. �0$�0$1""�� 2 2�3354�64�6�77�8�9�:8�9�:*66�3*;3*;�66�3�93�9�<<�=�9=�9 ::�3354�6�74�6�7�88�9�:9�:*66�3*;�63*;�6�33�9�<9�<�==�99 > >? ? 8 8�4�84�8 @@BA�9�:A�9�:�CCD@FE@FE�88�GG G G�8�H8�H�CC�66�88�I >I >? ? 8 8�4�84�8 @@BA�9�:A�9�:�CCD@FE@FE�88�GG J J�K1LK1L0MM�KK1LLON�J�PN�J�P�QQ�R�JR�J�SS T T U U�UU V V�W0XW0X5YY�ZZ�WW�[�[�\[�[�\�]] ^ ^5__�`ba`ba�``�ccd d _ _�e�_e�_ ffBg�h�ag�h�a�iiDfFjfFj�__�kk h hml1_l1_�nn�``�aa�o�n�ho�n�h5ppOk�_k�_�qqri*s�_i*s�_�tt u uwvv�vv n n�s�hx`s�hx`�oo�n�hn�hbhh�ssbss�h�y�oh�y�o0ll z z�{{r||} }�}}�}}w~~�~b�~b��*��*��*��x��*�*�0��*�*�0��


Invoker Architecture (1 of 3)

� A powerful and flexible remote invocation architecture� EJB containers expose a type-independent LQ�� Y

�RN�� H�

operation� Protocol-specific invoker MBeans make this

operation accessible to remote clients through various protocols (JRMP, IIOP, HTTP, SOAP)

� Client-side stubs are dynamic proxy instances � They convert calls to the typed interfaces seen by

clients into LQ�� Y�

R� N� H� calls on remote invokers

18



� Each client-side proxy has an invocation handler that performs remote calls on a given invoker, over the protocol supported by the invoker

� Client side proxies and their invocation handlers are instantiated by the server and dynamically sent out to clients as serialized objects

� Interface exposed by the JRMP invoker:� �� !!� �""$##�%%'&&�(()##+**�,,�&&�--�..�,, / /

0 0�11322544�66�77 8 8�99�::<;;�99�==?>>@99�==5AA�BB@CCD::�EE�FF�GG�99 H HJI ILKKM M�NN�OO�PP�QQ�RR S S�TTVUU�WW@XX P PYY5ZZ T TDUU�WW Q Q�[[�RR S S�WW<TT S S�TTVUU�WW Q Q�[[�RR S SDWW�TT�\\^]]_ _



` A client-side proxy (or, more precisely, its invocation handler) must “know a remote invoker”

` This knowledge is protocol-specific` It is encapsulated within an invoker proxy` A local invoker handles the case of in-process

calls in an optimized way` IIOP is treated as a special case in JBoss

a Reason: interoperability with clients written in other languages

19


Generalized EJB Containers� A container MBean is created when an EJB is

deployed� It provides middleware services to its EJB

(instance pooling, instance caching, persistence, security, transactions...)

� … by merely aggregating aspects that do the real work

� Container configurations (XML files)� For standard kinds of EJBs� For JBoss-specific extensions� Customized containers for generalized EJBs


Interceptors � Weavable aspects� Interceptor chains interposed at the client-side

and at the server side� Client-side interceptors

� Aspects that involve some form of context propagations (e.g., transactions and security)

� Handle certain invocations that can be fully processed at the client side

� Server-side interceptors� Transaction, security, logging, gathering of statistical data,

entity instance locking, detection of reentrant calls, management of relationships between entities

20


Ongoing and Future Work


Ongoing Work and Next Steps� EJB 2.1 compliance� Performance optimizations� AOP framework (JBoss 4.0)

� Class, method, field, and constructor pointcuts can be dynamically attached to any POJO

� Extensions to the meta-object protocol supported by generalized EJB containers

21


Related Work


JBoss owes a lot to many systems…

� Flexinet (Hayton et al)� Flexible remote invocation paths� Dynamic stubs

� Yasmin (Deri)� Hot-deployable components (“droplets”)

� OpenCOM (Clarke et al)� Lightweight component model� Based on a subset of COM� Dependence management, reconfiguration, method

call interception

22


Concluding Remarks


JBoss... � Demonstrates that application servers can be

built out of dynamically deployed components that provide middleware services to application components

� Brings reflective middleware to the world of mainstream computing

23


Thank you for your attention!� Q & A ...

Marc [email protected]

Francisco [email protected]

http://www.jboss.org

The JBoss Extensible Serverreverbel/slides/mw2003-slides.pdfThe JBoss Extensible Server Marc Fleury...

Documents

Transcript of The JBoss Extensible Serverreverbel/slides/mw2003-slides.pdfThe JBoss Extensible Server Marc Fleury...