IT Governance

소프트웨어 공학 관련 자료

TeddyLee — Fri, 21 Sep 2007 16:34:55 +0900

http://www.cs.toronto.edu/~sme/

PDCA - Plan Do Check Act

TeddyLee — Tue, 18 Sep 2007 15:21:56 +0900

Plan Do Check Act
PDCA ^^

http://www.soodon.net/131

http://www.12manage.com/methods_demingcycle.html
http://www.12manage.com/methods_venkatraman_strategic_alignment.html
http://www.12manage.com/index_expert.html ==> 아주좋아써
http://www.soodon.net/rss

test

TeddyLee — Mon, 17 Sep 2007 17:57:53 +0900

Designing Performance Testing Metrics...

TeddyLee — Wed, 29 Aug 2007 17:24:00 +0900

February 2004

Discuss this Article

Introduction

In ancient computing times, a wise system architect once said, "you can't manage an application you can't monitor." In many cases, documenting the design for a new application, let alone how it might be monitored, is typically beyond the scope of the project. This article describes a reusable mechanism for capturing application-bound, performance statistics for highly distributed J2EE applications.

Applications essentially need to be engineered to support established service levels (i.e. Service Level Agreements). In some cases, SLA might be very granular, such as, stating the elapsed time expected to persist data related to a person. The architecture depicted in Figure 1 was implemented to handle an Internet order entry, including a self-service feature to allow a customer to update his own profile.

Figure 1. Distributed J2EE Architecture

Because of expectations of high order volumes, the application was engineered to provide distributed EJB transactions, which can be pooled and clustered for high availability and scalability. Highly distributed applications not only need to be engineered from a distributed object standpoint, but from a load balancing and clustering perspective, too. The architecture does not reflect load balancing and clustering implementation details.

This document describes a basic methodology for performance testing the distributed architecture. Essentially, the document describes the design and edits required to collect basic instrumentation/timing estimates for a distributed J2EE application.

The Distributed Architecture and Time Synchronization

The J2EE application relies on five tiers: a Web, EJB, EAI (Enterprise Application Integration), ERP (Enterprise Resource Planning) and DBMS tier. An Internet client makes an HTTP request to the Web tier and forwards the request over RMI/IIOP to the EJB tier. The EJB tier communicates with the SeeBeyond EAI tier using a SeeBeyond MUX e*Way . The EAI tier communicates with the Peoplesoft CRM (Customer Relationship Management) application within the ERP tier using a Peoplesoft adapter. Finally, The CRM application integrates with an Oracle DBMS over SQL*net.

A key part of any distributed environment is the time server. Within the methodology, instrumentation metrics are collected on the server where the code is executed, so it is important that all machines within the distributed J2EE architecture are time synchronized. Within the IBM AIX UNIX environment, the xntpd daemon sets the internal clock time on a machine. The service is used to synchronize time services with an external machine using the Network Time Protocol (NTP). Typically, there is a time server, which does not necessarily need to be another AIX or UNIX machine, within an organization's network that all machines synchronize with on startup. (In reality, machines with xntpd configured synchronize constantly, not just on startup.)

Alternatively, a machine can synchronize with an external time server on the Internet. The xntpd daemon defaults to off, so time settings, such as the IP address of the time server to synchronize with, needs to be configured within an ntp.conf file. Since instrumentation metrics are collected at the second or even millisecond levels, discrepancies between machines can lead to spurious performance statistics.

Object Specification and Instrumentation Behavior

The proposed J2EE architecture relies on a number of well-known design patterns, such as the Business Delegate (a.k.a. Proxy), Data Access Object, Model-View-Controller, Session Facade and Transfer Object (a.k.a. Value Object). A transfer object is a serializable class that groups related attributes, forming a composite value. In the architecture, the Transfer or Value Object is used as the return type of a remote business method, such as an Enterprise JavaBean. Fetching multiple attributes through the value or transfer object in one server roundtrip decreases network traffic and minimizes latency and server resource usage.

Figure 2 depicts the PersonValueObject, which implements IPersonValueObject and Serializable interfaces. The PersonWorkerBean uses a PersonValueObject for containing person and instrumentation attributes. Instrumentation attributes are long values, which contain a timestamp from calling System.currentTimeMillis(). The PersonValueObject also includes accessor methods for all attributes.

Figure 2. UML Class Diagram Value Object Specification (a.k.a Transfer Object)

