Application definition and
design approach
Contents
1 Abstract 4
2 Database layer analysis & design 7
2.1 Information adaptation 8
2.2 Siebel data model comparison 8
2.3 Siebel data model extension 9
3 Business layer analysis & design 9
3.1 Data access layer 11
3.1.1 Data access information adaptation 11
3.1.2 Analysis of Siebel's data access layer 12
3.1.3 Siebel's data access layer adaptation 12
3.2 Business logic layer 12
3.2.1 Logic information adaptation 12
3.2.2 Analysis of Siebel's standard logic 13
3.2.3 Siebel's logic adaptation 13
4 Graphic user interface layer analysis & design 14
4.1 GUI adaptation 15
4.2 Analysis of Siebel's standard GUI 16
4.3 Siebel's GUI adaptation 16
5 Integration layer analysis & design 16
5.1 Interfaces adaptation 18
5.1.1 Inbound interfaces 18
5.1.2 Outbound interface 19
5.2 Analysis of Siebel integration layer 19
5.3 Interfaces Adaptation within boundaries of Siebel integration layer 19
6 Conclusion 19
6.1 Discussion 19
7 Appendixes 19
8 Indexes 20
Figures
Figure 1‑1: Siebel Entity Relationship Diagram example. 5
Figure 1‑2: Analysis & Design Waterfall 6
Figure 1‑3: Analysis & design waterfall - integration layer 7
1 Abstract
The main aim of the document is trial of discussion regarding the way of structured analysis and design within Siebel environment.
The purpose of the document will be achieved when such a way will come to its most effective realization, through usage of object oriented analysis and design standard techniques.
Siebel platform is coming to expose object oriented environment based on relational databases, using definition of strong, reflected, and extremely generalized object model. Siebel's object model elements interact within the boundaries of system using provided frameworks defined by application servers that are functioning within enterprise server. The interoperation became to be available thanks to definition of unique interoperation protocol which works over HTTP named SISNAPI. Siebel object model defined within several members/components of application server. Those components are application object managers that provides multithreaded environment using predefined multithreaded servers. Siebel enterprise can accommodate several application servers, when each of those has only one listener (Siebel Connection Broker component) that works simultaneously on application server's machine.
The most significant elements of Siebel object model are:
* Business Object
* Business Component
* Business Service
The Business Component represents an entity based on several tables from within Siebel data model that are joined by appropriate join definitions[1]. Those entities present information that has been gathered during interaction with database layer. The entities within Siebel applications may be related to each other in different ways within different Business Objects that provide ability of entities relationship definition using predefined links. Those links in fact present a parallel concept to join but within Business layer.
Siebel environment has capability of entity relationship definition which in fact presents an ability of effective way to design Business layer through the analysis phase.
Figure 1‑1: Siebel Entity Relationship Diagram example
The following diagram presents a proposed way for waterfall styled analysis & design phases. The proposed way provides an ability with less resources to handle a bigger work front when allows unidefined way of iterative progress started from data model adaptation through several phases to integration layer adaptation.
It must be realized that there is no shortening ways within the analysis phase only fulfillment of each key step as defined within diagram permits proceeding to the next one.
The diagram consisted of nine phases when integration layer is not represented there. It will be presented separately due its uniqueness in analysis and design.
Figure 1‑2: Analysis & Design Waterfall
The interfaces layer analysis & design presented by the following diagram.
Figure 1‑3: Analysis & design waterfall - integration layer
2 Database layer analysis & design
Database layer consisted of complete definition of bounded tables list, their constraints (user keys, data types, physical length, and foreign keys), and their indexes. Siebel database layer supports all of those standard mechanisms and provides several additional capabilities like denormalization path, predefined list of values (part of multi lingual list of values definition), accommodation of tables from different datasources within single data model.
The following are most significant emphasizes of the current issue:
* Determination of all main tables that are going to be used within the application
* Determination of all relationships within the boundaries defined by previous step, and as consequence determination of all foreign keys within each table
* Determination of possible normalization level (1NF[2], 2NF[3], 3NF[4], BCNF[5], 4NF[6], 5NF[7]), when generally Siebel application's data model is designed as 4NF.
* Analysis of possible drawbacks of defined data model in terms of performance, and as consequence definition of denormailzed columns within defined tables
* Adaptation of defined data model within Siebel's predefined data model
* Analysis of gap between those two data models
* Possible change of Siebel data model without impact in terms of non appropriate usage of predefined tables, normalization and performance.
The phase is taking as aim a trial to realize needed data model in non Siebel terms. The external data model must be critically reviewed and different representation of current data model must be done a moment before the information adopted within Siebel's data model.
The result of review must be well normalized (according previous decision) model of data with all necessary constraints, and indexes.
2.2 Siebel data model comparison
Previously defined data model must be critically compared against existed one. During this process the gap must be defined as well as possible ways for its elimination.
The main assumption which must accompany the analyst through this process is that Siebel's data model probably contains all needed tables and relationships. This approach can lead in some cases to change previous decisions that had been made within adaptation process which's been done before, so two visions must come to their common through the current phase of analysis & design.
The result of the process is unidefined data model described by Siebel's terms and adopted within its boundaries by unidefined appropriate technical descriptions.
2.3 Siebel data model extension
As result of previous two phases within Data Layer analysis & design section the appropriate changes may be needed for the Siebel's data model.
The proposed changes are:
* Additional extension tables with 1:1 relationship
* Additional extension tables with 1:M relationship
* Additional stand-alone tables
* Additional intersection tables
* Additional fields for the already existed table
* Additional indexes
* Additional denormalization paths
The usage of extension table against additional fields must be considered in each occurrence of such a dilemma. It must be realized that not in every case the usage of any of those concepts will lead to the best performance.
The usage of denormalization paths within the Siebel data model definition provides an ability of slight denormalization and thereby performance increasing. The performance affected using decreasing number of tables participated in sql statement that underlies given entity (Business Component).
The result of the process is final data model fully adopted within Siebel boundaries.
3 Business layer analysis & design
Business layer consisted of two sub layers: data access layer, business logic layer. Data access layer combines capabilities of database interaction including: sql statement definition, transaction management, and external systems interoperation.
* SQL statement definition - the statement prepared according Business Component definition its base table, joins, search & sort specifications etc.[8]
* Transaction management – completely encapsulated from developer.
* External system interoperation – the interoperability allowed using VBC (virtual business component) and different supported transports within the Siebel system (HTTP transport, MQSeries transport, MSMQ transport, JMS transport etc.)
Business logic layer combines capabilities of process flow management, server & browser side scripting, and predefined functionality managed mainly by user properties of several object model elements.
* Process flow management – Siebel's provides capability of process flow management when defines and allows usage of workflow processes. The workflow processes design within Siebel environment and in fact expose an ability of high level programming using high level declarative bounded programming language. The workflow process paradigm supports SOA concepts using unconnected and unrelated methods and functional point for final purpose achievement[9].
* Server & Browser side scripting – Siebel environment provides several capabilities of additional script appending. The script may be placed in the following object model elements: Application, Applet, Business Component, and Business Service. It must be realized that usage of browser side script must be minimized due to its high intensive impact on client/server networking. The main usage of browser side scripting is field's value or static state checks mainly handled using regular expressions.
* User properties – the object model provided by Siebel exposes predefined functionality based on class functionality of the following object model elements: Applet, Business Component, Business Service (mainly used within Business Component and Applet).
The following are most significant emphasizes of the current issue:
* Mandatory usage of Entity Relationship Diagram designer within the Siebel Tools
* Determination of all strong/weak entities that are going to be used within the application
* Determination of datasource per each entity within the application.
* Determination of all relationships within the boundaries defined by previous step, and as consequence determination of all links[10] related to each entity
* Adaptation of previously gathered information within Siebel's business layer boundaries
* Determination of all possible combinations of entities within the application using Business Objects definition (relationships defined by links[11])
* Determination all needed fields within each among defined entities, the step includes possible definition of joins and multi value link[12]
* Determination of all pre/post default values for each appropriate field
* Determination of gathering behavior per each field using the following properties: Force Active, Link Specification
* Determination of list of values per each appropriate field using picklist[13] concept of Siebel environment.
* Determination all needed calculated fields per each entity
* Review of predefined user properties.
* Determination of all appropriate functional points per each entity including their definition[14]
* Definition of Business Service proxy per each strong entity, for delivering its functionality possibly out of internal implementation.
The layer is responsible for database interaction.
3.1.1 Data access information adaptation
The phase is taking as aim a trial to realize needed data access layer. The data access layer must be critically reviewed and possibly different design of current data access layer must be provided a moment before the information adopted within Siebel's data access layer.
The result of review must be an entity relationship diagram consisted of every defined entity that consisted of fields populated by physical columns from within sql statement produced by the entity or by calculated value.
3.1.2 Analysis of Siebel's data access layer
The phase is taking as its aim an analysis of already existed entities environment within the Siebel system and trying to find out whether entity relationship diagram suits currently existed environment.
Siebel environment supports many different relationships and provides an ability to see by different view angle in many cases, different relationship picture.
The result of this step must be full realization of Siebel environment capabilities in terms of its suitability to entity relationship diagram defined within the previous step.
3.1.3 Siebel's data access layer adaptation
This phase is coming to compose the results of two previous phases by adaptation within Siebel business layer boundaries. The result of such an activity can be decision to extend data access layer by addition other entities or in opposite way just to change existed ones.
In case of data access layer changing the need of changes within database layer may raised up. In such a case database layer design need to be reconsidered and all related steps need to be performed as described by Figure 1‑2: Analysis & Design Waterfall.
The result of this phase must final definition of appropriate entity relationship diagram within Siebel boundaries and its complete design including possible extensions or changes supported by database layer.
The layer is responsible for internal business logic.
3.2.1 Logic information adaptation
The phase's main aim is complete definition of all needed logic regarding the implementation. The logic definition needs to be gathered from every possible source in order to avoid further problems of miss leaded solution.
The gathered functional points must be collaborated and generalized in order to design an effective logic mechanism that will answer on basic object oriented analysis & design criterions: reliability, availability, extensibility. Moreover the potential design needs to compose several significant characteristics like encapsulation, generalization, overtaken execution, unidefined strong types. The design must consider the data access layer designed during previous step.
The result of this phase must be thorough definition of needed business logic and its potential design in terms of object oriented paradigm considering Siebel environment restrictions.
3.2.2 Analysis of Siebel's standard logic
This phase deals with Siebel internal functional ability in terms of its suitability to previously defined business logic. During this phase the gap must be assessed and trial to overtake it within the Siebel boundaries must be taken.
The result of this phase must be fully realized and determined gap between business logic provided by Siebel environment without any interference and needed business logic defined and designed during previous step. The gap in fact may be handled and assessed in terms of computational and time complexity and as consequence translated to actual/real schedule and work front. It must be realized that without any reliable assessment of potential development phase, the work become to be adventurous and potential risky without any justification. It must be realized that under some circumstances the needed business logic may lead to some changes within data access layer..
3.2.3 Siebel's logic adaptation
The phase's aim of this step is to translate previously assessed functional gap in actual Siebel system design using appropriate system tools, in other words to perform an adaptation of previously defined and designed business logic.
The adaptation of the business logic must include definition of every functional points per each entity within developed application, moreover it have to show how the process flows will be treated, how the general functionality will be used, how the elements of object model are going to interact within the application.
The following key elements must be supplied:
* Business Component logics
* Business Component's proxy logics
* General Business Service definition
* Common Error Handler definition
* Common Messaging Engine definition
* Common Logging definition
* Application logics
The result of this phase must be final and full composed design of technical solution in order to achieve an appropriate functionality/business logic defined by previous steps. The design must be based and supported by data access layer and its entities. It must be realized that business logic mustn't be defined and designed separately from data model and data access layer definitions, because of their mutual influence.
4 Graphic user interface layer analysis & design
Graphic user interface layer consisted of complete definition of every appropriate GUI elements. Those elements are listed below:
* Screen
* View
* Applet
* Tool bars (mainly based on JavaApplets)
Siebel applications provide two different approaches of application running framework:
* Web thin client
* Web dedicated client[15]
Siebel applications provide two different approaches of application exposition:
* High interactive[16]
* Standard interactive[17]
The following are most significant emphasizes of the current issue:
* Determination of all needed Screens within the application. When the Screen composes logically related groups of entities (for example Accounts, Contacts, Orders, Quotes, Opportunities, Agreement, Products).
* Determination of all needed Views within the application. When the View based on Business Object and potentially exposes the relationships defined within the Business Object using Applets and their basis Business Components, when the last are related to each other by relationships reminded above.
* Determination of all needed Applets within the application. Each Applet based on Business Component and represents the data retrieved from database through database and data access layers within the boundaries defined by relationships of its Business Component inside the Business Object that underlies the current View.
* During the previous step the need of data access layer changing or extension may be raised up. In this case all appropriate steps from Figure 1‑2: Analysis & Design Waterfall must be taken and evaluated again.
* Determination which of defined Applets from previous step will participate in each of predefined Views.
* Determination which of defined Views from above steps will participate in each of predefined Screens
It must be realized that Siebel system exposes its Web application using its own web extension. The extension (.swe) uses the SWE plug-in within the Web Server for interconnection with Siebel Application Server's SWSE plug-in using integration layer. The SWSE produces the content of the Web site using Siebel's own markup language. Siebel does not provide any tools for effective work with web templates that written in reminded above markup language.
The information above is reasoning that mainly no web templates changes are acceptable[18].
4.1 GUI adaptation
The phase's main aim is gathering all needed information in order to define and perform a prior design for a graphic user interface.
During the define phase there is no need to take in considerations Siebel application constraints and functional restrictions. The main purpose of this step is full and deep understanding of application's desired graphic user interface, including all possible features.
The result of the phase is defined GUI, when all features considered and integrated within the definition. It must be realized that Siebel system is not a development platform and there is no reason for such a relation to it.
4.2 Analysis of Siebel's standard GUI
This phase is taking as its purpose an analysis of Siebel standard graphic user interface and its suitability to the definition of GUI that has been done during previous step.
During the work related to the step, a need for change or extension within data access layer may be raised up. In such a case all needed steps according Figure 1‑2: Analysis & Design Waterfall must take a place in order to handle cascade adaptation of all redefined structure to a new reality.
The result of this phase must be compared analysis of needed GUI against existed one and as consequence a gap needed to be handled by adaptation step. It must be realized that GUI must not lead the design phase and in fact just represents predefined data access layer using standard Siebel's object model elements.
4.3 Siebel's GUI adaptation
The main aim of this phase is performing an adaptation of previously defined GUI. During the adaptation all needed technical solutions must be considered in order to achieve an appropriate appearance defined within previous steps.
It must be realized that Siebel environment has its own tools for GUI implementation, and main course is staying within the boundaries that Siebel provides by those tools.
The result of this phase must be final design of new application, consisted of database layer, business layer, and graphic user interface layer.
5 Integration layer analysis & design
The integration layer is maybe the most sophisticated layer from technical perspective. Its effective implementation relies in many aspects on well defined and designed data business layer, when not just data access layer is important, but functionality across involved entities has its own inevitable influence on integration layer.
The main aim of integration layer design is trying to stay within the thesis that integration layer can operate using the same business layer like graphic user interface. In many cases the thesis fall down under the pressure of reality that dictates different process flows within GUI and integration layer.
Within integration layer the following types of interface can be distinguished:
Inbound interfaces
Outbound interfaces
When in their turn the inbound interfaces can be categorized as following:
Inbound gusty interface[19]
Inbound on-demand interface[20]
The following are most significant emphasizes of the current issue:
Determine all needed interfaces against every external systems
Determine among those interfaces, those that will participate inbound interfaces group, and those that will take place in outbound interfaces group.
Determine within inbound interfaces group those interfaces that demand an answer in synchronous manner and those that demands it in asynchronous manner.
Choose the integration mechanism architecture for outbound interfaces[21]
Choose the integration mechanism architecture for inbound interfaces[22]
Define per each interface appropriate communication protocol in terms of in/out message[23]. In case that integration middleware is existed the common object modeling paradigm must be used in addition the intermediary must be used in order to delegate transformation and redirection duties from Siebel to the that intermediary.
Analyze Siebel integration layer in order to find out whether needed integration layer can be implemented using standard and common mechanisms predefined within the Siebel system. If during this examination the need of business layer has been raised up, the appropriate steps in order to handle cascade change of whole application design must be taken before actual proceeding.
Design every interface separately considering every restriction of Siebel and external systems. The main purpose is to stay within predefined unified approach.
Design any needed infrastructure based on Business Services, Workflow Processes, and Business Components in order to simplify, generalize, and unify the uture development[24].
The main aim of this phase is collaboration of information regarding any needed interfaces within the boundaries of future system. At this moment the design is ready and analysis of future interfaces can rely in some aspects on work that has been done before, but still the process of gathering information and definition of interfaces on basis of information reminded before will be done without any considerations in terms of Siebel's future application architecture.
The result of this phase is full list of all needed interfaces divided on two parts: inbound and outbound. Each of those interfaces definition must include its nature (synchronous, asynchronous), destination and source systems, and structure of expected messages for request as well as for response.
Inbound interfaces can be handled using several approaches:
* EAI object manager framework. The framework provides an ability of standard typeless HTTP request usage as well as Web Services[25].
* MQSeries receiver[26]
* MSMQ receiver
* JMS receiver
* External DLL functions plus Blob (binary big objects)[27]
* CORBA architecture[28]
* Custom repeated job with wrapped JMS client (using Siebel Java Business Service)
Recommended approach is most standard and most reliable approach – EAI object manager plus Siebel Web Services.
5.1.1.1 Interfaces on demand
Depends on nature of interface: synchronous or asynchronous.
The synchronous, on demand interfaces in fact provide a response immediately during the integration session. The asynchronous mainly provide just a job id or any other process identification in order to be able to tie future response with the request.
It must be realized that approaches like HTTP request and Web Services can be used for asynchronous integration also[29].
5.1.1.2 Interfaces without demand
The inbound gusty interfaces suppose to work against EAI object manager framework or any other server's receiver component that implements monitoring/poling paradigm.
The outbound interfaces implemented using one of available transports within the originating system.
5.2 Analysis of Siebel integration layer
The main aim of this phase is analysis of currently provided by Siebel capabilities in order to find out whether defined in previous steps interfaces are suitable and may be implemented within the Siebel future application using standard Siebel's tools.
As result of reminded analysis the change within already defined and designed business layer may be raised up. In such a case appropriate steps in order to handle cascade change across whole application definition and design must be taken according Figure 1‑2: Analysis & Design Waterfall and Figure 1‑3: Analysis & design waterfall - integration layer.
The result of this phase must be the gap assessment if existed between needs and system capabilities considering future system definition and design
5.3 Interfaces Adaptation within boundaries of Siebel integration layer
The phase takes as its purpose final design of all predefined interfaces. At this moment every interfaces defined, and found suitable to predefined business layer.
The main activity through this phase is mapping of defined interfaces with predefined business layer.
The result of this phase must be final design of every defined interface.
The phases of definition and design in many cases have very smooth boundaries. This contiguity in many cases leads to mistakes within the stage of analysis and design, especially when the environment is not thorough object oriented and there are no undefined layers within the environment.
The process of analysis and design must be managed and planned very carefully, no jumps and parallel work suggested. If those conditions will preserve it is possible to perform an analysis and design with less resources, but more effectively.
6.1 Discussion
The stage of project where the future system first time gets its conceptual fullness is the stage of analysis. The analysis of future system requirements sometimes may bring analysts in front of in a good case very heavy problem and in a worst case the problems without the solution in given circumstances.
The reasoning above leads to conclusion that analysis must be performed top-down, when the meaning of that statement – system requirements in each of its layer need to be generalized and per each specific need the analysis will to go down through the general to the subject itself. When the thesis is that within several points of such an analysis the previous points will take part of it and at end the full analysis will able to accommodate a reasonable change within conceptual boundaries of the system without any impact and almost without any further analysis.
Design stage in many aspects very similar to analysis, but the biggest difference between those is that design never can lead the analysis, but analysis always leads the design.
It must be realized that sometimes development/system environments (like Siebel, .NET, J2EE, SAP) set up the boundaries of its capabilities, especially when the system is not clear development resource like Siebel, in such cases design will influence analysis, just because not everything is possible within the environment.
* "Workflow usage best practices"(Roman Agaev)
* "Common guidelines" (Roman Agaev)
8 Indexes
analysis, 2, 4, 5, 7, 9, 12, 13, 15, 17, 19, 20, 21, 22
Business Component, 4, 9, 10, 11, 14, 16
Business layer, 2, 5, 9
Business Object, 4, 15, 16
Business Service, 4, 10, 11, 12, 14, 19, 20
Database layer, 2, 7
design, 1, 2, 3, 4, 5, 7, 9, 10, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22
diagram, 5, 7, 12, 13
Entity Relationship Diagram, 3, 5, 11
environment, 4, 5, 10, 11, 12, 13, 17, 21, 22
Graphic user interface layer, 2, 15
GUI, 2, 10, 15, 16, 17, 18
HTTP, 4, 10, 18, 19, 20
integration layer, 2, 3, 5, 7, 16, 17, 18, 20, 21
interaction, 4, 9, 12
JMS, 10, 18, 20
MQSeries, 10, 18, 19
MSMQ, 10, 18, 20
normalization, 8, 11
object model, 4, 10, 11, 14, 17, 19
object oriented, 4, 13, 21
performance, 8, 9
Siebel, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22
SQL, 10
SWE, 16
SWSE, 16
[1] There are only two options regarding tables joining within Siebel environment: inner join, left outer join. Another significant remark is that joins can be implicitly or explicitly defined.
[2] 1NF – There is no duplicate rows in a table, each cell is single valued, entries in the column are of the same kind
[3] 2NF – 1NF plus if all non-key attributes are dependent on all of the key
[4] 3NF – 2NF plus if it has no transitive dependencies (A transitive dependency is a type of functional dependency in which the value in a non-key field is determined by the value in another non-key field and that field is not a candidate key)
[5] BCNF (Boyce-Codd Normal Form) – 3NF plus if every determinant is a candidate key
[6] 4NF – BCNF plus if it has no multi-valued dependencies
[7] 5NF – 4NF plus if every join dependency in the table is a consequence of the candidate keys of the table
[8] Search & Sort specifications may be provided through the GUI definition also.
[9] For more information regarding workflow processes please refer to "Workflow usage best practices" from appendixes section of the document
[10] Link – Siebel object model element, in fact the element is enabling override of entities combinations/relationships within an application previously defined by database layer using foreign keys and normalization concept.
[11] Mainly link must be based on database layer and its foreign keys including cascade behavior
[12] Multi value link (MVL) is the second option of combining entities together using link definition. Highly usable within integration processes
[13] Picklist is presentation layer of predefined business component. The picklist allows population of several fields within an entity through the pick action of one of its available entries. Mainly based on List Of Values business component.
[14] Mandatory being within boundaries determined by Common guidelines document, please refer for additional information to appendix section of the document
[15] Web dedicated client – application and web server instances are running locally. The application's data source not relevant and can be any available choice.
[16] High interactivity – the meaning is that web site uses interactive elements downloaded to a client machine in order to improve user experience and standardize client/server interconnection using common events paradigm.
[17] Standard interactivity – the meaning is that the web site works as standard web site using html stream which is coming regarding client's request from server side. The approach has many disadvantages when the major one is user experience.
[18] In each rule there are exceptions, here every exception must be proved as inevitable.
[19]The interfaces just arrives to the predefined virtual directory that points to the EAI object manager server component.
[20]The interface that in fact the following step of previously initiated outbound call. The result of such a call may be provided in synchronous or asynchronous manner, when the emphasize deals with the second option.
[21] There are many different ways to get connected within the enterprise, when the most significant ways are: HTTP request, Web services, JMS, MQSeries, MSMQ
[22] It must be realized that any other choice except EAI object manager framework, must be proved as inevitable solution because of it's being not standard
[23] It must be realized that any other choice except XML won't be the main stream/standard choice.
[24] The reminded elements of Siebel object model are not affecting already defined design. They must be part of infrastructure additional resources.
[25] Siebel Web Services are fully compliant with common WS standards provided by WWW consortium. Siebel Web Services supports usage of SOAP, XML, WSDL, WS-Security, RPC binding, Document binding, WS ports.
[26] Background Siebel component instance that enables checking of predefined queue on predefined server and invokes an appropriate Business Service or Workflow Process.
[27] Usage of Blobs and their descriptors enables integration without XML data representation. The same has been used by .NET framework (for 1.1, 2 versions, and WCF for further version) for Remoting concept design
[28] The most complicated architecture, demands additional several components within Siebel application server.
[29] Every interface must be defined carefully with full considerations regarding every possible and impossible restriction.
View Roman Agaev's profile
1 comment:
Good words.
Post a Comment