Contact Us Home
    Menu
Products

      Adapters

      BeansPass

      BeansSignage

      Kernl
           What's New in Kernl 2.0
           Blue Kernl
           FAQ
           Business Justification Paper
           Testimonials

      Product Registration

      AllFusion® ERwin® Data Modeler



Useful Information on WAS
IBM WebSphere
    Kernl FAQ
One Platform - No Restrictions - No Worries

Application Servers

Q1. Which versions of application servers does Kernl currently support?
Kernl 1.5 supports WebSphere 4.0 and WebLogic 6.1. Both application servers use JDK 1.3 and Kernl is tested on J2EE 1.3.

Audit
Q2. Is Log4J incorporated in Log Manager?
This will be in Kernl 2.0.

Database

Q3. How does Kernl handle concurrent access to databases?
Concurrent access to databases is really handled by the application server through an EJB transaction data source. This is one of the big advantages of using application servers as writing middle-ware code to handle concurrent access is now unnecessary.

Q4. How does OR mapping deal with cases where data is not fully committed to the database? How would rollback take place on complex queries?
This is actually handled by the EJB transaction data source on the application server. Rollback for complex queries is supported by the EJB transaction data source.

Interfaces

Q5. How can Kernl currently support MQSeries?
You can use MQSeries API directly in the service bean, or you can use JMS API. The messaging manager allows interface to JMS directly.

Q6. Is Kernl flexible enough to handle biometrics support and interfaces?
Since the capturing of biometrics is more a front-end support, this is not an issue. The front end (e.g. applet, activeX) will capture the information from the users. It can transfer the result back to Kernl (server) in a defined format for storage and future interaction.

J2EE/Java

Q7. Are Kernl components EJBs?
Yes, Kernl components are EJBs. They are all built with 100% compliance to J2EE standards.

Maintenance

Q8. What is your service model for Kernl?
We provide email and phone support as a standard maintenance service for the Kernl product. For enterprise users, we usually discuss 24-hour support options.

Messaging

Q9. What is the value-add for Kernl's message handling component?
Kernl provides the capability to build SMS and email-based applications - these interfaces are all built-on. It also provides a JMS wrapper for development to make it easier to write message-oriented applications.

Kernl's message handling component removes the complexities that distract developers, thus allowing them to focus on business logic.

Q10. How does Kernl's messaging component help me link to third party products like Microsoft Message Queuing or IBM MQ?
This is achieved using JMS, which is part of J2EE and is a part of almost all application servers. Kernl provides a convenient wrapper around JMS such that developers do not have to worry about setting up JMS connections, sessions, binding to destinations etc., allowing them to get up to speed quickly and focus on business logic.

Performance

Q11. How does Kernl's framework affect performance? Will it slow down my components or applications?
There is no impact to adding the Kernl framework to an applications environment as Kernl has been stress-tested and optimized to take full advantage of J2EE specifications.

In general, frameworks create minimal overhead for applications running on an application server. The impact of a framework is generally considered inconsequential when compared to the advantages it offers such as standardized development processes, greater focus on business logic, reduced design effort and shorter project lengths.

Pricing

 Q12. What is the pricing model for Kernl?
Pricing is based on individual CPUs, as licensing is by the IP address bound to each CPU.

Q13. If I buy the production server for Kernl, do I have to buy the developer license as well? I typically will not do development on the production environment.
There are two options: developer license or run-time license.

The developer license is a pack of 5 Kernl (installs and runs on 5 separate machines). Each license will allow up to 5 concurrent sessions. The run-time license is a full-fledged license that can be installed on a per-CPU basis. You can use it for development or run-time.

If your developers can share one development server, it is recommended to purchase a run-time license for your development application server. This will allow you to do full load and regression testing.

Security
Q14. Application servers come with their own security. Why would I need to use Kernl's?
Secure systems usually have requirements related to the type of security that needs to be implemented, the nature of the data to be secured and the level of security needed. KernlÕs security is data related. This means that we can provide end-to-end security for an enterprise system using the latest algorithms.

Kernl's security architecture is compliant with industry standards and open software cryptography technologies, allowing the implementation of strong encryption in applications at the client, server and network levels.

In any secure system, the requirements for the protection of the data are called Security Services. Security Services tend to favor a "practical" approach to cryptography and security, containing methods which validate the authenticity of origin, integrity, confidentiality and non-repudiation (proof of integrity and origin of data than cannot be refuted) of data.

Kernl handles confidentiality of data via encryption and decryption techniques. By default, Kernl supports BlowFish cryptography. Our default security for username and password verification is also done by the Kernl security component.

Q15. How does Kernl support common access (mainframe, legacy systems)? Single sign-on?
One approach is to interface via MQSeries. The mainframe end will have a MQ receiver that does the actual interface to the mainframe (e.g. CICS). The Kernl end is quite easy since there is the messaging manager that can receive and send messages.