While it is good OO practice to provide accessor methods instead of allowing direct manipulation of instance variables, it also increases overhead by imposing an additional method call. You want accessors to hide the implementation of get and set, and to allow subclasses to change the synchronization of a get or set, but there will be an overhead cost. Value objects can be sub-classed or they may have associations with other Value objects. For example, if requirements dictated that all Value objects in the application needed to be performance tested, refactoring instrumentation operations within a "FrameworkValueObject" would strongly be recommended. In this alternative specification to Figure 2, the PersonValueObject would extend the FrameworkValueObject and implement the IPersonValueObject interface; the IPersonValueObject interface would extend the IFrameworkValueObject interface. However, the operations listed in the IPersonValueObject would be the same as depicted in Figure 2 for either specification. The advantage to using this model is that all value objects would extend the FrameworkValueObject and therefore have instrumentation behavior; however, this is a complex relationship, and while correct from a UML (Unified Modeling Language) perspective, in and of itself would exert a performance cost to the application.

For value objects that have a direct association with other value objects, those relationships are implemented as class instance variables. UML recommends that for value objects that have an aggregation or composition association with other value objects, those relationships should be implemented as a Collection. A Collection is the root interface in the Java Collection hierarchy. A Collection represents a group of objects, known as its elements. This interface is typically used to pass collections around and manipulate them where maximum generality is desired. For example, a PersonValueObject contains one to many AddressValueObjects or a Collection of AddressValueObjects. However, this relationship is not included in the diagram, because it is not related to capturing timing estimates, but it is important to "real world" applications.

Instrumentation Data Collection Process

The objective of the methodology for this project was:

To estimate the total elapsed time to marshal and persist a PersonValueObject within middleware components.
To determine which tiers or key processes were the most expensive from a performance perspective and where optimization might be needed.
To be able to log timing estimates from multiple tiers in a single log file, which makes performance analysis and reporting simple.

Once the value object was wired for collecting instrumentation/timing, instrumentation edits were required in the J2EE and SeeBeyond application code. This required identifying the objects that would set timing estimates into the value object for the tier, and which object would be responsible for getting the estimates and writing them to a log file. The number of places in the code that timing metrics were collected was, in a way, an arbitrary decision. It was determined that the following objects needed to be reworked:

PersonWorkerBean on the Web Tier - would be responsible for setting timing attributes (that is, T1 and T6) on the PersonValueObject to determine total time spent marshaling the remote Session EJB from the Web tier, getting all timing estimates from the PersonValueObject and writing them to a single log file.
EJB SessionBean on the EJB Tier - responsible for setting timing estimates (T2 and T5) on the PersonValueObject to determine elapsed time spent on the EJB tier getting a connection to SeeBeyond and parsing the PersonValueObject into a delimited string for SeeBeyond processing.
PersonDAO (Data Access Object) on the EJB Tier - responsible for setting timing estimates (T3 and T4) on the PersonValueObject to determine total time spent on the EAI tier.

Architectural Limitations

The input for testing the application was generated using Mercury Interactive's LoadRunner via an HTML browser; this discussion, however, is out of scope for this report. Internet/network timing estimates, that is, download time from the HTTP server to the browser, are not collected through the value object; intranet download timing estimates must be imputed by estimating elapsed overall response time through LoadRunner minus PersonValueObject timing estimates collected in the framework_log4j.log.

The target of the log4j log output can be a file, an OutputStream, a java.io.Writer, a remote log4j server, a remote Unix Syslog daemon, or even an NT event logger, among many others. The performance of the log4j package is also quite good. On an AMD Duron clocked at 800Mhz running JDK 1.3.1, it costs about 5 nanoseconds to determine if a logging statement should be logged or not. Actual logging is also quite fast, ranging from 21 microseconds using the basic configuration.

It is important to point out that the purpose of the methodology is not memory and CPU application profiling as would be performed by tools such as JProbe from Quest Software or Optimizeit form Borland. The only tools that are engineered for distributed performance monitoring similar to the methology discussed here are PathWAI Dashboard from Candle Corp. and Introscope from Wily Technology.

Figure 3. UML Sequence Diagram - Create a PersonValueObject

A successful execution of the application from the Step 1 createPerson on the PersonWorkerBean to Step 23, writing the timing data to a Log4j log file would result in a single row that can be parsed into the following matrix. Timing estimates are collected in milliseconds. The table below is used to depict the elapsed time for processes within the application tiers, which is somewhat an arbitrary decision based on requirements. In effect, various permutations and combinations of processing times can be estimated, as long as the analyst/programmer has a solid understanding of the context of the timestamp captured. For example, 250 represents the total elapsed time marshaling the PersonValueObject from the Web tier through the entire application, whereas, the Incremental Elapsed Time Column is an imputed estimate for processing within tiers.

Implementation Details

Step 1: Implement instrumentation code edits for the IPersonValueObject Interface for the PersonValueObject Class (see Figure 2).

Step 2: Implement instrumentation code edits for the PersonValueObject Class (see Figure 2).

