Describing the functionality of EJB using the behavior protocols

Transcription

1 Describing the functionality of EJB using the behavior protocols Radek Pospíšil 1, František Plášil 1,2 1 Charles University Faculty of Mathematics and Physics Department of Software Engineering Malostranké námstí Prague 1 Czech Republic {pospisil,plasil@nenya.ms.mff.cuni.cz 2 Academy of Sciences of the Czech Republic Institute of Computer Science Pod vodárenskou væí Prague 8 Czech Republic plasil@uivt.cas.cz Abstract: component architectures are getting more popular. Industrial and academic communities try to design facilities for description of component architectures. In the SOFA/DCUP project, the description of the architecture is based on the CDL (component definition language), that embodies the behavioral protocols. The behavioral protocols of components describe the behavior of the system. One of the biggest industrial company, Sun Microsystems created the Enterprise Java Beans architecture - component architecture based on the Java language and environment. The EJB specification has not facilities for formal describing. In this paper, the behavioral protocols are used to describe the EJB. The preliminary results are presented, because the work is still in progress. 1 Introduction Today software engineering is heading to software components used to build large software architectures (component architectures). A big problem is how to describe the software component and component architecture. There are projects that deal with that problem in different ways (Wright [4], C2 [5], Rapide [6], SOFA/DCUP [7]). All approaches define a software component as reusable code and resources that provides its functionality to the runtime environment and require a functionality from the environment. The functionality is described by s (set of methods or set of accepted and emitted events) and behavior description on them (describing the requested sequencing of invoked methods or dispatched/accepted events). In the SOFA/DCUP project, behavior is based upon behavior protocols. On the other hand, there are several commercial software component architectures widely used (COM/DCOM [10], CORBA [8], JavaBeans [9], Enterprise Java Beans [1]). Unfortunately, they are not compatible, thus a software component written for one architecture is not easily portable to other architecture). Goal of this paper is to show how behavior protocols can be employed in describing the semantics of the EJB. The behavior protocols will be used to describe behavior of the Enterprise Java Beans and to discover weakness of the EJB. On the other hand, this description will may show weakness of the Behavior Protocols. The outcomes should be used to refine both of them. Also, it would valuable to rewrite the EJB specification in a formal way. In the Section 2, the concept of the behavioral protocols and concept of the Enterprise Java Beans are presented. Section 2.3 presents the description of the EJB. Section 3 presents proposed enrichment of the behavioral protocols. Section 5 summarize the achievements. 2 Concepts In this section, the behavioral protocol and the Enterprise Java Beans are briefly presented. The presentation is focused at the features needed for the goal of our project. 1

