Fragment: A BPEL Work Process Execution Motor for Cell phones.

Uploaded on:
Category: Sales / Marketing
Bit: A BPEL Workflow Process Execution Engine for Mobile Devices ... 267 million Java-prepared cellular telephones sent in 2004; evaluated 1.5 billion by end of 2007 ...
Slide 1

Bit: A BPEL Workflow Process Execution Engine for Mobile Devices Gregory Hackmann, Mart Haitjema, Christopher Gill, and Gruia-Catalin Roman Mobile Computing Laboratory and Center for Distributed Object Computing Department of Computer Science and Engineering

Slide 2

Outline Introduction and Motivation Sliver Middleware Architecture In-Depth Design Decisions Evaluation Conclusion and Future Work

Slide 3

Background PDA and cell telephones have turned into a gigantic registering stage 267 million Java-prepared cellular telephones conveyed in 2004; assessed 1.5 billion by end of 2007 Each individual gadget has constrained computational and correspondence power, however total force is enormous Physical portability of gadgets makes numerous difficulties Interactions happen with next to zero pre-arranging Devices highlight exceptionally lightweight equipment and programming Network connections are always made and disjoined

Slide 4

Web Standards can mitigate requirement for pre-arranging If gadgets concur on a typical information trade and handling standard, then can interface without standard transaction Web gauges as of now generally acknowledged in wired settings SOAP: XML-based information trade and administration conjuring BPEL: forms SOAP administrations into work process forms Many Web administration middleware and instruments exist for organization in wired settings

Slide 5

Problem Statement Unfortunately, existing middleware frameworks are excessively heavyweight and make an excessive number of suspicions about the system Example: ActiveBPEL execution motor Requires Apache Tomcat and Java SE 1.4.2 Combined impression of 92 MB of storage room and 22 MB of RAM Host must have openly routable IP address

Slide 6

Sliver Middleware Three crucial qualities for versatile middleware Small stockpiling and memory impression Depends just on APIs accessible on all gadgets Support for a wide assortment of correspondence media and conventions Sliver is a SOAP and BPEL middleware for cell phones which fits these characteristics

Slide 7

Sliver Architecture administration. demand(); new Request(); new Process(); <request> <process>

Slide 8

BPEL Parser kXML tokenizes the BPEL archive Token show label name, characteristics, and whether tag is beginning or completion Sliver changes over tokens into Java protests Each tag has a relating object (e.g., <process> => Process ) START_TAG process quality "name"="Echo" START_TAG succession START_TAG get trait "variable"="var" END_TAG get START_TAG answer property "variable"="var" END_TAG answer END_TAG grouping END_TAG process START_TAG process characteristic "name"="Echo" START_TAG arrangement START_TAG get characteristic "variable"="var" END_TAG get START_TAG answer characteristic "variable"="var" END_TAG answer END_TAG grouping END_TAG process Process.Process(parser) parser.require(START_TAG, "process") name <= parser.attribute("name") if name = NULL toss "<process> requires name trait" sort <= parser.nextTag() if sort = "get" kid <= new Receive(parser) ... parser.require(END_TAG, "process") end <process name="Echo"> <sequence> <receive variable="var"/> <reply variable="var"/> </sequence> </process>

Slide 9

BPEL Parser (cont.) Each class has a constructor which takes in the kXML parser and devours everything between the relating begin and end labels Child labels are parsed by recursively summoning different constructors Each constructor settles on neighborhood choices about the label\'s legitimacy (e.g., Process \'s constructor checks that the "name" quality is determined) START_TAG process characteristic "name"="Echo" START_TAG grouping START_TAG get trait "variable"="var" END_TAG get START_TAG answer property "variable"="var" END_TAG answer END_TAG arrangement END_TAG process Process.Process(parser) parser.require(START_TAG, "process") name <= parser.attribute("name") if name = NULL toss "<process> requires name trait" sort <= parser.nextTag() if sort = "get" tyke <= new Receive(parser) ... parser.require(END_TAG, "process") end

Slide 10

BPEL Parser (cont.) Normally, XML reports are approved by looking at them against a XML Schema Description (XSD) e.g., BPEL standard has a comparing bpel.xsd General-reason XSD validators are restrictively extensive (many KB or MB) kXML just does basic acceptance: e.g., watches that all labels are shut Hand-composed, neighborhood approvals => effective worldwide procedure acceptance No requirement for a heavyweight, universally useful XSD validator

Slide 11

BPEL Process Execution All labels\' classes get from a base Activity class Activity.execute() watches that all preconditions are fulfilled (e.g., all inputs are accessible), then calls executeImpl() Each determined class supersedes executeImpl() (e.g., Sequence.executeImpl() conjures all youngsters\' execute() one by one)

Slide 12

BPEL Process Execution (cont.) Instance-particular information (e.g., estimations of variables) are followed by an InstanceData object Passed along recursively to execute() Entire procedure can be executed by making a void InstanceData and summoning execute() on procedure\'s "root" action Highly secluded: every label\'s execution code is independent

Slide 13

Evaluation Support for everything except one BPEL movement, and fundamental XPath inquiries Total code base of 114 KB Supports Java MIDP 2.0, Foundation Profile 1.0, Personal Profile 1.0, and Standard Edition 1.3 20 regularly repeating "work process designs" [1] BPEL underpins 17 of the 20 designs [2] Sliver at present backings 15 of these 17 designs 1. van der Aalst, et. al.: Workflow designs. Circulated and Parallel Databases 14 (1) (2003) 5 - 51 2. Wohed, P., et. al.: Pattern based investigation of BPEL4WS. Specialized Report FIT-TR-2002-04, Queensland University of Technology (2002)

Slide 14

Evaluation (cont.) Implemented 12 of the 15 designs in BPEL 3 examples are unfeasible benchmarks All procedure conjure an inconsequential Web administration which includes two numbers Deployed Sliver three stages: PC: 3.2 GHz Pentium 4 CPU, 512 MB of RAM, Linux 2.6.16, Sun Java 1.5.0_07 Dell Axim X30 PDA: 624 MHz XScale CPU, 64 MB of RAM, Windows Mobile 2003, IBM WebSphere Micro Environment 5.7 Nokia 6682 cellular telephone: 220 MHz ARM9 CPU, 20 MB of RAM, Symbian OS 8.0a, packaged MIDP 2.0 runtime

Slide 15

Mean Execution Time

Slide 16

Conclusion Sliver\'s engineering is composed in light of the attributes of versatile middleware Sliver bolsters BPEL and SOAP on cellular telephones, PDAs, and other asset constrained stages Although Sliver\'s BPEL server is fragmented, it can as of now execute numerous valuable work processes with sensible execution Future work: Enhance Sliver\'s BPEL consistence Consider modules for other work process dialects (e.g., CiAN)

Slide 17

Thank You! Fragment venture page:

Slide 18

Sample Code open class BPELServerExample { open static void main(String [] args) tosses Exception { String namespace = ""; transport = new SocketTransport(9001); BPELServer server = new BPELServer(transport); server.addProcess(namespace, new FileInputStream("ExampleWorkflow.bpel")); server.bindIncomingLink("ClientLink", namespace, "executeWorkflow"); Binding remoteHost = new SocketBinding("", 9000); server.bindOutgoingLink("ExternalSOAPServiceLink", remoteHost); server.start(); }

Slide 19

Peak Memory Usage

View more...