Step 3: Instrumentation code edits for the log4j.xml that sets priority level for application logging to the framework_log4j.log file. log4j relies on a configuration file for runtime settings. It also provides an ability to dynamically set the log levels (i.e. DEBUG, INFO, WARN, etc.).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration
debug="true">
   <appender name="TEMP"
       class="org.apache.log4j.FileAppender">
      <param name="File" value="framework_log4j.log"/>
      <layout class="org.apache.log4j.PatternLayout">
        <param name="ConversionPattern" value="%d - %m%n"/>
      </layout>
   </appender>
   <category name="proofofconcept">
      <priority value="info"
      <appender-ref ref="TEMP"/>
   </category>
</log4j:configuration>

Step 4: Implement instrumentation code edits for the PersonWorkerBean (see Figure 3). The PersonWorkerBean logs the timestamps to the framework_log4j.log file by invoking a log4j.info method on a static reference to the Log4j Logger class. There are really two key classes: the PropertyConfigurator and Logger. The PropertyConfigurator.configure method is used to pass the location of the configuration file. The Logger is used to set the logging messages, the logging level and to identify which classes in the application you want to log errors for. The recommended pattern for extending the Logger class within Log4j is wrapping or creating a reference. It is strongly discouraged that users subclass either the Logger classes. Log4j provides an ability to (dynamically) set the log levels (i.e. DEBUG, INFO, WARN, etc.) or provide the level through a configuration file. By setting the level to "info", all messages of "info" and above will be written to the log file. Provided that the application does not throw any exceptions, there should be only one "info" message written to the file, which includes timing estimates for all middleware tiers.

Step 5: Implement instrumentation code edits for the PersonServiceSessionBean (see Figure 3). The PersonSessionBean create method receives a serialized copy of the PersonValueObject, sets the estimate into the PersonValueObject and calls the createPerson on the PersonDAO. In the model, the DAO is used to get a connection to the SeeBeyond EAI application server, and the PersonValueObject is not directly persisted into a DBMS. The point is, that in most J2EE applications, the Data Access Object pattern is used to specify how to persist data into DBMS.

Step 6: Implement instrumentation code edits for the PersonDAO class (see Figure 3). The createPerson method on the PersonDAO sends the PersonValueObject to the SeeBeyond application server using a MUX e*Way, a synchronous protocol. For this implementation, the PersonValueObject attributes where sent as a test message, because the SeeBeyond application server only supported text messages. The returning message from SeeBeyond, because it represented a string, not a PersonValueObject, needed to be parsed using a StringTokenizer. This edit for instrumenation code assumes that there are 3 tokens in the order in the format "Id^timeStamp1^timeStamp2." The Id is generated by SeeBeyond and represents the primary key for the PersonValueObject created.

The SeeBeyond application server provided timestamps for integration with the Peoplesoft CRM. SeeBeyond also returned the generated primary key, which would be required for persisting associated value objects, such as Address value objects. This is not modeled in the UML sequence diagram, because the central theme is how to collect timing estimates within disparate computing tiers.

protected IPersonValueObject createValueObject(
    String rs )
    {
        IPersonValueObject valueObject = null;
        try
        {
            valueObject = getPersonValueObject();
            if ( valueObject == null )    // create one
            {
                valueObject = new PersonValueObject();
            }
               StringTokenizer st =
                  new StringTokenizer(rs, "^");
               PersonPrimaryKey pk =
                  new PersonPrimaryKey(st.nextToken());
               valueObject.setPrimaryKey( pk);
               valueObject.setT3( Long.parseLong(st.nextToken()));
               valueObject.setT4( Long.parseLong(st.nextToken()));
                      }
        catch ( Exception exc )
        {
            printMessage("PersonDAO:createValueObject()-" +
                         exc );
        }

        return( valueObject );
    }

Architectural Implications

Ideally, the best design would allow for a ValueObject to be passed to all middleware tiers. SeeBeyond on the EAI tier actually has asynchronous support using JMS (Java Messaging Service) text messages, but not for JMS ObjectMessage type messages. Most implementers would prefer ObjectMessage type messages. For example, with an ObjectMessage type using JMS, the PersonValueObject would not have been parsed into a String object, but could have been sent directly to SeeBeyond . ObjectMessages - messages containing a serialized Java object - make it clear to programmers which data type and attribute they are receiving and sending. With support for JMS ObjectMessages, the PersonEAI object depicted in Figure 4 could have been implemented in SeeBeyond, which could have marshaled directly the PersonValueObject. For distributed object programmers, this is what it is all about -- transferring objects around the network.

Figure 4. View of participating classes for UML Sequence Diagram - Create a PersonValueObject

About the Author

