1 / 55

EAS302 - EAServer Internals

EAS302 - EAServer Internals. Scott McReynolds OEM Engineering Manager e-Business scottmc@sybase.com. Agenda. Object References Naming and Security Interoperability Architecture Dispatcher (Server Kernel) Marshalling, Stubs and Skeletons Component Model Plug-in Architecture

tynice
Download Presentation

EAS302 - EAServer Internals

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EAS302 - EAServer Internals • Scott McReynolds • OEM Engineering Manager • e-Business • scottmc@sybase.com

  2. Agenda • Object References • Naming and Security • Interoperability Architecture • Dispatcher (Server Kernel) • Marshalling, Stubs and Skeletons • Component Model Plug-in Architecture • Customizable Instance Life-Cycle

  3. What is an Object Reference? • Also known as a CORBA IOR. It contains zero or more profiles (> 1 for load balancing and high availability). • A typical profile contains: • Protocol, e.g. IIOP. • Endpoint, e.g. myhost:9000. • Protocol + Endpoint = location of server. • ObjectKey, unique for the specified endpoint. Example Profile Protocol: IIOP/SSL (iiops) Endpoint: myhost:9001 ObjectKey: ………...

  4. What is an Object Key? • The part of an Object reference that tells a server which of its objects is being referenced. • An opaque binary value whose contents are (usually) only understood by the server that created the owning object reference. • The value that is sent in the GIOP Request Header when a client invokes a method on an object reference. binary data

  5. Naming and Security • CORBA 2.2 Interoperability • Uses SessionManager::Session::lookup – Sybase proprietary naming interface that allows clients that do not support any of the standard CORBA security mechanisms for authentication. • RMI/IIOP Interoperability • Uses CosNaming::NamingContext::resolve together with CSIv2 standard mechanisms for security interoperability.

  6. Manager Object • A well-known object in each EAServer process. • Used implicitly by the PB connection object and the EJB InitialContext. • Allows simple URL based naming for clients’ initial object references, e.g. “iiop://myhost:9000”. interface Manager { Session createSession(in string user, in string password); void ping(); };

  7. Manager ObjectKey • Since Manager objects are used for bootstrapping, a Manager ObjectKey can be created by a client given a server’s URL, e.g. String url = “iiop://myhost:9000”; Manager manager = ManagerHelper.narrow(orb.string_to_object(url)); NUL byte ‘M’

  8. Manager View Client Server createSession Manager ObjectRef check Manager Object Operating System (user, password) (optional) Session ObjectRef checkSession (optional) Client AuthService ObjectRef AuthService Object Manager ObjectRef This is separate from, and additional to, any SSL authentication using server and client certificates. May return NO_PERMISSION system exception Session ObjectRef

  9. Session Object • Returned bymanager.createSession(“user”, “password”) • Used implicitly by the PB connection object and the PowerJ/JNDI InitialContext. • Allows only authenticated clients to create object references. interface Session { Object create(in string factoryName); Object lookup(in string name); };

  10. Session ObjectKey • Can only be created or decoded by the server. • Contains the client’s username & password(or CSIv2 flag). Is encrypted using a random key from $JAGUAR/Repository/Security/jaguar.key (the contents of which are assumed to be site-specific). • Has a 32 bit checksum using random data from jaguar.key to prevent clients creating ‘fake’ sessions. checksum user password ‘S’ encrypted

  11. Session View Client Server create Session ObjectRef Session Object (factoryName) Note: all of a Session Object’s state is reconstructed from the ObjectKey in the client’s Session ObjectRef, each time ‘create’ or ‘lookup’ is called. Session Objects consume no server resources between calls from the client. ObjectRef May return OBJECT_NOT_EXIST system exception Client lookup Session ObjectRef Session Object (name) Factory/Home ObjectRef May return OBJECT_NOT_EXIST system exception

  12. Factory/Home Object • Returned bysession.lookup(“MyPackage/MyComp”) • Used implicitly by the PB connection.createInstance call. • Allows only authenticated clients to create object references. interface Factory { Object create(); }; interface CustomerHome { Customer create(); };

  13. Factory/Home ObjectKey • Can only be created or decoded by the server. • Contains the client’s username & password(or CSIv2 flag). • Contains the component name. • Uses same encryption and checksum mechanisms as Session ObjectKey. checksum user password component ‘H’ encrypted

  14. Factory/Home View Client Server create Factory/Home ObjectRef Factory/Home Object Note: all of a Factory/Home Object’s state is reconstructed from the ObjectKey in the client’s Factory/Home ObjectRef, each time a ‘create’ or ‘finder’ method is called. Factory/Home Objects consume no server resources between calls from the client. ObjectRef Client find... Factory/Home ObjectRef Factory/Home Object ObjectRef

  15. Component ObjectKey • Can only be created or decoded by the server. • Contains the client’s username & password(or CSIv2 flag). • Contains the component name. • Contains a unique ID (+ Primary Key for entity). • Uses same encryption and checksum mechanisms as Session ObjectKey. checksum user password component unique ID ‘E’ encrypted

  16. Name Service • Manages bindings of names to Factory/Home objects. • All binding information is transient (in-memory) for maximum performance. • When a server starts, it consults its local repository for a list of installed components and binds each with the name server(s). • Lookup/resolve calls return ALL available locations (profiles) for the requested name, sorted according to the selected load balancing strategy. • Load balancing and failover is based on client run-time choosing from the available profiles.

  17. Interoperability Architecture • Dual architecture: • CORBA 2.2 Interoperability • RMI/IIOP Interoperability (for EJB 2.0) • You can have your cake and eat it too 

  18. CORBA 2.2 Interoperability • Attempts to map all parameter types to: • Primitive IDL types, or • Object References (IDL interface types), or • Structures (IDL struct types), or • Sequences (IDL sequence types) • In principal, this allows any CORBA 2.0 – 2.2 compatible client (supporting IIOP 1.0 or 1.1) to easily communicate with components in EAServer.

  19. RMI/IIOP Interoperability • Uses the same IDL as for CORBA 2.2 Interoperability. • ‘Clever’ stub and skeleton generation allows for the generated code to obey the Java to IDL (RMI/IIOP) mapping specification even though our IDL does not use valuetypes. • In other words, our wire-level interoperability is compliant with RMI/IIOP requirements, but our IDL is not generated in the ‘standard’ way, instead it is generated to facilitate access by non-Java clients.

  20. What are valuetypes? • Valuetypes are the CORBA 2.3 IDL equivalent of classes that support inheritance - like ‘structs’ with inheritance and operations (methods).

  21. What is the big deal with valuetypes? • Marshalling is complex. • Using CORBA 2.3 IDL for non-Java clients requires the customer to re-write the valuetype operations in the target client language, e.g. porting the java.util classes and marshalling code to C++, COM or PB. • Their use precludes interoperability with pre-CORBA 2.3 ORBs. This limits the types of clients that can be used.

  22. Detection of Client Type • Allows a component to be deployed without regard for whether the client will want to use CORBA 2.2 or RMI/IIOP Interoperability. • Detects client’s interoperability requirements at run time. • Allows usage of a component by both types of client, simultaneously! As far as we are aware, this feature is unique to EAServer.

  23. Tricky Cases • There are several cases where the correct: • Java RMI (EJB standard) semantics cannot be obtained using CORBA 2.2 Interoperability. • Null value propagation. • Inheritance with parameters. • Inheritance with exceptions.

  24. Null Value Propagation • Actual parameter value passed at run-time is null, e.g. • Declared: void myMethod(String name); • Run-time: String name = null; comp.myMethod(name); • Component: if (name == null) • . . . • Solution – use RMI/IIOP interoperability.

  25. Inheritance with Parameters • Actual parameter type passed at run-time inherits from declared parameter type, e.g. • Declared: void myMethod(java.util.Date date); • Run-time: java.sql.Date myDate = . . . ; comp.myMethod(myDate); • Component: if (date instanceof java.sql.Date) . . . • Solution – use RMI/IIOP interoperability.

  26. Inheritance with Exceptions • Actual exception type thrown at run-time inherits from declared exception type, e.g. • Declared: void myMethod() throws java.sql.SQLException; • Run-time: throw new java.sql.DataTruncation(); • Client: if (ex instanceof DataTruncation) . . . • Solution – use RMI/IIOP interoperability.

  27. IDL Entity Types • In the context of EJB interoperability, IDL entity typesare Java classes that were generated from CORBA IDL definitions (e.g. enum, struct and union definitions). • Examples: TabularResults.ResultSet, XDT.RowSet. • Carefully defined IDL entity types can be marshalled much more efficiently than typical serializable Java classes. • These must be supported as parameter types by all products that implement EJB 2.0 interoperability, i.e. using RMI/IIOP does not mean sacrificing efficiency.

  28. Dispatcher (Server Kernel) • The dispatcher manages: • Client connections. • Component instances. • Method invocation. • Threads. • Transactions. • Security.

  29. Object Reference / Component Instance • An object reference is a client handle for an abstract object. • A component instance is the implementation for an abstract object. • A stateless component can use different component instances to service multiple client requests for the same object reference. • A stateful component is tied to a particular component instance until the transaction ends (or the instance times out).

  30. Container • An EAServer container is an internal object that represents the association between an object reference and an active component instance. • A container is required only for an invocation in progress, or a transaction in progress, or for a component that retains conversational state. (Helps with scalability). • Containers manage interactions between object references, component instances and the server’s security and transaction sub-systems.

  31. Instance Pooling • Component instances can be costly to create (for COM, PB, and for other components where the constructor does expensive initialization). • Programmatic pooling is available for objects implementing the COM IObjectControl or EJB 0.4 ServerBean interface. • Declarative pooling is available via “Pooling” check-box in Component Properties. • Pooling is recommended where possible.

  32. End-to-End Object View Client Server Container Hash Table Component Hash Table ObjectRef Container Object Stateful Component Instance Pool ObjectRef ObjectRef Container Object Pooled Object Client Container Object Stateless Component Instance Pool ObjectRef Container Shared Object Shared Component Pooled Object ObjectRef ObjectRef Container Pooled Object

  33. True False True Active thread Sharing Blocked thread False Activated component instance Component Types and Threading Issues Concurrency

  34. Component Types and Threading Issues • NOT supported in PowerBuilder VM • Setting .bind.thread to TRUE overrides this combination, effectively turning off Concurrency and forcing serialization of requests to the shared component Concurrency = TRUE and Sharing = TRUE

  35. Concurrency Option • Disable this option where component code is not thread-safe (MT-safe), i.e. when it is not safe for multiple clients to call methods in parallel (even on separate instances). • Disable this option for shared components if the component writer did not make use of synchronization primitives, e.g. COM / PowerBuilder shared components. • EAServer uses a mutex (semaphore) to serialize access to components that do not permit concurrency.

  36. Component Types and Threading Issues • What’s up with this new BindObject property? • Allows multiple client threads to execute in one instance (like a shared component) but also supports creation of multiple instances • Due to PowerBuilder thread-safety issuesnot a viable property for a componentimplemented in PowerBuilder

  37. Thread Pooling • Service Thread - a thread that is associated with a running service component. • Listener Thread - a thread that accepts incoming connection requests. • Client Thread - a thread that is associated with an open client connection (e.g. IIOP client). • Bound Thread - a thread that is associated with a component instance. The Bind Thread option is required for components that attach data to the creating thread (e.g. COM, PB DataStore).

  38. End-to-End Thread View Client Server Listener Thread Thread Service Thread Container Object run, start, or stop invoke method ObjectRef Client Thread Client Container Object Method Thread Pool Thread Client Thread Bound Thread Pooled Thread invoke method ObjectRef Container Object Method Pooled Thread

  39. Marshalling • Marshalling is the process of converting method calls – in particular input and output parameter data - into raw binary data that can be passed over a network. • Except for EJB 2.0 ‘local’ interface calls, all component calls in EAServer involve parameter marshalling. • Marshalling is distinct from actual network I/O (e.g. TCP/IP socket read/write calls). • For inter-component calls within a server, network I/O is avoided.

  40. Lightweight EJB Container • Improves Performance for EJB -> EJB Communications. • Default for Server. com.sybase.jaguar.server.lwc • Component level Property. com.sybase.jaguar.component.lwc • EAServer activates the lightweight container for EJB-to-EJB calls as long as all of the following are true: • The LWC is enabled for the server and the called (target) component. • The calling (source) component uses an EJB reference or EJB local reference to make the call. • The LWC is compatible with the transaction and security properties of the calling (source) and called (target) components. • The LWC cannot be forced to activate. • Significant performance improvement with "Required" or "Requires New". • Object references cannot be marshalled.

  41. EJB CMP Cache • Drivers to improve overall performance of CMP EJBs • Allowing updates to be deferred to the end of each transaction and sent together as a command batch.. • Reducing network round trips between the database server and EAServer. • Supports automatic creation of semi-temporary stored procedures. • Sybase Driver : com.sybase.ejb.cmp.SybaseDriver • Oracle Driver: com.sybase.ejb.cmp.OracleDriver • Lots of new Parms.. Check the documentation

  42. Stubs • A stub is a generated class that implements a CORBA IDL interface by delegation to a remote object. • Stubs appear to the client as ‘local’ objects. • Stubs contain object references. • Method calls on stubs are dispatched to the server identified in the object key - using parameter/request marshalling (and network I/O if the object is on a remote server).

  43. Stub Architecture – C++ / COM / PB / … virtual CORBA_Double sqrt (CORBA_Double x) { CORBA_ULong _status; JagStream* _stream = new_JagStream(&_status, _jagObjectRef, 0, "sqrt"); CORBA_check(_status); JagStream_putDouble(_stream, (JagDouble*)&x); JagStream_getReply(_stream); // network I/O CORBA_Double _result; JagStream_getDouble(_stream, (JagDouble*)&_result); if (_stream->fail == JAG_CORBA_USER_EXCEPTION) { CORBA_Char* _type = ""; _stream->fail = 0; JagStream_getString(_stream, &_type, 0); JagORB_log("Math::DoubleMath::sqrt -- unknown user exception '%.100s'", _type); _stream->fail = JAG_CORBA_UNKNOWN; } CORBA_close(_stream); return _result; } JagStream run-time library libjcc.dll/.so

  44. Stub Architecture - Java public double sqrt (double x) { com.sybase.CORBA._Request _request = __request("sqrt"); try { org.omg.CORBA.portable.OutputStream _output = _request.getOutputStream(); _output.write_double(x); _request.invoke(); // network I/O org.omg.CORBA.portable.InputStream _input = _request.getInputStream(); double _result; _result = _input.read_double(); return _result; } catch (com.sybase.CORBA.UserException _ue) { throw new org.omg.CORBA.UNKNOWN(_ue.type); } finally { _request.close(); } } _Request InputStream OutputStream classes com.sybase.CORBA.*

  45. Code Set Conversion • For IIOP 1.0, all data is passed over the network in ISO 8859-1 transmission code set. • For IIOP 1.1 / 1.2, all data is passed over the network in UTF-8 or UTF-16 form. • Stubs and skeletons take care of converting between transmission code set and the code set required by the clients and components. • Flexible design ensures that multiple code sets can be used (at same time) by client & server.

  46. Skeletons • A skeleton is a generated class or library that provides a bridge between the dispatcher and an implementation class. • Skeletons are required for Java and C++. Generic code is used for some component models (COM, PowerBuilder). • Skeletons tend to support more efficient marshalling than generic code.

  47. Component Model Plug-in Architecture • Each component model (apart from C++) is implemented by an external library with three entry-points. • Load Component (new_JagComponent). • Create Instance (create). • Invoke Method (invoke).

  48. Load Component Server Load Component delegates to external library (.dll / .so) new_JagComponent (JagChars* name, JagHashtable* props) (For example - libpbjag70x.so with server property com.sybase.jaguar.server.pb70.library=libpbjag70x.so) Load Component returns JagComponent - a “C” class struct JagComponent { JagComponentCreateFunc create; ... }

  49. Create Instance struct JagComponent { JagComponentCreateFunc create; ... } JagObject* create (JagComponent* component); Create Instance returns JagObject - a “C” class struct JagObject { JagObjectInvokeFunc invoke; ... }

  50. Invoke Method struct JagObject { JagObjectInvokeFunc invoke; ... } void invoke (JagObject* object, JagStream* stream, JagChars* method, int control) Invoke Method uses JagStream for parameter & exception marshalling invoke method on component instance (COM / Java / PowerBuilder object)

More Related