Object-oriented Metacomputing with Exertions

1. Object-oriented Metacomputing with Exertions Michael Sobolewski AFRL/WPAFB, PJIIT, TTU 17 February, 2010 sobol@cs.ttu.edu http://sobol.cs.ttu.edu Mike Sobolewski

2. Agenda • From the Internet to Metacomputing • Conventional Platforms • Programming Languages vs. SW Languages • Metacomputing Platforms • SORCER Platforms • Exertion-oriented Programming Concepts Mike Sobolewski

3. From the Internet …. applications computing power data files storage What is the platform for the Internet? Mike Sobolewski

4. …. to SO Computing What is the platform for virtual services? Mike Sobolewski

5. Computing • Computing is defined as the activity of using and developing computer technology, computer hardware, and software. • A computer is a machine that manipulates data according to control strategy that applies instructions defined in computer programs. • A computer requires an operating system (OS) to execute programs in terms of instruction set of its processor. • A computing process requires a platform (runtime): processor, OS, programs Mike Sobolewski

6. The Warship Vasa Vasa Museum, Stockholm, Sweden http://www.tar.hu/softarchpract/part01.html Does not Compute

7. We need to confront Deutsch’s Eight Fallacies of the Network • 1. The network is reliable • Latency is zero • Bandwidth is infinite • The network is secure • Topology doesn't change • 6. There is one administrator • 7. Transport cost is zero • 8. The network is homogeneous

8. Programs P3 MachineCode Batch Processor P2 P2 Programs P3 P1 Processor P1 Processor P2 OS Beffore1950s 1960s 1970s P1 Processor PlatformProcessor, OS , Programs Mike Sobolewski

9. What is a metacomputer? „The metacomputer is, simply put, a collection of computers held together by state-of-the-art technology and "balanced" so that, to the individual user, it looks and acts like a single computer. The constituent parts of the resulting "metacomputer" could be housed locally, or distributed between buildings, even continents.” 1987 by NCSA Director, Larry Smarr What is a metaOS for metacomputer? What is an instruction set of metaprocessor? Paweł Rubach

10. …. to Metacomputing Define the platform and relevant abstractions for SO computing Mike Sobolewski

11. Client-Server • Predefined: • Location • Protocol • Implementation Server Client Mike Sobolewski

12. SOA: SPOA vs. SOOA Service Registry Service Registry Discovery Find Discovery Publish Bind Execute Service Provider Service Requestor • How to find registry? (statically, dynamically) • Who does owe a proxy? (requestor, provider) • What is registered? (proxy description, proxy object) • How a provider is activated? (statically, dynamically) • How a provider is provisioned? (autonomically: statically, on-demand) • How to invoke service? (read/write, request/response) • Is a communication protocol fixed or neutral? Mike Sobolewski

13. Shrinking ProgramsBehavioral Transfer • OLE - One Large Executable • Shared Libraries • Share classes • Mobile Code Program units becoming smaller and mobile

14. MobileProxyObject SOOA - Network Centricity Requestor Originated from Network Network Neutrality: Location Protocol Implementation Discovery & Register Discovery & Lookup Service Registry Service Browser Service Service Provider ProxyObject Requestor Exported Classes Code Server Mike Sobolewski

15. Intergrid Programming Grid vs. Metacomputing Platforms Intergrid Applications Metacompute GridApplications cP3 mcP3 Metacompute OS Compute GridApplications mcP2 Service Providers mcP1-3 mcP1-2 Cybernodes cP2 Resource Scheduler cP1 Network Resources/Processors mcP1-1 Mike Sobolewski

16. Quantum Jumps in Programming Complexity Sequential Programming + order runtime: batch processing, OS Multi-threaded programming - order + parallelism runtime: + concurrency support Multi-process Programming - context + SW isolation (safety)runtime: + interprocess communication (pipes, sockets) Multi-machine-process Programming (DICE, CAMnet, Agile Castings) - global state, security, trust + HW isolation, scalability runtime: + secure interprocess communication (RPC), trusted mobile code (proxying), virtual file system, disconnected operations,leases, transactions, distributed events, deployment control Grid Programming (FIPER) - resource setup + resource collocation, untrusted resource sharing runtime: + aggregation of individual CPUs for execution of conventional programs Metaprogramming (SORCER) - code (deployment) setup, untrusted mobile code + spontaneity for virtual collaborations, code collocation (mobility), autonomic provisioning runtime: + FMI, federated file storage, autonomic resource management, EOP Mike Sobolewski