There are two ways to achieve single sign-on. One way is to redirect all existing machines and make them perform logon to a single machine. This means that these machines will have to perform code changes for their security aspect. Kernl can be the single machine for logon, but there must be interfaces to take requests from the other machines.

The other way is to create an administration application that does the synchronization of user profiles among the other machines. When there is a change in the user profile, this info will be replicated in the databases of the other machines that are in the single sign-on. This allows the machines to logon as it is without any code change.

Q16. How is the administration of username and password done?
 Kernl comes with a basic userid-password mechanism. The info can be updated into the user database directly.

Q17. How is Kernl security different from the EJB security?
Kernl's security manager does not rely on the EJB security provided on a particular application server. It implements its own public and private beans. This allows enterprises to be truly platform independent.

Q18. What is the security realm provided in Kernl? Is it like the one provided in application servers?
In Kernl, business logic is implemented as service beans and the central control lies with the service manager. A service has a type attribute with two values - "public" and "private". The service manager controls the access to all services.To access the private services, the user needs to logon to the system first. By default, the authentication service in Kernl uses the userid and password. Access control regulates what individual users can and cannot do within a system. Before the service manager activates the service bean to process a request, it will check with the authorization bean to see if the request is authorized. The implementation method of access control is different for each organization. This is why we leave it open, meaning that each organization can plug/code for the solution they choose. Thus, access control can be linked via a database, LDAP etc.

Session Management

Q19. What is the value-add for Kernl's session management feature?
Kernl's session manager takes the complexity of session management away from the developer so that the focus is on business logic instead of session management details on any application server. It ensures compatibility across multiple types of application servers.

For thick client applications and for support of external channels such as SMS, a non-HTTP session management mechanism is useful. As a general enterprise solution for J2EE distributed environments, Kernl's session manager provides this useful mechanism.

Kernl provides a session-based feature to collect transient data for a live session on the server side. It does not rely on HTTP sessions because we envision that systems have to be truly multi-channel - extending beyond web servers. This takes away session management complexity in an environment with multiple web and application servers spread across the enterprise.

Web server HTTP sessions are stateless in nature. Once a HTTP request is serviced, the application server forgets about it. In J2EE/EJB architecture, stateless session bean is widely used as a process model for either transactional or non-transactional requests. The same issues occur when session-related information needs to be transferred across multi-clustered application servers. This makes even simple applications like shopping carts and multi-page questionnaires a challenge to write.

This problem is easily solved when HTTP sessions managed by a web server occurs in non-clustered single domain systems - session-based attributes are simply kept at both client and server sides.

However, in a multiple-clustered application system, the load balancing facility cannot always guarantee that successive calls from the same client will go to the same web server. So a HTTP session object in any particular instance of web server is useless if it is unknown whether that client has already established a session with another instance on another server.

By not relying on HTTP sessions, Kernl removes session management complexity in an environment with multiple web and application servers spread across the enterprise.

Q20. Session management is packaged in every application server. Why would I need to use Kernl's?
Most application servers implement session management differently since they need to replicate this information for load-balancing and failover. Without session management at the framework level, developers will need to handle sessions slightly differently for different application servers since J2EE standards do not define session management architecture. In addition, most application servers perform HTTP session management.

Kernl is not tied to any particular application server, enabling our developers to write truly multi-channel applications.

Q21. If I use the Kernl framework, do I have to use the session manager that Kernl provides?
 No, you can bypass it but we do not recommend it. Session management is a complex issue. Unless you know how to handle the life-cycle of a session, you are better off using Kernl's session manager, which is the default strategy for handling sessions.

Note that our session manager also has features like session timeout, session cleanup and session persistence to support load-balancing and failover. If you are writing business components in Kernl, using Kernl's session manager gives you a good strategy for handling session-based systems with multiple channels.

Q22. Does Kernl's session management use security?
 Kernl's session management uses Public and Private Services so that a user must be authenticated for use of Private Services. This is useful for "stateful" session support.

Q23. Where does Kernl's session management reside?
 Kernl's session management resides on the application server within the framework itself.

Trial

Q24. Do you have a trial version for Kernl framework?
Yes, it is a 30-day limited developer license (5 concurrent user sessions).

Web Servers

Q25. Does Kernl assume that the web server and application server will run together on the same machine?
No, Kernl performs well in multiple scenarios. Kernl was designed with enterprise application solutions in mind. A typical enterprise solution will use several application servers and web servers separately. Since Kernl is a server-side application framework, there is no issue running it on the same machine or physically separate from the web server.

Web Services

Q26. How does Kernl support web services currently?
Kernl is a J2EE framework. Web services are not currently part of the J2EE specification. However, it is currently possible to implement components within the framework to support the support web services (e.g. Messaging). Web services support will be a significant feature in Kernl 2.0.