Frank is a Lead Architect specializing in J2EE application design and implementation of enterprise-wide applications. He can be reached at frank_teti@hotmail.com.

COTS Integration

TeddyLee — Mon, 27 Aug 2007 14:36:44 +0900

http://www.sei.cmu.edu/str/descriptions/cbsd.html
http://www.cebase.org/www/frames.html?/www/researchActivities/COTS/integrationmodels.html
http://www.ncca.navy.mil/services/software/cots.pdf
http://www.computer.org/portal/cms_docs_software/software/content/value.pdf
http://tharkun0.ucsd.edu/ResearchCentral/download.jsp?id=138
http://www.stargroup.uwaterloo.ca/~ltahvild/courses/ECE750-11-S05/CBSS-Lecture10.pdf
http://www.eetkorea.com/ARTICLES/2004FEB/2004FEB02_ICD_EDA_TA.PDF?SOURCES=DOWNLOAD
http://www.omg.org/news/meetings/workshops/MDA-SOA-WS_Manual/02-3_Cummins.pdf
http://aswec07.cs.latrobe.edu.au/14.pdf
http://sunset.usc.edu/GSAW/gsaw2006/s4/hohwald.pdf
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/iccbss/2007/2785/00/2785toc.xml&DOI=10.1109/ICCBSS.2007.46
http://colab.cim3.net/file/work/SOACoP/2006_05_2324/CCasanave205222006.ppt
http://www.army.mil/armybtkc/test/sa/soa.htm

오래된 이야기..거버넌스가 힘들다. Cots에 대한 Integration은...

현재 몸으로 겪고 있음.

몇개월째..T.T

S/W Architecture

TeddyLee — Fri, 22 Jun 2007 14:14:27 +0900

※ 아키텍처는 소프트웨어 아키텍처를 뜻합니다.

최근 아키텍처에 대한 품질 평가를 하면서 몇몇 새로운 것들을 느끼고 있다.

엔지니어들이 느끼는 아키텍처란게 무얼까? 6년전에 만든 아키텍처 문서를 보면서 품질팀에서 아키텍처에 대한 품질을 검사 할 수 없음을 다시 한번 느끼고 있다.

아키텍트는 아키텍처의 품질 담당자이며 이로 인해 아키텍트가 책임을 지는 일은 상당히 크다라고 할 수 있다.

어떤 품질에 포커스를 하느냐에 따라 QA( Quality Attribute ) 의 느낌감도 (?) 는 상당히 다르다는 것이다.

어떤 이는 ATAM을 너무나 쉽게 거론하기도 한다.

최근 모 회사의 아키텍처 문서를 평가하면서 많은 것들을 느꼈는데… 최근에 제품위주(COTS) 의 아키텍처가 아키텍트들의 머리에 또 다른 사고를 만든다는 것도 알았다.

그러기 위해서는 COTS를 위한 아키텍처가 필요하며 이에 맞는 적절한 평가가 필요하다고 생각된다. 페이지수가 많거나 학구적이라고 해서 아키텍처 문서라고 하기엔 너무나 고리타분하고…. 외국서적에 나온 듯이 그대로 배낀 패턴이나 스타일로 뒤덮힌 아키텍처 문서도 난무하며… 정말 그런 문서들이 아키텍처 문서인지는 잘 모르겠다.

개발자입장에서 디자인패턴을 써놓는다고 해서 아키텍처라는 말을 붙이기엔 아키텍처라는 말이 너무나 광범위하고 어떤 면에서는 협소하다고 생각한다.

최근 몇 년간 SEI 에서 나온 시리즈 물을 몇 번 정독하고…

포사1.2를 쪼개고…

각종 Object문서를 봐도 봐도…

현장에서의 아키텍처문서엔 어떠한 면에선 현실적인 내용이 들어가긴 힘들다는 것이다.

그저 현학적인 문서들….. 책을 아무리 많이 봐도 익혀지지 않는 것들이 많은 것은

책의 장수만을 세거나 아니면 너무나 현학적인 책을 봐서 아닐까….. 반성해야 한다.

아키텍처 문서에는 이러한 것들이 들어있으면 좀더 많은 이해관계자들이 공감하기 좋을 것이다.

1.여러 이해관계자가 이해가 가능한 View를 가진 문서
2.비 전문가가 봐도 어느 정도 이해 가능한 합리적이고 쉬운 아키텍처 문서
3.회사나 집단의 아키텍처적인 의사평가를 내리는 과정이나 기술적인 평가를 위해 쓰이게 될 문서
4.회사의 아키텍처 전략 ( 품질속성 ) 을 내포하며 이를 지키기 위해서 어떠한 것들이 내재 되어야 하는지 어떠한 것들이 패턴화 되었는지 등등에 대한 문서, 이를 위한 대안이나 원칙, 정의 등이 포함된 문서
5.비즈니스와 기술을 연결하기 위해 최적의 메커니즘 효율성을 찾아내는 메커니즘적인 문서
6.기타 등등