17. RPC Generations • First generation RPCs: Sun RPC (ONC RPC) , DCE RPC • language, architecture, OS independent • IDL • Second generation RPCs: CORBA, Microsoft DCOM-ORPC • adds object support • Third generation: Java RMI • it is conceptually similar to the second generation but supports the semantics of object invocation in different address space • is built for Java only • fits cleanly into the language (interfaces, serialization) • no need for standardized data representation • with behavioral transfer • Fourth generation RPCs: Jini Extensible Remote Invocation (Jini ERI) • dynamic proxies • dynamic configurations (dependency injection • security • Fifth generation RPCs: Web Services RPC and the XML bandwagon • SOAP • WSDL • Sixth generation RPCs: SORCER Federated Method Invocation (FMI) • concurrent invocation on multiple federating hosts (virtual metacomputer)

18. Programming Languages vs. SW Languages The interpreter for a computer language is just another program. Mike Sobolewski

19. SORCER Platform Metacompute Applications (Exertions) P3 Metacompute OS (System Services) P2 Tasker, Jobber, Spacer, Grider, Caller, Methoder,FileStorer, MetadataStorer, ByteStorer, Replicator, Sweeper, Tracker, Spliter, Persister,Autenticator, Authorizer, Policer,WsRpcRelayer, WsDocRelayer, JxtaRelayer, Surrogator, Cataloger Service Providers P1-6 Service Beans P1-5 (DomainServices,FMI) Cybernodes P1-4 SOAPHTTPIIOPTCP/IPUDP/IPRPC/XDR Jini Network Objects (Interfaces) P1-3 Computer Networks (Protocols) P1-2 Platforms (Processor Instructions) P1-1

20. Programming Models ServiceUI, Exertions SorcerServiceBean GISOSGrid Domain SOO Programming PM6 System SOO Programming PM5 FMI, ServiceProviderServiceProviderBeanSorcerServiceBeanServiceUIWS, JXTA, CORBA ProvidersJini Programming Model SOB Programming (Rio) PM4 SOO Provisioning (Rio) PM3 GlobusAxisJXTACORBASockets SOO Programming (RMI, Jini/JERI) PM2 Socket, SPO Programming PM1 Structured, OO Programming PM0 The interpreter itself is just a program.

21. SORCER Fundamental concepts • In SORCER the data context is used as a local namespace of objects representing data with control context that defines control strategy. Data flow is defined by context pipes. Control strategy is applied to a collection of service signatures. • An exertion is an OO shell that provides the network interpreter and API in Java for SORCER. • The user exerts a collaboration of services by creating an exertion instance and invoking its exert operation. Mike Sobolewski

22. EO Programming Terminology • Service provider: a remote object accepting exertions from service requestors (implements Servicer) • The service grid: a collection of service providers. • A service provider runs a set of service operations. The operations are exposed indirectly to service requestors via interfaces (services) • Service signature: a specification of a service operation defined by (i, o), where i is a name of provider interface, o is a name of operation (selector) • Service data: argument to a service operation, called a data context, for short dc • Control context – defines control strategy, for short cc

23. Exertions • Exertiona triplet of data context dc, a collection of service signatures {s}, and control strategy cci.e., (dc, {s}, cc), where s = (i, o) • Elementary exertion is called a task– one shared context • Composite exertion is called a job– aggregation of tasks and other jobs • Exertions define collaborations – service-oriented programs

24. Service Context – network centric relationshipperson = firstname | initial | lastname SORCER name laboratory Mike | W | Sobolewski university director person TTU department email name room sobol@cs.ttu.edu CS number phone 20B number ext 237 806-742-1194 Mike Sobolewski

25. Job Task Context Signature Dynamic CollaborationsExertion Exertion j0 = new ServiceJob("j0"); Exertion j0_0 = new ServiceJob("j0_0"); j0.addExertion(j0_0); j0.addExertion(new ServiceTask("t0_1")); j0.addExertion(new ServiceTask("t0_2")); j0_0.addExertion(new ServiceTask("t1_0")); j0_0.addExertion(new ServiceTask("t1_1")); Meta program Signature type: preprocess process postprocess append

26. Job Task Context Signature Exerting Dynamic CollaborationsExertion#exert(Transaction) Exertion – specification of service collaboration (metaprocessor and processing)Basic vs. Composite Exertions (encapsulation of data, ops, control strategy) Meta computer Late Binding (MetaOS) Federation Member Meta program Signature type: preprocess process postprocess append

27. Job Task Context Signature Exerting Dynamic CollaborationsExertion.exert() Meta computer Meta program Signature type: preprocess process postprocess append

28. Cloud Resource Management Define the optimal dynamic federation in the existing cloud Define the optimal dynamic federation in the autonomically managed cloud – increased cloud by provisioned providers Remove unused providers – cloud reduction Update the optimal dynamic federation for failure recovery – migration of providers to new compute resources Mike Sobolewski

29. UNIX vs. SORCER Unix pipes – processes; SORCER pipes – data Pipeline vs. SORCER workflow – exertion + control context Local shell vs. network shell Mike Sobolewski

30. VEFEx AbstractionsVariable-Evaluator-Filter-Exertions Filters Exertions Evaluators Variables ServiceContext Signatures Metacomputer Models ControlContext EO Programming SORCERmeta-OS Providers Metaprocessor (Services) Service Context Computers Service Types ProgrammingEnv Implementation OS Processor Mike Sobolewski

31. SORCER Research Domain • Service-Oriented Programming • Service-Oriented Computing Environment • Service-Oriented Programming Development Tools • Service-Federated Assurance and Security • Self-Aware Service Federations • Autonomic Service Federations • Service Federated Intergrids • Metacomputing Transdisciplinary Analysis and Optimization (MTAO) • SORCER Theses and SORCER Publications Mike Sobolewski

32. Conclusions • A provider interface (service type) is defined first. • The interface specifies the operations and semantics of a service. • The interface is not required to be a remote interface, so requestor/provider communications need not be RMI based. Multiple ways of proxying possible in SORCER. • In SORCER a requestor can use an exertion or itself can be an exertion - a metaprogram and metashell. • Exertions can be created using SORCER API or interactively in the netcentric context. The underlying FMI communication mechanism is hidden from the requestor. • SORCER is the metaprogramming platform with protocol, implementation, and location neutrality. Mike Sobolewski

33. References • M. Sobolewski, “Object-Oriented Metacomputing with Exertions,” Handbook On Business Information Systems, A. Gunasekaran, M. Sandhu, 2010. • M. Sobolewski, "Metacomputing with Federated Method Invocation", Advances in Computer Science and IT, edited by M. Akbar Hussain, In-Tech, intechweb.org, ISBN 978-953-7619-51-0, s. 337-363, 2009 • P. Rubach i M. Sobolewski, “Autonomic SLA Management in Federated Computing Environments,” Parallel Processing, 2009. ICPP ’09 Workshops, International Conference on, IEEE Computer Society, 2009. • Sobolewski, M, 2008, SORCER: Computing and Metacomputing Intergrid, 10th International Conference on Enterprise Information Systems, Barcelona, Spain (2008). Available at: http://sorcer.cs.ttu.edu/publications/papers/2008/C3_344_Sobolewski.pdf. • Sobolewski, M., 2008, Exertion Oriented Programming, IADIS, vol. 3 no. 1, pp. 86-109, ISBN: ISSN: 1646-3692. • Berger M., Sobolewski, M. 2007, A Dual-time Vector Clock Based Synchronization Mechanism for Key-value Data in the SILENUS File System, IEEE Third International Workshop on Scheduling and Resource Management for Parallel and Distributed Systems (SRMPDS '07), Hsinchu, Taiwan, Vol.2, ISSN 1521-9097. • Sobolewski M., 2007, Federated Method Invocation with Exertions, IEEE International Conference on Principles of Information Technology and Applications (PITA'07), Wisla, Poland, October 15-17, 2007, ISSN 1896-7094, pp. 765-778. • Berger, M., Sobolewski, M. 2007, Lessons Learned from the SILENUS Federated File System, Complex Systems Concurrent Engineering, Loureiro, G. and L.Curran, R. (Eds.) 2007, Springer Verlag, ISBN: 978-1-84628-975-0, pp. 431-440. • Turner A., Sobolewski M. 2007, FICUS - A Federated Service-Oriented File Transfer Framework, Complex Systems Concurrent Engineering, Loureiro, G. and Curran, Richard (Eds.) 2007, Springer Verlag, ISBN: 978-1-84628-975-0, pp. 421-430. • Sobolewski, M. 2002. Federated P2P Services in CE Environments, Advances in Concurrent Engineering, A.A. Balkema Publishers, 2002, ISBN 90 5809 502 9, pp. 13-22. Mike Sobolewski

34. Mike Sobolewski