2 2.1 Enterprise Java Beans The Enterprise Java Beans (EJB) architecture is the one of the commercial component architectures [1]. The EJB architecture is tightly bound to the Java language and environment. EJB is based on the concept of EJB container, which provides services (transactions, persistence, security) to inserted (deployed) components (s) during runtime (figure 1). Also, the EJB container manages the life of the deployed s. The EJB specification introduces two phases of a s life: deployment and runtime. At the beginning of the deployment, the EJB container creates wrapping code to contacting the provided services (transaction, persistence, and security) by some of the business methods of the Remote ; the wrapping is specified by the Bean s DeploymentDescriptor. Then, the is inserted (deployed) into the EJB container. At runtime, the wrapping code and the code are executed as a part of the EJB container. This way, the functionality of a (at its Remote Interface) can be parametrized by its DeploymentDescriptor, i.e., without the s code involvement. 2.2 Behavioral protocols and Components The Behavioral Protocols is an extension of the SOFA/DCUP architecture [2]. In SOFA/DCUP, behavior protocols are specified on three levels of functionality abstraction:, frame and architecture ( protocol, frame protocol and architecture protocol). An architecture protocol has to be in the compliance relation with the corresponding frame protocol and a frame protocol has to be in the compliance relation with the corresponding protocols. The language of behavior protocols is based on regular languages (but it is not regular [3]). A key benefit of behavior protocol is a formal description of component behavior. EJB Server EJB container Account family Client Account Account (pooled) family Client client contract (pooled) instance container contract unspecified Transactions Persistence Security 2.3 Describing EJB using behavioral protocols Figure 1 The EJB specification is mostly written in an informal way. Even though several diagrams are included (e.g. those describing life cycle and transactional behavior), some parts of the specification are ambiguous. Moreover, at many place, related information is spread throughout the document. With respect to its overall size (about 100 pages), this unpleasant feature makes the specification hard-to-read. As a remedy, the primary goal of this paper is to enhance the EJB architecture specification by behavioral protocol [2] which allow to express mutual dependencies of methods calls over a set of s. An attempt to describe deployment phase by protocols can be ends up by the lack of specified s (the 2

3 document [1] specifies deployment just in an informal way). Therefore, we have focused on employing behavior protocols in the runtime phase of a s s life. During the description of the EJB, two weakness of the behavioral protocols were found. The first concerns the dynamicity of instnaces creation, which implies the need of frame protocol dynamic modification. The second problem is exception handling, thrown by Java methods. An attempt to overcome both problem, Section 3 describes the enhancements to the behavior protocols we found necessary in order to describe EJB s behavior at runtime. 3 Enrichments of the behavioral protocols 3.1 Semi-dynamic protocols During the description of EJB, the following problem arose - how to deal with dynamic EJB instances creation. Example 1illustrates the problem. The frame server provides a number of s, which are created and destroyed using s. When the system starts up, the array bn of the s is empty. Bean instances are created via invocation of the.createbean method and removed by.removebean.when such an instance is created, it gets a unique index in bn. From this point, the instance can be included in the corresponding frame protocol as a denotation instance_name[symbolic_index] (eg bn[i]), where the symbolic_index has the meaning i, thus i denotes valid instance in an array. Often, a new instance is created as a response to a request. Of course, that the instance must not exist before creation (protocol containing instances event is inactive). On the other hand, when the life of an instance is over, the protocol containing the instance s event must be inactivated. It can handle these two enrichments (1) new arr[i] construct and (2) delete arr[i] construct. The semantic of the new arr[i] is: allocate new arr (symbolic index is equal to i). Then all protocols containing arr[i] are enabled. The semantic of the "delete arr[i]" is: deallocate denoted by i. Then all protocols containing arr[i] are disabled. Another possibility to deal with this problem is to use guards [2]. Example 1 { createbean; removebean; { put; get; datastore { registerbean; unregisterbean; read; write; frame server { provides: hm; bn[]; requires: datastore ds; ( *?hm.createbean{new bn[i];!ds.registerbean?hm.removebean{!ds.unregisterbean; delete bn[i]?bn[i].put{!ds.write?bn[i].get{!ds.read 3.2 Exceptions handling The last version of the behavior protocols as described in [2] does not address exception handling. An enrichment of the behavior protocols proposed in this section is based on the Java language s exceptions handling. Java specifies that there are two possible outcomes of a method call - a value of the result type or an exception. In Java, exception handling is syntactically based on the throws clause after the name of the method and the try-catch construct. The enrichment of the notation of the behavior protocol is follows a similar patern. Let m be a method which may throws exception exc, the abbreviation!m is defined as!m8;(?m9+?exception9). In the same sense,?m is redefined as?m8;(!m9+!exc9). Thus, if a request for an event m is emitted (!m8), then the emitter must expect two alternative outcomes: (1) the standard return from the method invocation, i.e., m9, or (2) an 3

4 exception exc9. This mechanism can be implicitly enabled by the throws clause in the signature of an. Then all method invocations are subject to exception handling. Until this point, the behavior protocol does not change much. On the other hand, the result protocol for an exception s handling becomes complicated and hard-to-read. In the Example 2, exception handling for two method sequences of invocations is illustrated. In the a) case, there are two invocation of a method m. Then the protocols for success return and exception handling is added (case b)). The disadvantages of handling exception in behavior protocols this way is the direct usage of!,?,8,9 and a complicated protocol trace. Example 2 a.!m8;(?m9 +?exc9);!m8;(?m9 +?exc9) b.!m8;((?m9;(!m8;((?m9; protocol_for_success) + (?exc9; protocol_for_exception2))) + (?exc9; protocol_for_exception1)) To overcome the problem, we propose to enrich behavior protocols by exception protocol. This enrichment follows the idea of the Java s try-catch construct. The basic idea is that the exception protocol is placed into the catch part of a behavior protocol. When a sheltered protocol sp (placed between try and catch) raises an exception (exc9), processing of sp is interrupted and processing of the exception protocol ep starts. When ep processing ends, the processing of the whole protocol continues after sp (as if sp was finished ordinally). The corresponding notation takes the form: (sheltered protocol)(exception protocol). Example 3 illustrates how the exception handling form the Example 2 can be modified by employing the sheltered and exception protocols idea. Example 3 a.!m;!m b. ((!m;!m)(?exc9;(protocol_for_exception1+protocol_for_exception2))); protocol_for_success Exceptional protocols can be nested to allow exception s pre-handling ( catching an exception and re-throwing it to the parent s exception protocol). Passing an exception from a child s exception protocol to the parent s exception protocol is done by using the t type of an event [2]. If an exception event must be returned to the caller, the notation of!exc9 is used. In Example 4, nested exception protocols are used. This example is more complex. It presents the frame protocol of Database, which provides the IDBServer ( user ) and requires the IDBAccess ( data storage ). The Insert and Deletemethods can throw InsertException and DeleteException. If a InsertException is thrown, the exception protocol interrupts the sheltered protocol and the exception protocol emits the exception (re-throws) to the client (see the IDBServer ). Then the execution of the protocol continues with next iteration of the sheltered protocol, because the iteration operator * is not placed in the sheltered protocol. If the DeleteException is emitted, the exception is re-emitted to the parent s exception protocol using the t type of the event. In the example, DeleteException means that a serious problem occurred in a data storage. Then the data storage is closed (!dbacc.close), DeleteException returns, and the protocol ends. Example 4 IDBServer { Insert throws InsertException; Delete throws DeleteException; Query; (Insert Delete Query)* ; IDBAccess { Open; Insert throws InsertException; Delete throws DeleteException; Query; Close; Open; (Insert Delete Query)*; Close ; frame Database { provides: IDBServer dbsrv; requires: IdatabaseAccess dbacc; (!dbacc.open; ((?dbsrv.insert{!dbacc.insert +?dbsrv.delete{!dbacc.insert+?dbsrv.query{!dbacc.query )(?InsertException9;!InsertException9 +?DeleteException9; tdeleteexception9 ))*!dbacc.close 4

5 ; )(?DeleteException9;!dbAcc.Close;!DeleteException9) 4 Employing behavior protocols in EJB - case study As a case study, we choose a relatively complicated method interplay semantics related to employing transactions in a EJB. As the semantics illustrated is related to EJB s in general, we will use a generic which has methods methodtx.. Where TX... stand for one of the transactional attributes defined for EJB s(e.g. method_tx_required method is deployed with TX_REQUIRED transactional attribute). However, the attribute TX_BEAN_MANAGED is not covered here, because once used, all methods of a have to be marked also as TX_BEAN_MANAGED. In Appendix A, the runtime phase of a generalized StatefulSession instance behavior is described via behavioral protocols. In this preliminary version, the frame protocol of a StatefulSession instance is considered. The reason for choosing the StatefulSesion is its non trivial transactional behavior. The key components used in the description are captured in Figure 2. The provides the SessionHome. This serves mainly to create/remove instances. The is in fact the EJBObject. This is entry point to functionality of a instance via its. The StatefulSessionBean is the of a. The implements all methods specified by EJBFunctionality (the s business methods) and the methods called by the corresponding to notify the about creation/remove/activation/passivation process. The functionality of a Bean is a part of the StatefulSession instance (frame SBInstance). The UserTransaction and TM (TransactionManager) s are used to access transaction service. EJB Server EJB container family Client (pooled) TM Transactions Figure 2 To capture the behavior of the components from Figure the following two frames are introduced in Appendix A.The first frame is Services. It describes the services of the EJB Server (currently only transaction service). It provides TM and an array of UserTransaction s. The semi-dynamicity of protocols is employed in creating/removing instances of UserTransaction. The second frame is SBInstance. It describes the life and transactional behavior of a StatefulSession instance. In compliance with the EJB specification, the StatefulSession instance must modify its transaction behavior if one of its methods is invoked in a transaction context. On the frame level, it is not possible to listen on all s of transaction manager (TM); thus, guards must be used to enable portions of the corresponding frame protocol, depending upon if a transaction context is propagated or not. According to the EJB specification, there are two states of a StatefulSession instance, in which invocation of a method with a specific transaction 5

6 attribute is not allowed - in such a case, an exception is returned. 5 Conclusion In this paper, a preliminary description of the EJB transactional behavior was presented. Two problems were emphasized: (1) the exception handling in the behavior protocol and (2) the semi-dynamicity of the behavior protocols. A solution to both of them was proposed. A further research topic have been identified - the area of dynamicity of behavior protocols. The research should aim at evaluation of different approaches to protocol dynamicity 6 References [1] Sun Microsystems, EJB Specification, [2] František Plášil, Stanislav Višnovský, Miloslav Bešta: Behavioral Protocols and Components, TOOLS 1999 [3] Stanislav Višnovský: Master theses, Charles University, 1999 [4] Allen, R. J.: A Formal Approach to Software Architecture. Ph.D. Thesis, School of Computer Science, Carnegie Mellon University, Pittsburgh, 1997 [5] Medvidovic n.: The C2 style, [6] Luckham D.: Rapide project, [7] Plasil, F., Balek, D., Janecek, R.: SOFA/DCUP Architecture for Component Trading and Dynamic Updating. In Proceedings of ICCDS '98, Annapolis, IEEE CS, 1998, pp [8] OMG: CORBA, [9] Sun Microsystems: JavaBeans, [10] Microsoft: COM/DCOM, 6

7 Appendix A - the behavioral protocols of EJB architecture (preliminary version) // EJB business methods EJBFunctionality { method_tx_not_supported; method_tx_required; method_tx_supports; method_tx_requires_new; method_tx_mandatory; (method_tx_not_supported + method_tx_required + method_tx_supports + method_tx_requires_new + method_tx_mandatory)* // EJB s EJBObject: EJBFunctionality { getejbhome; gethandle; getprimarykey; isidentical; remove; (getejbhome + gethandle + getprimarykey + isidentical + method_tx_not_supported + method_tx_required + method_tx_supports + method_tx_requires_new + method_tx_mandatory)* + remove // EJB base EJBHome { remove; getejbmetadata; (getejbmetadata + remove)* // SessionBean SessionHome: EJBHome { create; (create + getejbmetadata + remove)* // Session synchnronization s SessionSynchronization { afterbegin; aftercompletion; beforecompletion; (afterbegin; ((beforecompletion; aftercompletion) + aftercompletion))* // Session StatefulSessionBean: EJBFunctionality, SessionSynchronization { ejbactivate; ejbpassivate; ejbremove; setsessioncontext; ejbcreate; setsessioncontext; ejbcreate; ( (method_tx_not_supported + method_tx_supported + method_tx_required + method_tx_requires_new + method_tx_mandatory+(ejbpassivate; ejbactivate))*+ (afterbegin; (method_tx_not_supported + method_tx_supported + method_tx_requires + method_tx_mandatory + method_tx_requires_new)*; ((beforecompletion; aftercompletion) + aftercompletion) )* )*; ejbremove // UserTransaction UserTransactioin { begin; commit; getstatus; rollback; setrollbackonly; settransactiontimeout; (begin; setrollbackonly*; (commit + rollback)) (getstatus + settransactiontimeout)* 7

8 // Transaction Manager TM { getusertransaction; suspendtransaction; wakeuptransaction; registerxaresource; getcurrenttransaction; (getusertransaction + suspendtransaction + waketransaction + registerxaresource+getcurrenttransaction)* // services frame frame services { provides: TM tm; // Transaction Manager UserTransaction tx[]; // array of UserTransaction s requires: ( (?tm.getusertransaction{new UserTransaction[i] +?tm.suspendtransaction +?tm.waketransaction +?tm.registerxaresource +?tm.getcurrenttransaction) (?tx[i].begin; tx[i].setrollbackonly*; (?tx[i].commit{delete tx[i] +?tx[i].rollback{delete tx[i])) (?tx[i].getstatus +?tx[i].settransactiontimeout) )* // StatefulBean instance frame frame SBInstance { provides: EJBObject sso; // EJB requires: StatefulSessionBean ssb; // StatefulSession TM tm; // Transaction Manager UserTransaction tx[]; // array of UserTransaction s!ssb.setsessioncontext;!ssb.ejbcreate; ( [invocations are in TX context - tx[i]]( // method TX_NOT_SUPPORTED and TX_REQUIRES_NEW do not associate instance with transaction tx[i] (?sso.method_tx_not_supported{!tm.susspendtransaction;!ssb.method_tx_not_supported;!tm.wakeuptransaction+?sso.method_tx_requires_new{!tm.suspendtransaction;!tm.getusertransaction; tx[j].begin;!ssb.method_tx_requires_new; ((!tx[j].commit;!ssb.aftercompletion) + (!ssb.beforecompletion;!tx[j].rollback;!ssb.aftercompletion)); tx[i].wakeuptransaction)*; // TX_SUPPORTS, TX_REQUIRED and TX_MANDATORY associate instance with transaction tx[i] (?sso.method_tx_supports{!ssb.method_tx_supports+?sso.method_tx_required{!ssb.method_tx_required+?sso.method_tx_mandatory{!ssb.method_tx_mandatory+ (?sso.method_tx_not_supported9;!remoteexception8)(?remoteexception9;!remoteexception8)+ (?sso.method_tx_requires_new9;!remoteexception8)(?remoteexception9;!remoteexception8))*; // when tx[i] is commited or rollbacked (!ssb.aftercompletion+(!ssb.beforecompletion;!ssb.aftercompletion)) )+ [invocations are not in TX context]( (?sso.method_tx_not_supported{!ssb.method_tx_not_supported+?sso.method_tx_supports{!ssb.method_tx_supported+?sso.method_tx_requires{!tm.getusertransaction;!tx[i].begin;!ssb.method_tx_requires; ((!tx[i].commit;!ssb.aftercompletion)+(!ssb.beforecompletion;!tx[i].rollback;!ssb.aftercomple tion)) +?sso.method_tx_requires_new{!tm.getusertransaction;!tx[i].begin;!ssb.method_tx_requires_new; ((!tx[i].commit;!ssb.aftercompletion)+(!ssb.beforecompletion;!tx[i].rollback;!ssb.aftercomple tion)) + (?sso.method_tx_mandatory8;!remoteexception9)(?remoteexception9;!remoteexception8)+ (!sb.ejbpassivate;!sb.ejbactivate))* )*;?sb.ejbremove 8