하도 많아서 기술하기 힘들지만…. 대략 저러하다.

또다른 뷰에서 본다면 아키텍처 정의를 위한 문서들은 어려워서는 안되며 가장 쉬운 것으로 추상화되어 표현되어야 한다는거….

Relationship between SCA and BPEL

TeddyLee — Wed, 30 May 2007 09:51:56 +0900

http://www.osoa.org/display/Main/Relationship+between+SCA+and+BPEL

SCA and BPEL - Rivals or Friends?

Sometimes, when talking about composite service-based applications, people get confused about the roles of SCA and of BPEL and consider that these two technologies are in conflict or that they are trying to perform the same roles. This isn't the case - far from being rivals, SCA and BPEL are firm friends and are complementary parts of a business solution, each with its own role to play.

However, the similarities between SCA and BPEL show why there is the possibility for confusion. First, both BPEL and SCA are described in terms of a formal language that is based on XML. Secondly, both languages may be used to describe a business service that is implemented by composing together other business services and both can describe inbound and outbound service interactions types by WSDL port types. There the similarities end. The important difference between SCA and BPEL is that SCA is all about describing the structure of the application while BPEL describes business logic involving the sequencing of operations in a business process.

Putting this in another way, SCA is concerned with what components exist in the business application, what services those components offer, what service references those components depend on, how the components are connected together, what endpoint addresses and communication methods are used for the connections, what policies are applied to components and to the connections between them. BPEL is concerned with business logic and the sequences of operations which are performed to execute an individual business process. BPEL processes provide and consume other services through partnerLinks, but these are abstract interfaces that must be connected to actual endpoints and communication methods through configuration.

So, SCA describes the structure of a business solution in terms of business components and their connections, but the sequence in which particular services are invoked is determined by the business logic of the implementation used for each component. It is a good combination when the components are implemented as BPEL processes within an overall SCA assembly, since then it is possible to get a combined view of structure and sequence. Of course, SCA does not force this as a requirement and components may be implemented in any supported programming language, such as Java or C++. In this case, sequence decisions are made in the implementation language of the component and it may be harder to work out the sequences involved.

So, BPEL and SCA are the firmest of friends and work well together when building business solutions as sets of services. The following sections provide some details and some examples as to how this works in practice.

SCA and the Structure of Composite Applications

SCA is useful for describing the structure of composite service applications. To get a better sense of what this means, an example application is shown in the following diagram:

In this example, the Order Processing service is offered for use by customers, most likely as a Web service available over a general protocol such as SOAP over HTTP. This may have a set of operations such as "createOrder", "checkAvailability", "getOrderStatus" and so on.

The Order Processing service is implemented by the OrderProcessing Component. In turn, the OrderProcessing component makes use of services provided by other components, represented by the EventLog component, the AccountsComposite and the WarehouseComposite. The names of those components already indicate how they are implemented - EventLog is a simple implementation, for example a Java class, while AccountsComposite and WarehouseComposite are each a composite set of components which work together to provide the services used by the OrderProcessing component.

The OrderProcessing component does not need to know the structure of the AccountsComposite or the WarehouseComposite - but the assemblers and developers responsible for those parts of the solution certainly do!

So, SCA shows what components make up a particular business solution and it shows how they are connected together. SCA provides more information than this, if it is needed. For example, SCA knows what binding is used for each connection. The OrderProcessing component may, for example, connect to the PaymentService using an EJB binding, if the AccountsComposite is implemented as a Java EE application using EJBs. Meanwhile the OrderProcessing component might connect to the WarehouseService using a JMS binding using an underlying messaging infrastructure. SCA may also apply particular policies to these connections. For example, accounts information may be regarded as sensitive and so require that all operations on the PaymentService are encrypted. The same operations may also require authentication to ensure that only trusted users are invoking the operations. Meanwhile some of the operations on the WarehouseService, such as those involved in dispatching orders to the customer, must be performed transactionally and reliably, so that the OrderProcessing component can be assured that the order is dispatched once and once only.

What SCA does not do is in any way show the sequences of operations associated with the OrderProcessing service. So, the checking of the customer's account status, the checking of the inventory status of the order items, the calculation of the price of the order items, the billing of the customer, the request to dispatch the goods to the customer - all these operations (and more!) may be required to complete a "createOrder" operation, but their sequence is entirely determined by the code used as the implementation of the

CPIC - Capital Planning and Investment Control

TeddyLee — Fri, 18 May 2007 16:40:27 +0900

