Jmservice Framework

Jmservice Framework


Chris Liao


2007/02/01




Content

1. Introduction

1.1. What is service?

1.2. Service and Client

1.3. Service and Lifecycle

1.4. Service and other Service

1.5. Service and Domain

1.6. Service and Component

1.7. Component and Description

1.8. Source and Detection

1.9. Source and Identification

1.10. Source and Parser

1.11. Component and Deployment



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 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.3. 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.4. 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.5. 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.6. 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.7. 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.8. 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.9. 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.10. 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.11. 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.


More detail, please visit Http://JminApp.id666.com and click "framework" topic

文章来自: 本站原创
标签: