뚜벅이개발돌이

(1) Static SQL

• Static SQL이란, String형 변수에 담지 않고 코드 사이에 직접 기술한 SQL문을 말합니다.
  
   

(2) Dynamic SQL

• Dynamic SQL이란, String형 변수에 담아서 기술하는 SQL문을 말합니다.
  String 변수를 사용하므로 조건에 따라 SQL문을 동적으로 바꿀 수 있고, 또는 런타임 시에 사용자로부터 SQL문의 일부 또는 전부를 입력 받아서 실행할 수도 있습니다.
  따라서 [PreCompile] 시 Syntax, Semantics 체크가 불가능 합니다.
• Dynamic SQL을 만나면 [PreCompiler]는 그 내용을 확인하지 않고 그대로 통과시킵니다.
  Pro*C환경에서 개발해 본 독자라면 스칼라 서브쿼리, 분석 함수, ANSI 조인문 등을 사용했을 때 [PreComile] 과정에서 에러가 나는 경험을 했을 것입니다.
  Semantic 체크는 DB 접속을 통해 이루어지지만 Syntax 체크만큼은 [PreCompiler]에 내장되 SQL 파서를 이용하는데, 위 구문들을 사용하면 현재 사용 중인 [PreCompiler]가 그것들을 인식하지 못해 에러를 던지는 것입니다.

그럼 XA DataSource가 무엇인지를 설명하면 되는데, XA는 2PC(2 phase commit)을 통한 분산 트렌젝션
처리를 위한 X-Open에서 명시한 표준입니다. 예를 들어 Oracle데이타베이스와 IBM DB2 데이타베이스간에
2단계검증을 통한 2PC를 보장하여 트렌젝션을 보장시켜주는 것이지요. 비단 데이타베이스에 국한되지
않습니다. WAS의 트렌젝션 서비스를 통해 TUXEDO(via WTC)와 Oracle 데이타베이스, IBM MQ와 Sybase DB등
이기종 Resource Manager간에 트렌젝션이 보장되는 것이지요.

트렌젝션이 보장된다 함은 각각이 모두 commit되었을 때만이 전체가 commit되며 하나라도 rollback되면
모두가 rollback되어야 한다는 것을 의미합니다.

그럼 언제 XA DataSource를 사용하고, 언제 Non-XA DataSource(ConnectionPoolDataSource)를 사용해야
할까요? 현재 등록된 하나 이상의 (혹은 이기종) 데이타베이스간에 2pc 트렌젝션이 보장되어야 할 때
XA DataSource를 사용하시면 되고, 설령 하나 이상이 데이타베이스를 접근하더라도, 굳이 트렌젝션이
보장되어할 필요성이 없다면 Non-XA DataSource로 등록하여 사용하시면 됩니다.

일반적으로 XA DataSource는 데이타를 정합성 및 2pc를 위해 file lock이나, 그 외의 적절한
메카니즘(예를 들어 WAS가 다운되더라도 2pc는 보장되어야 하며, 갑작스런 down시에도 적절한
트렌젝션 리커버리를 위한 메카니즘)을 보장하기위한 기능이 들어있기에 Non-XA에 비해 성능이
느립니다. 따라서, 2PC를 사용할 경우의 최대의 관건은 가능한 빨리 리소스에 대한 commit/rollback과
자원의 반납등이 중요하며, 성능의 확장성과 반대방향(?)이므로 충분한 고려를 필요로 합니다.

NOTE: 웹스피어의 경우 같은 데이타베이스를 향하는 데이타소스일지라도, 등록된 데이타소스의 이름, 
아이디 및 프라퍼티가 모두 동일해야 2PC로 승격되지 않습니다.

SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 사용하여 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 형태의 프로토콜이다. SOAP은 웹 서비스(Web Service)에서 기본적인 메시지를 전달하는 기반이 된다. SOAP에는 몇가지 형태의 메시지 패턴이 있지만, 보통의 경우 원격 프로시져 호출(Remote Procedure Call:RPC) 패턴으로, 네트워크 노드(클라이언트)에서 다른 쪽 노드(서버)쪽으로 메시지를 요청 하고, 서버는 메시지를 즉시 응답하게 된다. SOAP는 XML-RPC와 WDDX에서 envelope/header/body로 이루어진 구조와 전송(transport)와 상호 중립성(interaction neutrality)의 개념을 가져왔다.

장점

• SOAP를 사용한 HTTP는 기존 원격 기술들에 비해서 프록시와 방화벽에 구애받지 않고 쉽게 통신 가능하다.
• SOAP는 융통성있게도 각각 다른 트랜스포트 프로토콜들의 사용을 허용하고 있다. 표준 스택에서는 트랜스 포트 프로토콜로 HTTP를 사용하지만, 다른 프로토콜 역시 사용가능 하다.
• SOAP는 플랫폼 독립적이다.
• SOAP는 프로그래밍 언어에 독립적이다.
• SOAP 간단하고, 확장가능하다.

단점

• XML 포맷은 태그 형태로 보내기 때문에 CORBA같은 미들웨어 기술과 비교해서 상대적으로 느리다. 이것은 전송할 메시지가 적을때에는 문제 되지 않을 수 있다. 성능을 향상시키기 위해서 바이너리 객체를 포함시킨 특별한 경우의 XML(바이너리 XML을 말하는듯)로 메시지 전송 최적화 메커니즘(Message Transmission Optimization Mechanism; MTOM)이 나왔다. 게다가 일반적인 XML의 성능을 향상시키기 위해, VTD-XML과 같은 emerging non-extractiv XML 처리 모델이 있다.

SOAP 샘플

 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Body>
     <getProductDetails xmlns="http://warehouse.example.com/ws">
       <productId>827635</productId>
     </getProductDetails>
   </SOAP-ENV:Body>
 </SOAP-ENV:Envelope>

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 그는 하이퍼텍스트 전송 프로토콜(HTTP)의 주요 저자들 가운데 한 사람이다. 그 뒤로 이 개념은 네트워킹 문화에 널리 퍼졌다.

엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 네트워크 아키텍처 원리란 리소스를 정의하고 리소스에 대한 주소를 지정하는 방법에 대한 개괄을 말한다. 간단한 의미로는, 도메인 지향 데이터를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 부가적인 전송 레이어 없이, 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 당연히 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP 프로토콜을 사용하지 않은 채로 또 월드 와이드 웹에서 전송하지 않고도 아주 커다란 소프트웨어 시스템을 설계하는것도 가능하다. 또한, 리모트 프로시저 콜을 이용하는 대신에 간단한 XML과 HTTP 인터페이스(REST 원리에 부합하지는 않지만)를 이용해 설계하는 것도 가능하다. 현실 세계에서의 REST 용어에 대한 이러한 두 가지 의미는 기술 토론에서 종종 혼란을 야기한다.

필딩의 REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다. 열정적인 REST 옹호자들은 스스로를 RESTafrians 이라고 부른다.

• 리소스의 구별
  • 개별적인 리소스는 요청에서 구별된다 - 웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있다. 리소스 그 자체는 클라이언트로 리턴되는 representation으로부터 개념적으로 분리되어 있다. 예를 들어, 서버는 그 데이터베이스를 전송하지 않는다, 단지 아마 어떤 데이터베이스 레코드를 나타내는 HTML, XML이나 JSON 등이 요청에서 구체적으로 요구되거나 서버의 구현에 따라서 예를 들어, 프랑스 어로, UTF-8로 인코딩되어 보내질 것이다.
• 이들 representation을 통한 리소스의 조작
  • 클라이언트가 어떤 메타데이터가 첨부된 상태로 어떤 리소스의 representation을 가지고 있을 때, 만약 승인이 있다면, 서버에 있는 그 리소스를 변경 또는 삭제할 수 있는 충분한 정보를 가지고 있는 것이다.
• 자기-서술적 메시지
  • 각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다 - 예를 들어 어떤 파서를 불러야 하는지. 그 한 예는 MIME type과 같은 인터넷 미디어 타입의 사용을 들 수 있다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기-서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 코드 다운로드가 사용되지 않으면, 그 내용을 가지고 무엇을 해야할지에 대해 충분히 알려주지 못한다.
• 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어
  • 만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 representation에서 구별될 수 있어야 한다. 충분한 컨텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.

HTML5 is not just about making existing markup shorter (although it does a fair amount of that). It also defines new semantic elements.

<section>

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading. Examples of sections would be chapters, the tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site's home page could be split into sections for an introduction, news items, contact information.

<nav>

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to common pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element.

<article>

The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a Web log entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

<aside>

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography. The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

<hgroup>

The hgroup element represents the heading of a section. The element is used to group a set of h1–h6elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.

<header>

The header element represents a group of introductory or navigational aids. A header element is intended to usually contain the section’s heading (an h1–h6 element or an hgroup element), but this is not required. Theheader element can also be used to wrap a section’s table of contents, a search form, or any relevant logos.

<footer>

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like. Footers don’t necessarily have to appear at the end of a section, though they usually do. When the footer element contains entire sections, they represent appendices, indexes, long colophons, verbose license agreements, and other such content.

<time>

The time element represents either a time on a 24 hour clock, or a precise date in the proleptic Gregorian calendar, optionally with a time and a time-zone offset.

<mark>

The mark element represents a run of text in one document marked or highlighted for reference purposes.

자주 보게 되는 Code

200 OK

403 Forbidden

404 Not Found 

500 Internal Server Error 

505 HTTP Version Not Supported