예산편성 & 투자관리 - IT 거버넌스에서의 투자 ROI에 대한 문서및 템플릿 Set

http://www.cit.nih.gov/home.asp
http://irm.cit.nih.gov/itmra/CPIC.html

CPIC의 세가지 요소

선정

-장기 투자 계획의 개발
-목표에 도달하기 위해 대안의 평가

-정보기술 자산 획득을 투자로 인식, 투자 관리방법 사용

-임원 검토 위원회를 구성하여 선정

-측정 가능한 목표와 성과 척도의 개발

통제
-통합 프로젝트 팀의 구성

-유용한 단위별로 예산 배정 (전체비용의초기결정)

-프로젝트 비용, 일정 및 성과의 추적 관리

평가
-구현 후 검토 실시

-현재 자산의 능력과 계획된 결과와의 차이 확인

OSOA - Service Component Architecture Specifications

TeddyLee — Thu, 10 May 2007 17:48:39 +0900

http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications

몇몇개를 읽어보고 있다. 직접 보기전엔 이해가 안갈지도....
최근 이해가 되기 시작했음 -.-
Z

IBM ESB 나름 좋음.

TeddyLee — Wed, 9 May 2007 14:33:40 +0900

http://www-128.ibm.com/developerworks/websphere/techjournal/0510_brent/0510_brent.html

Part 2: Assembling SCA components

Part 3: Integrating SCA modules with imports and exports

Part 4: Integrating with JMS and Web services

현 프로젝트에서 적용중 -.0- 그러나 난관은 있다.
내가 생각하는 SOA모델이 가장 잘 일치하는 것은 IBM의 SOA모델...
이 이야기를 좀 적어보까 ^^

어디부터 시작을 해야 이게... 적히게 될려나....
정치부터 해야 하나 -.T

UML2BPEL

TeddyLee — Wed, 9 May 2007 13:28:33 +0900

http://www.ibm.com/developerworks/kr/library/ws-uml2bpel/

요즈음 나는 ....

TeddyLee — Fri, 4 May 2007 20:02:16 +0900

1. 몸이 더 안좋아짐. 오늘은 회사를 쉬었음. 토비형을 보고 싶기도 했지만 도무지 보기가 힘든 상황
2. 최근엔 SOA의 SCA대해서 좀더 깊이 연구 하였음.
3. 스프링의 IoC에 대한 좀더 깊은 생각
4. 스프링의 컨트롤러에 대한 여러가지 생각을 하게 됨. - 내부 구조를 뜯다가 서블릿의 그 ( ? ) 구조가 생각나기도 했음. 그러나 스프링은 여전히 국내에서는 무력한 상태임. 참고로 스프링의 컨트롤러는 Servlet Controller는 아님.
5. 아침 스터디중 - TDD에 대한 또 다른 생각중
6. SQL Map - Abator 괘얀음. 그러나 유동성 없음. 조금 하다 보니 DAO를 생성해주는데 "SPRING" 으로 바꾸자 Spring의 JDBC Template를 이용해서 코딩이 Gen 되어 나옴 그런데 코드를 보고 약간 실망...T.T 자동 Gen의 한계가 아닐까라는 생각이 듬.
7. 제품에 대한 의존도및 이것들에 대한 유지보수에 대한 생각중 - 제품자체의 건강함을 위해서 코드는 간결하고 철학을 가져야 함. 내부적인 품질이 지켜지지 않은 모 회사의 제품은 철학도 없고... 사람힘들게 만드는 쓰레기 코드임이 틀림 없음. 이상...

걍 생각없이 읽어볼만한 pdf 임

attach[1].pdf

갑자기 S모 회사의 Nasa표준이 생각나는군...끌

TeddyLee — Wed, 2 May 2007 09:15:40 +0900

http://andrei.gmxhome.de/jdepend4eclipse/links.html
http://classpathhelper.sourceforge.net/

의존도 검사중 ^^

Spring SCA

TeddyLee — Tue, 24 Apr 2007 09:20:30 +0900

http://forum.springframework.org/showthread.php?t=21050

http://www.osoa.org/display/Main/SCA+and+Spring+Framework

http://www.osoa.org/download/attachments/35/SCA_SpringComponentImplementationSpecification-V100.pdf?version=1

http://phillyspring.org/spring-and-bea.pdf : spring weblogic SCA 결합
멋지다. Spring SCA

LifeRay도 버전이 올라가면서 여러가지 기술이 도입 되었네...

TeddyLee — Sun, 22 Apr 2007 23:41:39 +0900

[Flash] http://www.liferay.com/c/document_library/get_file?folderId=65&name=home_4_2_530x190.swf

http://content.liferay.com/4.0.0/flash/tutorials/liferay_demo.swf

