Performance Analysis and Design of A
Wireless Networks
Fatma Omara1, Ragab El Saiedy2,*Reham Anwer3
1
Computer science department, Information Systems and Computers Faculty, Cairo University, Cairo -Egypt. E-mail: fatma_omara@hotmail.com
2, 3
Math's Department. Science Faculty, EL Minufiya University, Shebin-El Kom -Egypt.
3
*Tel : 0020482372447 - 0020165851433 E-mail: rehamteacher@yahoo.com
Abstract
Business rules have been defined as "declarations" of policy or conditions that must be satisfied to determine how operational decisions and the organization must be made. In other words, business rules specify action on the occurrence of particular business events, including" state of being" changes concerning individuals and groups of individuals infrastructure, consumables, informational resources, and even business activities. The aim is to discuss an approach to business rules centric development paradigm, known as Manchester Business Rules Management which comprises of a number of activities and techniques. The Basic idea is applying the elicitation organization, and management of business rules for implementing atomic read/write shared memory in mobile ad hoc network according to the Geoquorum algorithm. It also associates rule statements with information entities of their universe of discourse, in order to facilitate their management by allowing rules grouping and retrieval according to different criteria.
Keywords:Software Design phase, Specification, Business Rules, Mobile Ad Hoc Networks, MBRM.
I. INTRODUCTION
allows existing distributed algorithm to be adapted for highly dynamic ad hoc environments one such fundamental problem in distributed computing is implementing atomic read/ write shared memory [1]. Atomic memory is a basic service that facilitates the implementation of many higher level algorithms (see fig.1). For example: one might construct a location service by requiring each mobile node to periodically write its current location to the memory. Alternatively, a shared memory could be used to collect real – time statistics, for example: recording the number of people in a building here, a new algorithm for atomic multi writes/multi- reads memory in mobile ad hoc networks. The problem of implementing atomic read/write memory is divided into two parts; first, we define a static system model, the focal point object model that associates abstract objects with certain fixed geographic locales. The mobile nodes implement this model using a replicated state machine approach. In this way, the dynamic nature of the ad hoc network is masked by a static model. Moreover it should be noted that this approach can be applied to any dynamic network that has a geographic basis. Second, an algorithm is presented to implement read/write atomic memory using the focal point object model. The implementation of the focal point object model depends on a set of physical regions, known as focal points [2].The mobile nodes within a focal point cooperate to simulate a single virtual object, known as a focal point object. Each focal point supports a local broadcast service, LBcast which provides reliable, totally ordered broadcast. This service allows each node in the focal point to communicate reliably with every other node in the focal point. The focal broadcast service is used to implement a type of replicated state machine, one that tolerates joins and leaves of mobile nodes. If a focal point becomes depopulated, then the associated focal point object fails. (Note that it doesn't matter how a focal point becomes depopulated, be it as a result of mobile nodes failing, leaving the area, going to sleep. etc. Any depopulation results in the focal point failing). The Geoquorums algorithm implements an atomic read/write memory algorithm on top of the geographic abstraction, that is, on top of the focal point object model. Nodes implementing the atomic memory use a Geocast service to communicate with the focal point objects. In order to achieve fault tolerance and availability, the algorithm replicates the read/write shared memory at a number of focal point objects. In order to maintain consistency, accessing the shared memory requires updating certain sets of focal points known as quorums. An important aspect of our approach is that the members of our quorums are focal point objects, not mobile nodes. The algorithm uses two sets of quorums (I) quorums (II) put- quorums with property that every get-quorum intersects every put-get-quorum. There is no requirement that put-get-quorums intersect other put-get-quorums, or get-quorums intersect other get-quorums. The use of quorums allows the algorithm to tolerate the failure of a limited number of focal point objects. Our algorithm uses a Global Position System (GPS) time service, allowing it to process write operations using a single phase, prior single-phase write algorithm made other strong assumptions, for example: relying either on synchrony or single writers. This algorithm guarantees that all read operations complete within two phases, but allows for some reads to be completed using a single phase: the atomic memory algorithm flags the completion of a previous read or write operation to avoid using additional phases, and propagates this information to various focal paint objects[2]. As far as we know, this is an improvement on previous quorum based algorithms. For performance reasons, at different times it may be desirable to use different times it may be desirable to use different sets of get quorums and put-quorums [2]. For example: during intervals when there are many more read operations than write operations, it may be preferable to use smaller get- quorums that are well distributed, and larger put-quorums that are sparsely distributed. In this case a client can rapidly communicate with a get-quorum while communicating with a put – quorum may be slow. If the operational statistics change, it may be useful to reverse the situation. The algorithm presented here includes a limited "reconfiguration" Capability: it can switch between a finite number of predetermined quorum systems, thus changing the available put-quorums and get –quorums. As a result of the static underlying focal point object model, in which focal point objects neither join nor leave, it isn't a severe limitation to require the number of predetermined quorum systems to be finite (and small). The resulting reconfiguration algorithm, however, is quite efficient compared to prior reconfigurable atomic memory algorithms. Reconfiguration doesn't significantly delay read or write operations, and as no consensus service is required, reconfiguration terminates rapidly [1] [3].
1.1Mathematical Notation for Geoquorums Approach
- I the totally- ordered set of node identifiers.
- i0 є I, a distinguished node identifier in I that is smaller than all order identifiers in I. - S, the set of port identifiers, defined as N>0× OP×I,
Where OP= {get, put, confirm, recon- done}.
- O, the totally- ordered, finite set of focal point identifiers. - T, the set of tags defined as R≥0 × I.
- Vx the set of values for x - v0,x є Vx , the initial value of X
- M, a totally-ordered set of configuration names
- c0 є M, a distinguished configuration in M that is smaller than all other names in M. - C, totally- ordered set of configuration identifies, as defined as: R ≥0 ×I ×M
- L, set of locations in the plane, defined as R× R
Put/get variable type
StateTag
T, initially< 0.i0> Value
V, initially v0Config-id
C, initially< 0, i0, c0> Confirmed-set C T, initially Ø Recon-ip, a Boolean, initially false OperationsPut (new-tag, new-value, new-Config-id) If (new-tag> tag) then
Value ←new-value Tag ← new-tag
If (new-Config-id > Config-id) then Config-id ← new-config-id Recon-ip ← true
Return put-Ack (Config-id, recon-ip) Get (new-config-id)
If (new-config-id >Config-id) then Config-id ← new-Config-id Recon-ip ←true
Confirmed ← (tag
confirmed-set)Return get-ack (tag, value, confirmed, Config-id, recon-ip) Confirm (new-tag)
Confirmed-set ←confirmed –set U {new-tag} Return confirm-Ack
Recon –done (new-Config-id) If (new-Config-id=Config-id) then Recon-ip ←false
Return recon-done-Ack ( )
Fig .1 Definition of the Put/Get Variable Type
1.2 Operation Manager Client
This automaton receives read, write, and recon requests from clients and manages quorum accesses to
implement these operations. The Operation Manager (OM) is the collection of all the operation manager clients (OMi, for all i in I).it is composed of the focal point objects, each of which is an atomic object with the put/get variable type [1] [2]. Also, the focal point emulator implements the focal point object Model in an ad hoc mobile network. The nodes in a focal point (i.e. in the specified physical region) collaborate to implement a focal point object. They take advantage of the powerful LBcast service to implement a replicated state machine that tolerates nodes continually joining and leaving .This replicated state machine consistently maintains the state of the atomic object, ensuring that the invocations are performed in a consistent order at every mobile node [3].When a node enters the focal point, it broadcasts a join-request message using the LBcast service and waits for a response. The other nodes in the focal point respond to a join-request by sending the current state of the simulated object using the LBcast service. As an optimization, to avoid unnecessary message traffic and collisions, if a node observes that someone else has already responded to a join-request, and then it does not respond. Once a node has received the response to its join-request, then it starts participating in the simulation, by becoming active.
When a node receives a Geocast message containing an operation invocation, it resends it with the Lbcast service to the focal point, thus causing the invocation to become ordered with respect to the other LBcast messages (which are join-request messages, responses to join requests, and operation invocations ).since it is possible that a Geocast is received by more than one node in the focal point ,there is some bookkeeping to make sure that only one copy of the same invocation is actually processed by the nodes. There exists an optimization that if a node observes that an invocation has already been sent with LBcast service, then it does not do so. Active nodes keep track of operation invocations in the order in which they receive them over the LBcast service. Duplicates are discarded using the unique operation ids. The operations are performed on the simulated state in order. After each one, a Geocast is sent back to the invoking node with the response. Operations complete when the invoking node with the response. Operations complete when the invoking node remains in the same region as when it sent the invocation, allowing the geocast to find it. When a node leaves the focal point, it re-initializes its variables [1] [2].
A subtle point is to decide when a node should start collecting invocations to be applied to its replica of the object state. A node receives a snapshot of the state when it joins. However by the time the snapshot is received, it might be out of date, since there may have been some intervening messages from the LBcast service that have been received since the snapshot was sent. Therefore the joining node must record all the operation invocations that are broadcast after its join request was broadcast but before it received the snapshot .this is accomplished by having the joining node enter a "listening" state once it receives its own join request message; all invocations received when a node is in either the listening or the active state are recorded, and actual processing of the invocations can start once the node has received the snapshot and has the active status. a precondition for performing most of these actions that the node is in the relevant focal point. This property is covered in most cases by the integrity requirements of the LBcast and Geocast services, which imply that these actions only happen when the node is in the appropriate focal point[1] [3].
Operation Manager Client Transitions Input write (Val) i
Effect:
Current-port-number Current-port-number +1
Op < write, put, <clock, i>, Val, recon-ip, <0, i0, c0>, Ø> Output write-Ack ( )i
Precondition:
Conf-id=<time-stamp, Pid, c> If op .recon-ip then
√ C/
M, э P
put-quorums(C/): P C op. acc ElseЭ P put-quorums(C): P C Op. acc Op .phase=put
Op. type=write Effect:
Op. phase idle
Confirmed confirmed U {op. tag} Input read ( )i
Effect:
Current-port-number Current-port-number +1
Op < read, get, ┴, ┬, recon-ip, <0, i0, c0>, Ø> Output read-ack (v)i
Precondition:
Conf-id=<time-stamp, Pid, c> If op. recon-ip then
√ C/ M, э G get-quorums(C/): G C op. acc Else
Op. phase=get Op. type=read Op. tag
confirmed v= op. value Effect:Op .phase idle
Internal read-2( )i Precondition:
Conf-id=<time-stamp, Pid, c> √ C/ M, э G get-quorums(C/
): G C op. acc Else
Э G
get-quorums(C): G C op. acc Op. phase=getOp. type=read Op. tag
confirmed Effect:Current-port-number Current-port-number +1
Op. phase put
Op. Recon. ip recon-ip
Op. acc Ø
Output read-Ack (v)i Precondition:
Conf-id=<time-stamp, Pid, c> If op. recon-ip then
√ C/ M, э P put-quorums(C/): P C op. acc Else
Э P put-quorums(C): P C op. acc Op. phase=put
Op. type=read v=op. value Effect:
Op. phase idle
Confirmed confirmed U {op. tag} Input recon (conf-name)i
Effect:
Conf-id <clock, i, conf-name>
Recon-ip true
Current-port-number Current-port-number +1 Op < recon, get, ┴, ┴, true, conf-id, Ø> Internal recon-2(cid)i
Precondition
√ C/ M, э G get-quorums(C/): G C op. acc √ C/ M, э P put-quorums(C/): P C op. acc Op. type=recon
Op. phase=get Cid=op. recon-conf-id Effect
Current-port-number Current-port-number +1 Op. phase put
Op. acc Ø
Output recon-Ack(c) i Precondition
Cid=op. recon-conf-id Cid= <time-stamp, Pid, c> Э P put-quorums(C): P C op. acc Op. type=recon
Op. phase=put Effect:
Recon-ip false Op. phase idle Input geo-update (t, L) i Effect:
Clock 1
Fig .2 Operation Manager Client Read/Write/Recon and Geo-update Transitions for Node
II. COLLECTING AND CLASSIFYING BUSINESS RULES
The term "business rule" has been used by different methodologists in different ways. In Ref [4] business rules are "statements of goals, policies, or constraints on an enterprise's way of doing business" .In Ref [5], they are defined as "statements about how the business is done" i. e guidelines and restrictions with respect to states and processes in an organization.
2.1The Development Framework
The MBRM approach covers a number of key information system development stages, all of which are centered on a business rules paradigm. Elicitation is concerned with the identification of stakeholders, the domain ontology and the rules that govern the behavior of the business application [4].Representation deals with the way that business rules are specified according to their typology [4].Mapping is concerned with the way that business rules specification is linked to equivalent S.W design structures. Implementation deals with the way that business rules specification is linked to equivalent software designs are realized in software code and Database structures [5](see fig.3) .
Fig. 3 The Manchester Business Rules Management (MBRM) Framework.
2.2 Elicitation and Analysis of Business Rules:
The MBRM framework, which constitutes the methodological basis of this work, identifies three views for approaching information systems analysis: The Intentional view, the Operational view and the information systems view, along the lines [4]:
Intentional Analysis: contains preparatory activities aiming at an initial understanding of the organization and crystallization of the project's scope and objectives.
Operational Analysis: involves the development of the necessary enterprise knowledge context, making references to central business process concepts, such as actors, activities, activity enablers and information objects that are used or produced by enterprise activities.
Is Architecture Analysis: Bridges the gap between analysis and design, through the transformation of implementation- free requirements to implementation specific requirements and specifications. During each one of the above analysis stages, business rules are treated in different ways. Therefore, we distinguish between "Intentional rules", "operational rules" and "is architecture rules".
Elicitation
Implementation
Business Rules
Representation
Intentional Rules: are expressions of business rules seen from the Business context perspective. They express laws, external regulation or principles and good practices specifying the way on organization Conducts business and are usually expressed in the from of a natural Language statements.
Operational Rules: are expressions of business rules approached from a business process perspective. They prescribe action on the occurrence of some business event, or describe valid states of an organization's information entities [6].
"Is Architecture Rules": are business rule statements examined from an implementation perspective. They are expressed in an implementation-specific manner, i.e. in accordance with the implementation paradigm that has been selected for the information system under development (can active DB) [7].
2.3.1 Classifying Intentional Rules for Supporting Intentional Rule Analysis
Management Rules: are expressions of business policy or constraints that deal with managerial issues, such as strategy development, tactical planning, business performance management, financial management, investments management (quality assurance and issues management)[4] [5].
Business Development Rules: deal with feasibility exploration concerning a new product or service idea, new product or services design, an existing product's or service's enhancement.
Core Business Rules: Constitute the wider rule category and depend on the particular characteristics of different industries. Some examples are: Product manufacturing, distribution rules, store operational rules, service provision network management rubles [4] [8].
Administration Rules: It Refers to supporting business activity policies and constraints, and can represent facilities construction and maintenance rules, inventory control rules, IT management rules, legal issues and human resources management rules.
2.3.2 Classifying Operational Rules for Supporting Operational Rule Analysis
The Knowledge modeling "exercise" described in this work mainly aims at the design of business supporting information system, which will either be built from scratch, or may be based on the configuration of a packaged IT solution. An initial step in information systems design deals with "architecture", which concerns the identification of its distinct (although usually integrated) operational parts. Each one of these parts has a specific objective ("goal").This objective is fulfilled through the facilitation of a specific workflow ("activities") [4] [9]. A systematic workflow involves one or more types of users ("actors"), uses, or produces information ("information objects"), and also engages other enterprise resources ("activity enablers") ( see fig.4) .
Fig. 4 Operational Rule Analysis Steps.
The term "context" represents the boundaries of the (business or system) application under investigation, and is characterized by the aforementioned enterprise knowledge entities: ("actors"), ("activities"), ("information object") an" activity enablers". "Operational rules" describe structural and behavioral characteristics of the above enterprise knowledge entities. More specifically, "operational rules" belong in two major groups: "Descriptive Rules" and "Prescriptive Rules". "Descriptive rules" describe valid states of an organization's informational entities, and "prescriptive rules" prescribe action on the occurrence of some business event. This approach is also followed by several existing methodologies, which" distinguish between structural and action
Selection of a particular
analysis context
Identification of main context actors
Identification of main Actor
Activities
Identification of main Activity information
objects Identification
of main Activity Enablers
assertions [10]. Descriptive rules": Can be specialized in "information object rules," "actor rules," "activity rules" and" activity enables rules" "Information object rules" examine the attributes of " information objects". "Information objects" represent entities containing information that is useful for an organization. A service proposal, a product purchase order, or even a product is represented by the corresponding" information objects"[5].
"Information Object Rules": specify how an "information object" attribute derives from others information object" attributes ("information object attribute derivation rule"), or define "information object" sets based on their attribute values " similarity ("information object set rules"), or examine integrity ( "information object integrity rules")." Actor rules" are very similar; dealing with "actor" attributes (i.e. attributes of employees, partners, customers and so on) [4] [11] (see fig.5).
Fig. 5
High Level Classification of Operational Rules"Activity Rules": describe status of activities and" activity enabler rules" are concerned with the status of "activity enablers", the infrastructure that allows the execution of activities." Prescriptive rules": are distinguished into "workflow rules" and "information assertion rules", examine a set of conditions on the occurrence of some event, and perform information updates accordingly: creation or deletion of information entities ("information operation rules"), assertion of information entity attribute values (" attribute assertion rules"), or assertion of information entities association (" association assertion rules") [7][12].
III. ORGANIZING BUSINESS RULES IN A REPOSITORY ENVIRONMENT
The Organizing Business Rules represent the relations between various enterprise knowledge entities, which are central to the ontological analysis of business rules. Such entities are "goal" "role", "activity", "event", "activity enabler" and "information object" [4].Within a particular enterprise context, "actors" are involved in the realization of different business "goals", through the execution of enterprise "activities". "Activities", which are grouped in enterprise "roles", are triggered by business" events", and make use of "activity enablers", i.e. supporting material infrastructure. They also consume or produce information, which is "packaged" in "information object". All the information entities mentioned above have attributes. Therefore there are" "actor attributes", "activity attributes", "activity enablers attributes" and "information object attributes" [13].Relationships that are worth mentioning within the business rules ontology context concern the facts that:
"Goals" are satisfied by" Actors".
"Activities" are part of "Roles".
"Activities" are triggered by "events"
"Activities" are played by "Actors" ("Actor/Activity relationship").
"Activities " use " Activity enablers" ("Activity/Activity-enabler-relationship").
"Activities" produce/consume "Information objects" ("Activity /Information object relationship")
IV. THE REPOSITORY SCHEMA
The structuring of rules according to the Even Condition Action paradigm (ECA) (see fig.6), which was also widely used in the area of active databases, According to the ECA paradigm, "as soon as" on event occurs, and as long as all the conditions hold, the specified action must be performed. A certain "Operational rule" may contain zero, one or more than one event ("WHEN part"), zero one or more than one events ("WHEN part"),
Operational Rule
Descriptive rule Prescriptive rule
Workflow Rule Information
Assertion Rule Activity enabler
rule Information
object rule Activity
Rule Actor
zero, one or more than one conditions ("IF part") and one and only one action part ("THEN part"). An "operational rule" may also reference one or more relationships of the following types. Activity/ Activity enabler relationships", "activity/ information object relationships" or "actor/activity relationships". This type of reference determines the context of the rule, especially in cases of complex condition parts, where different informational entities are examined, and it is not clear how these entities relate to each other. Observe that, the information already exists in the information model developed during the initial stages of rules analysis, however, including in the rule statement itself makes things clearer during the whole analysis process[11] [13].
Fig. 6 Structuring Operational Rules in the Rule Repository schema.
V. BUSINESS RULES FOR IMPLEMENTING ATOMIC READ/WRITE SHARED MEMORY IN MOBILE AD HOC NETWORKS
The geoquorums approach, for implementing atomic read/write shared memory in mobile ad hoc networks based on associating abstract atomic objects with certain geographic locations. In the previous sections the following points are discussed and for summary, the existence of focal points as geographic areas that are normally "populated by mobile nodes" is explained, the geoquorums algorithm uses & quorum –based strategy in which each quorum consists of a set of focal point objects. The quorums are used to maintain the consistency of the shared memory and to tolerate limited failures of the focal point objects, which may be caused by depopulation of the corresponding geographic areas. Overall the new geoquorum algorithm efficiently implements read/write operations in a highly dynamic, mobile networks .this application is implemented using geoquorum algorithm. This algorithm consists of two independent components: the focal point emulator, which implements the focal point object model in highly dynamic environment, and the operation manager, which is a quorum- based algorithm for read/write shared memory. By replicating data at multiple focal point objects and performing read and write operations on quorums of focal point objects, the operation manager ensures that the data is maintained reliably and consistently. The operation manager relies on the variable type of the focal point objects, which we call the put / get variable type. These objects support specially defined operations, put / get and config / reconfig that allow clients to send information to the objects and retrieve information from the objects also switching between the available put / get quorums thus exchanging information .each focal point supports a local broadcast service (LBcast service),which provides reliable totally ordered broadcast. This service allows each node in the focal point to communicate reliably with every other node in the focal point. The mobile nodes also depend on a global message delivery service, Geocast. The Geocast service delivers a message to a specified destination point in the plane and every node within a certain radius of that destination.
Activity/Activity Enabler Relationship
Activity / Information Object Relationship
Actor/Activity Relationship
When part
If part
Then part Operational rule
References
Has 0….n
Has 0….n
Has 1….1
1- Descriptive Rule Examples
(A) The First Operational Rule
The first operation rule is talking about an "actor attribute value assertion rule", (i.e. "a specialization of actor rule") (see fig.7).
Context:- WHEN Part If part Type: Dynamic
Attribute Value Condition Defined on
(Operation Manager Client) Focal Point Objects (FPO) Operation Manager Client Invoke put operation: (Update the FPO) Get operation:
(Retrieve the value from the focal point objects) Replication operation:
(Allows the operation manager client to guarantee fault- tolerance of FPO).
THEN part Type:
Attribute value assertion Defined on
Focal Point (FP).port sets FP. port sets = Geocast service
Fig.7 Information entity model for implementing Atomic Read/Write shard memory in mobile ad hoc network (B)The Second Operational Rule
The second operation rule is an "actor attribute value transition rule" "i.e. specialization of an "actor integrity rule", which is a specialization of actor rule").
Context:-
FPE Server
oA node receives a Geocast atomic read/ write containing an operation invocation
oIt reconfig the atomic object read/write with LBcast service to FP.
oCausing the invocation to become ordered with respect to other LBcast objects.
Contact
Leads to Submits
Operation Manger Client oPut operation. oGet operation. oReplication
operation
Uses
Invoke
FPE client
Respond
Responds
To
The mobile
node Performance of the Geoquorum Algorithm
WHEN part If part
Type: Dynamic Attribute Value condition
Defined on FPE client THEN part Type: code FPE client CHANGES From
"Invoke interface to the mobile node "To" respond interface to the mobile node''. Code
(C)The Third Operational Rule
The third rule is concerned with the corresponding "operational rule" is an "activity attribute value integrity rule "defining the allowed values of activity attribute FPE server."Activity attribute value integrity rule "is a special type of "activity integrity rule" which is a specialization of "activity rule".
Context:- WHEN part If part
Type: Dynamic Attribute Value condition
Defined on FPE Server THEN part Type: Automaton FPE server LBcast service IN
("Received a Geocast read write object", "reconfig the read/write object with LBcast service to FP"). Automaton
(D)The Last Descriptive Rules
The Last Descriptive rules are all" information object rules", deriving from "information object Attribute derivation rule". (Specialization of the "information object rule") .
Context:- WHEN part If part THEN part
Type: Attribute value Assertion
Defined on
Focal point Emulator server signature Focal point Emulator client
Focal point Emulator server transitions
Focal point Emulator server transitions= focal point Emulator Client transition +focal point server signature transition
2- Information Object Association Cardinality Rule
(A) An "Information Object Association Cardinality Rule" is a specialization of "information object integrity rule", which is also a special type of "information object rule".
Context:- Set ports WHEN part If part
Cardinality Condition Defined on ports Contact
THEN part Type: Integer CARDINALITY of Current Port Number
Current port Number= current port Number +1 Integer
(B)Another "Information Object Association Cardinality Rule" is the expression "the number of objects submitted by a FPO (Focal Point Object):-
Context:-
Focal Point Object (FPO) WHEN part
IF part
Type: Dynamic Association Cardinality Condition
Defined On Operation Manager Client (OMC) Proposal THEN part
Type: Integer CARDINALITY of Config- id
Recon –ip New- Config- id FPO
CHANGES from Recon to recon- Ack Invoke to respond With
New- Config-id= Config-id And recon –ip=true Integer
3- Prescriptive Rule Examples
(A)The First One is an "Information Assertion Rule"
Context:- FPE (Focal Point Emulator)
FPE server (Focal Point Emulator Server) FPE client (Focal Point Emulator Client)
FPE server transition (Focal Point Emulator Server Transition) OM (Operation Manger)
WHEN part IF part
Type: Dynamic Attribute Value Condition Defined on
Focal Point (FP) server status THEN part
Type Object Defined on
Performance of Geoquorum Algorithm =FPE Server Performance + Operation Manger (OM) Performance CREATE
(B) The Second "Information Assertion Rule Results in the Establishment of a Relationship between Two Information Entities".
Context:-
External signature- proposal WHEN part
IF part
Type: Dynamic Attribute Value Condition Defined On Proposal
New-config-identifier Config- identifier Read- ack invoke Write- ack response Recon-done ack THEN part
Type: Association Assertion
Defined on read action, write action, recon action Read action= read –ack invoke
Write action= write- ack response Recon action =recon-done-ack
(C)The Last Example is "Work Flow"
Context: ports Sequence _ number Node_ identifier Operation _ identifier WHEN part
If part
Type: Set condition
Defined on ports _set _offers Put, get, config, recon operations THEN part
Type: Activity Invocation Defined on new operation Ports_ sets_ offers Submitted
<current_ port_ number, op, i>= <current_ port_ number, op, i> +1 New operation
RESULTS AND DISCUSSION
Finally the Manchester Business Rules Management (MBRM) approach assumes the existence of underlying information and workflow models, which ensures structural and notational consistency of rule expressions, and allows efficient rule grouping and retrieval. The main contribution of the work presented here relates to the repository schema for structuring and organizing rules, which links rules with goals and other derived rules, with information about the rule collection sessions that revealed them, with business or information system events that trigger their execution (if there are any),and with the various information entities (i.e." actors", "activities", "activity enablers" and "information objects ")that constitute their context ,and that characterize their "IF" and "THEN parts".
CONCLUSIONS AND FUTURE WORK
Basic idea is Applying the management of business rules (MBRM) for implementing atomic Read /write shard memory in mobile ad hoc network according to the Geoquorum Algorithm. Finally, the specification for the Geoquorum Algorithm can be done with different techniques.
ACKNOWLEDGMENT
The authors would like to thank the Conference INFOS 2010 (Cairo University) reviewers for their
constructive comments and suggestions for learning how to write scientific research papers.REFERENCES
[1] Dolev,S.,Gilbert,S.Lynch,N.A.,Shvartsman,A.A.,Welch,J.L:"Geoquorums:Implem-enting Atomic Memory in Mobile Ad Hoc Networks " . In: Proceeding of The 17th International Conference on Distributed Computing, PP: 306-320(2003).
[2] Haas, Z.J., Liang, B.A., "Ad Hoc Mobile Management with Uniform Quorum Systems", IEEE/ACM Transactions on Networking 7(2), PP: 228-240(2002).
[3] Kote, Y.B., Vaidya, N.,"A Protocol for Geocasting in Mobile Ad Hoc Networks, In: Proceedings of the IEEE International Conference on Network Protocols, PP: 240-249(2000).
[4] P.Kardasis, P.Loucopoulos, "Expressing and Organizing Business Rules", In: Information and Software Technology 46(2004), PP: 701-718.
[5] P.Kardasis, P.Loucopoulos, "Managing Business Rules During The Requirements Engineering Process in Rule-Intensive IT Projects", Proceedings of 6th International Conference on Business Information Systems, Colorado Springs, Colorado, USA, June, PP: 239-247, (2003).
[6] Y.Amghar, M.Meziane, A.Flory, "Using Business Rules Within a Design Process of Active Database", Vol.11, No.3, Idea Group Publishing, 2000, PP: 3-15.
[7] M.Snoeck, G.Poels, "Analogical Reuse Of Structural And Behavioral Aspects of Event-Based Object-Oriented Domain Models", International Workshop on Enterprise and Domain Engineering-DOME 2000(Within The DEXXA 2000 Conference ),IEEE,Greenwich,UK,2000.
[8] I.Traore, D.Aredo, H.Ye.A.S, "An Integrated Framework for Formal Development of Open Distributed System," In: Introduction and Software Technology 46 (2004), PP: 281-286
[9] D.Rosca, S. Greenspan, C.Wild, H.Rebenstein, K.Maly, M.Feblowitz, Application of a Decision Support Mechanism to the Business Rules Life cycle, 10th Knowledge- Based Software Engineering Conference (KBSE 95), Boston, MA, 1999.
[10] C. Chiang, J.E. Urban," Validating Software Specifications against User Claims," Proceedings of the Twenty- Third Annual International Computer Software and Applications Conference (COMPSAC 2000), 2000,PP: 104-109.
[11] R. Mattolini, P. Nesi, "Interval Logic for Real-Time System Specification," IEEE Transactions on Software Engineering 27(3) (March 2001), PP: 208-227.
[12] M.Sveda, R.Vrba, "Executable Specifications for Embedded Distributed Systems," Computer Science 34(1) (2001), PP: 138-140. [13] B.C. Moszkowski, "A Complete Axiomaization of Interval Temporal Logic with Infinite Time", Proceedings of the 15th Annual IEEE
