Jmservice                                                                                           (PDF  DOC)



 

1.   Introduction

Jmservice is a framework in SOP(Service Oriented Programming), which is contained in jmin server.The framework is designed to programming in logic domain. If you are not familiar with its theory and its basic concept; we will introduce them to you step by step and lead you over the course of our design.

1.1. What is service?

Why dose our program visit servers? It is because servers provide some useful applications to be visited and to handle request from clients. This phenomenon is very general in Client-Server model, maybe you enjoy or use some various applications in servers for your work, but you don't care their concept and  their internal actions. Although these applications look very complex and different, if be careful, a common feature can be found in overview: every one works in a domain and  makes effect to others, for example: handle invocation  from outside or finish  some useful tasks for outside.In our opinions, we suggest to use 'service' word to represent the feature. "Service" is a logic concept, some objects are integrated together to finish collaboration and should be regarded as one in logic point. It is that integration in logic and separation in physics for these objects. Sometimes, the "service" word doesn't appear in some applications, but in fact, same things are doing. Here, we abstract this concept further and define it as a object, you can get it from our source.

1.2. Service and Domain

Services are designed to help us do some things for outside and every service just expresses some problems in a domain. In other words, a service maps a domain, and definition of service depends on domain which is a way. In fact, we can regard services as logic AOP. Commonly, a service is not independent, some components are allowed to run on it and work as parts of it.

1.2. Service and Client

If exist some services to be visited, clients can visit them by interfaces. However, it is possible that not all services are visible  to clients, they are just applied internally and don't supply approach to outside, for example: we can assume a InitService service to finish one thing, which just  initialize some system parameter, so it is not necessary to be invoked by outside. It is free to design behave of a service, we advise to follow its responsibility in designing your service. A clearly figures is below; hope you to get our meaning from it.

1.4. Service and Lifecycle

The lifecycle of service may be different, some die at the end of  applications, some die once finishing some thing. But how to control  them?  Designers should be allow to do it in his/hers program

1.5. Service and Other Service

Mainly, a service just does some things for outside. It is possible that  a service invokes others during  tasks, this case is allowed. If this, there exists dependency between  some services. 

1.6. Service and Combination

Some services may be combined into a new service.

1.7. Service and Component

Components can run on services, whose technology is very popular in software programming., programmers design components to finish some business operations. However, if observe these components from higher level: every one is active in a service. When invoke interfaces of a component, a service are implicitly invoked. Concept of service is abstract, and not easy to be caught. In some points, every component should be associated with a service. Of course, it is also feasible that no any components on a service, which can be chose by designers. But services how to hold them? Containers are expected, and components live in them. But what instrument is depended when  instantiating components. Description is a good way for this.

1.8. Component and Description

In most conditions, we use source files to store components and theirs description which may be XML files, properties files or others. This is very commonly in J2EE, if release a pressed file of J2EE components, you will find some class files and some XML files which contain some important information, for example: names of components, transaction and security, and so on. When components are loaded from physical files, description files should be resolved together. Every service should supply a fixed format for its components. Although description of components is a good instrument, if don't find source files contain components, resolving components can’t be continued.

1.9. Source and Detection

We think that a set of mechanism should be applied here to discover source of components, and it is able to detect changes on source of components. For example, if a source file has been deployed, this mechanism should discover it, then raise a notification which contains a changed source. Three types of changes are for source:  new files are found; updated files are detected; deleted files are found; The notification will hold this change information. Source may be xml files or property files or others.

1.10. Source and Identification

If server wants to resolve components from a source, what can it do at first?  Identification, in logic points, a source just contains a kind of components which can map a service. A way should be prepared to identify them. When find one, server will  retrieve a relative service  by source, then components are resolved from the  source. We suggest to put the instrument in service, a interface to do it  is include in our framework.

1.11. Source and Parser

Our goat is deploying components in service containers. Physical files are used to store persistent components,  relative services instantiate components from source by description and do some initialization on them. Because of difference in source description for services, difference is in resolving source. We have designed a parser object to do this task  in our framework.

1.12. Component and Deployment

When components are resolved from source, services do some useful actions on components, for example: deployment. A helper class is designed to do some things for a service, you can add some detailed methods in the helper for services.Before visiting service components, they may have been active in service containers. Due to various services, there exists difference in their deployment. Component  description is very important, when deploy a component on servers, it should be resolved. Sometimes, deployment is a primary path, and so much relative operation hide under deployment. In our points, all operation about components should be around two aspects: Component preparation (deployment) and component invocation, we can regard deployment as begin of components.

      

2.Jmservice in Jmin

2.1. Objectives

1: Build a service platform(Jmkernel) on this framework.

2: Simplify server structure and make logic clearer

3: Tell you how to organize services and deploy components

4: Show advantage and features of this framework.

 

2.2. What in J2EE Server?

There are some applications contained in J2EE servers, for example: Naming, JDBC, Transaction, EJB, and so on. If you are a J2EE programmer, you may meet the following things:

1: Binding and resolving objects in Naming

2: Configuring data source in JDBC domain

3: Deploying EJB components in EJB containers

If be careful, a common feature is found from them: every one provides some operations for outside in explicit way or in implicit way. This matches the features in our framework. We can regard these applications as services applied in J2EE

2.2. Characters of service

What can these J2EE services do? They let some j2ee components run on them. Commonly, before visiting components, they should have been deployed. In our points, deployment (Component preparation) and component invocation are two main lines and many logic operations hide under them. If a component is expected to be deployed in a server, it should be acceptable by the server and the description of  the component is a key. Some features from j2ee services are listed below.

1: Service invocation

2: Component description

3: Component deployment

2.4. Configuration of Service

An XML file to integrate all services in a J2EE server and advise to drive IOC mechanism to resolve this file. The file format is below:

2.4.1.1.   File format

2.4.1.2.Order in the file

Services defined in this file must follow an expected order, which is a load order. When a service is being instantiated, it may invoke others. Dependency exists between services. The depended service should be loaded earlier. Developers should think over the order for their application, then organize them in the file.

2.4.1.2.     Service List in Jmin

Service Name

Description

ORBService*

Startup server orb

Nameservice*

Java name service

JDBCService

Provide j2ee data source

TrnasactionService

Provide j2ee transition

EJBService

Run EJB components

WebService

Run web components

 

 

DiscoverService*

Discover j2ee source (it must be at the end of the order)

2.5. Management of service

A locate can be found to manage services, for example: load services, registering services and unregistering services. We have defined an object to do them in the server architecture, please note the source

2.6. How to launch service?

Once run server, services will be loaded into memory, then do some initialization for them. There exists a load order for services; please refer to the content in configuration subject.

2.7. How to discover j2ee source?

When J2EE programmers deploy their components in servers, a set of mechanism is necessary to discover them. The Jmserver  architecture provides a  sub framework to discover component source, we named it as Jmdiscover framework, which run as a J2EE service in Jmserver architecture. More detail, please read the source of it.

2.8. How to deploy components?

Deployment is primary in J2EE servers. Different types of components hold different description and map different deployment. A J2EE Assistant are designed to do the deployment task and contained in Jmkernel


Copyright © 2006 . All Rights Reserved.