END USER를 위한 다큐먼팅 ^^
http://www.liferay.com/web/guest/documentation/4_2/end_users

오래전 LifeRay기사를 내면서 많이 고생했던 기억이 난다.
별안간 분석을 하게 되어서 많이 힘들었다. 그때 토비형이 많이 도움 줬던 기억이 생생히 난다.
많은 사람들이 외면했던 것도 기억이 난다.T.T
열심히 분석했더니...기술은 괘얀은듯 했으나 코드는 엉망였다. 꼬리에 꼬리를 무는 구조...

다만 포틀릿 엔진을 자체 제작 했었다는게 조금 신기 했다. 문서를 자세히 보면 많은 부분에서
포틀릿에 대한 구현이 된것이 보인다.
오래 되었지만...기억상으로는 이 LifeRay는 코드상 재귀 호출을 하고 있었던것으로 보였었다.
기억이 가물가물....T.T
http://toby.epril.com/?s=liferay
참조... ^^

SOA를 위한 Portal로서의 기능을 갖추기 위해 JBI스팩의 ServiceMix의 연동을 도입하였고...
JBPM등을 도입하였다. 이렇게 되면 어느정도 기술적으로는 SOA를 위한 기술들을 갖추었지만...
SOA는 기술로만 되는게 아니지 않더냐...T.T 수많은 아키텍처적인 고민을 통해 SOA의
철학이 완성되지만 아직도 많은 고민이 필요하다.

http://www.liferay.com/web/guest/products/portal/supported_technologies
위의 링크와 같은 기술들이 쓰였다.

분석 당시 아래의 아키텍처때문에 분석을 하게 되었었다. 그것이 가지는 절대적인 미학을 위해 분석을 하게 된것이다.... 그런데 약간은 실망....T.T
얼마나 유연한 구조를 제공하느냐는.... 그런 이유였었다...
그때 당시 나의 가장큰 기술적인 이슈는 당연히 Spring, Hibernate 였다. 많은 레퍼런스가 필요하던 차에
LifeRay는 나게에 빛과 같이 중요한 Portal Framework였다.
얼마전 Portal에 대한 자료를 보다가 문득 생각이 났다.
최근 기업에서도 SOA프로젝트를 한다고 하면 Portal이 빠지지 않고 나온다....

사용자에게 기술이 무슨 상관이 있으랴.... 사용자는 편리하기만 하면 된다.
그러한 이유에서인지...사용자 위주의 Ajax가 도입된것도 많은 발전이 있어 보인다. 그러나...T.T
소스코드의 정제는 없었다는거.... 여전히 같은 아키텍처라는게 맘에 걸린다. ㅋ

다른 서버의 이식성에서는 높은 점수를 주고 싶었다. EJB, Non EJB방식의 지원등이 그러하였고...
500여개의 Client site에 이식하면서 많은 노하우를 쌓은듯...

Application Servers

BES		Borland ES 6.5
GER		Apache Geronimo 1.1
GLF		Sun GlassFish 2.0 M2
JB		JBoss 4.0.3SP1, 4.0.4, 4.0.5
JFX		JFox
JON		JOnAS 4.4.3, 4.7.7
JR		JRun 4 Updater 3
O		OracleAS 10.1.3
ORI		Orion 2.0.6
P		Pramati 4.1
REX		RexIP 2.5
SUN		Sun JSAS 8.01
WL		WebLogic 8.1 SP4, 9.2
WS		Websphere 5.1, 6.0.x

Servlet Containers

JET		Jetty 5.1.4
RES		Resin 3.0.14
TOM		Tomcat 5.0.x/5.5.x

AIX

BSD

Linux

Solaris

Windows

Mac OS X

Databases

AD		Apache Derby
DB2		IBM DB2
FIRE		Firebird
HYP		Hypersonic
INT		InterBase
JDS		JDataStore
MY		MySQL
O		Oracle
PSQL		PostgresSQL
SAP		SAP
SQL		SQL Server

분석당시 많은 불만이 많았던...다큐먼팅은 많이 개선되었지만...아직도...T.T
그러나 문서화면에서는 정말 많은 개선이 있는게 틀림없다.
http://www.liferay.com/web/guest/documentation

PS : LifeRay Portal의 Demo를 볼수도 있지만... 직접 설치함을 권장함....
사이트 접속 매우 느림...T.T

오랜만에 글을 써서 두서도 없고 정신도 없다는.... 보실분은 알아서 보실듯....T.T
내일부터는 출퇴근하면서...TDD를 다시 연마 해야겠다는....
흠.... 할게 많다. 말뿐인 아키텍트라는 말 안들으려면.... 할것도 많고... 볼것도 많고...
여러가지 꾸준히 관심도 가져야 하고....

많은 사람들도 알겠지만... 아키텍처가 어디 기술만 가지고 되더냐....
가끔 기술베이스의 아키텍트를 보기도 하지만.... 기술이라는 거는 언젠가는
후배들이 차지하게 될텐데.... 게다가 기술은 끊임없이 빠르게 변한다.
또한 경험이 많아야 아키텍트로서 살아 남지 않을까 싶다.
어떤 아키텍트는 프레임워크 검증을 하라고 하면 어떤 사람들은 게시판을 만든다.
그걸로 검증이 될까 ??

아키텍트는 두마리의 토끼를 잡아야 한다. 기술, 비지니스.....
기술과 비지니스를 결합하는게 S/W 아키텍트라고 말하고 싶다.

주인장 이메일 입니다. 연락하실분은 ^^

TeddyLee — Thu, 19 Apr 2007 16:58:11 +0900

//잘써먹고 있다. 친구들한테 이멜 보낼때...ㅋㅋㅋ

// 나와 대화하려면 이거 받으셔야... 제 이메일은 bG92ZUxhenVyQGdtYWlsLmNvbQ==
// 연락주세요 ^^

ISO 9126 QA

TeddyLee — Mon, 16 Apr 2007 11:15:36 +0900

http://en.wikipedia.org/wiki/ISO_9126
click1
click2
click3

98-147.zip

ISO 9126 QA
열심히 레포팅중... ^^

Functionality - A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.
Reliability - A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.
Usability - A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users.
Efficiency - A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.
Maintainability - A set of attributes that bear on the effort needed to make specified modifications.
Portability - A set of attributes that bear on the ability of software to be transferred from one environment to another.

상세도 있음. ^^

회사 집을 오가는 나의 생활

TeddyLee — Sun, 15 Apr 2007 23:58:40 +0900

현 프로젝트는 SOA프로젝트 ....
컨설팅 기간도 엄청길고.... 최근 몇년간 차세대 프로젝트의 아키텍트로 일하면서
별별 일을 다 겪었다. 결론... 사람이 기술이나 비지니스 보다 우선하며 사람다음엔 비지니스 그다음엔 기술 순이었다. 그리고 로비는 가장 마지막이 되어가고 있다.
상위레벨에서의 기술은 그져 비지니스를 충족하기 위한 무언가 일 뿐인 경우라고 생각하는 경영자가 많다.
그런 갭을 줄이는게 나의 일이다.

최근 1-2개월간 집과 회사만을 오가며 일을 하고 있다. 몸이 많이 망가진거 같다.
대규모 프로젝트이기도 하고...할일도 많고....
특히 생각해야 할 것들이 많고 보고서와 분석 레포트가 많아 지고 있다.
보고서와 분석 레포트 많아지면 일이 힘들어 지던데.... 거버넌스 혹은 무언가 부족한 상태인 것으로 보인다.

여러가지 아키텍처 유형과 내가 가지고 있는 비지니스, 그리고 기술, 컨설팅 기법등에 있어 많은 충돌이 있었다.
하나 크게 깨달은건 언제나 거버넌스는 중요하다라는 것이다.

누가 이야기 했지..거버넌스 답없다고...그러나 답없지 않다고 생각한다.
나의 비지니스가 성공해야 할텐데... 걱정도 많다.

최근 나의 비지니스는 2가지로 일축된다.
- 회사 - 혁신이 필요하다. 회사 그리고 나....
- 투자 - 투자의 경우 많은 혁신이 있었다. 매년 아무런 노력없이 부동산을 제외하고...
1500~1000만원의 수익이 들어오고 있다.

그러나 집에는 내가 자리를 비운사이 우리 와이프가 많이 외로워하고 있었다. 이제 그 자리 채워야 하는데
이만저만한 노력으로 되는게 아니다. 가정을 못지키는 상태에서 기업의 컨설팅이라니.... 여전히 반성중....

여러 측면에서 회사의 관점에서 볼때 경영적인 기법이 필요할때가 아닌가 생각된다.
좀더 객관적인 시각에서 사물을 바라봐야 할 시간인듯...

며칠전 몇몇 후루꾸 ( ? ) 컨설턴트들을 만났다. 그들과의 2시간동안의 대화를 하면서
그들에게 컨설턴트라는 이름을 붙인 그 회사...
양심도 없다 라는 생각이 든다.

PS : 연동을 위해서 가장먼저 해야 할것은 BA, AA이다. BA, AA에서 연동이 시작된다라고 생각이 든다.
여전히 아침엔 한손엔 책을 들고 저녁엔 서브 노트북으로 자료를 보면서 출퇴근을 한다. 하루가 24시간이 아니라 48시간이었으면 좋겠다.T.T