#PARAN SILVERLIGHT#
  • Tistory
    • 관리자
    • 글쓰기
Carousel 01
Carousel 02
Previous Next

'B2B'에 해당되는 글 14건

  • 2009.04.10 [Web Service] UDDI / WSDL / SOAP
  • 2009.04.10 JMS(Java Message Service)
  • 2009.03.31 Webmethods Architecture
  • 2009.03.31 BPM Architecture for Webmethods 7.1
  • 2009.03.31 DUNS Number
  • 2009.03.31 webMethods
  • 2009.03.27 MIME (Multipurpose Internet Mail Extensions)
  • 2009.03.27 RosettaNet PIPs
  • 2009.03.27 RNIF(RosettaNet Implementation Framework)
  • 2009.03.27 Web service

[Web Service] UDDI / WSDL / SOAP

B2B 2009. 4. 10. 09:23

UDDI (Universal Description, Discovery and Integration)

  • 웹 서비스의 Publish와 Find를 위한 XML 레지스트리 구현 및 사용 방법을 표준화
  • 웹 서비스 Broker가 운영할 XML 레지스트리 운영 방법에 대해 정의
  • 웹 서비스 Provider가 제공할 웹서비스 공개 방법에 대해 정의

WSDL (Web Service Description Language)

  • 웹 서비스의 인터페이스를 기술하는 XML 표현 방법을 표준화
  • 웹 서비스의 원격 프로시저를 이용하기 위한 argument, method, return 등을 기술하는 방법 정의
  • 웹 서비스 Consumer가 WDSL을 해석하여 binding 방법을 확인

SOAP (Simple Object Access Protocol)

  • 클라이언트와 서비스간의 정보 교환의 구조를 표준화
  • XML 문서 형태로 전송 프로토콜을 이용하여 전송하는 방법에 대해 정의

 

[출처] [Web Service] 스펙 3종 세트 UDDI / WSDL / SOAP|작성자 밤바


저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

JMS(Java Message Service)

B2B/WEBMETHODS 2009. 4. 10. 09:10


JMS(Java Message Service)

메시징 시스템은 응용프로그램 간에 비동기적으로 메시지를 교환할 수 있는 방법을 제공해준다.

비즈니스에서 메시징 서비스를 이용하려면 MOM(Message Oriented Middleware)가 필요하다.

MOM은 메시지를 전달할 수 있으며, 메시지 전달을 비동기적으로 처리할 수 있는 특징이 있는 시스템이다.

JMS는 각 회사에서 만든 MOM 시스템의 공통적인 부분을 표준화함으로써 공통된 API를 사용할 수 있게 한다.

웹로직 서버는 MOM 기능을 제공한다.

메시징 서비스를 이용함으로써 얻을 수 있는 장점으로는 통신이 비동기적으로 이뤄지기 때문에 클라이언트에서는 작업 여러 개를 기다릴 필요 없이 처리할 수 있다는 것이다.

 

메시징 서비스는 다음과 같은 종류의 서비스를 제공한다.

 

P2P(Peer to Peer)

여러 개의 클라이언트(메시지 센더)에서 보낸 메시지를 MOM의 메시지 큐(Message Queue)에 차례대로 저장한 후, 메시지 리시버(Message Receiver)가 큐의 내용을 하나씩 읽어 들여 처리할 수 있는 방식을 말한다. 메시지 큐는 메시지 리시버가 메시지를 읽어갈 때까지, 혹은 유효 시간이 경과되기 전까지 메시지를 저장하게 된다.

 

Pub/sub

발행자/가입자의 약자이다.

메시지 센더에서 메시지를 MOM에게 전달(출판)하면, 주제에 등록된 클라이언트에게 메시지가 전달(구독)되는 방식을 말한다.

 

JMS란

MOM을 공통적으로 이용하기 위한 API

JMS API를 이용하기 위해서는 JMS명세를 알아야 한다.

JMS 명세에 따르면 JMS를 이용하는 응용 프로그램은 다음과 같은 요소로 구성된다.

각각의 요소는 API에서 제공하는 객체가 될 수도 있으며 어떤 부분은 응용 프로그램일 수 있다.

 

운영도구(Administrative Tool)

커넥션 팩토리(Connection Factories)

목적지(Destinations)

커넥션(Connection)

세션(Session)

메시지 생산자(Message Producer)

메시지 소비자(Message consumer)

메시지(Message)

 

운영도구

MOM을 이용해서 P2P나 pub/sub 방식으로 메시지를 전달하고 메시지를 전달 받기 위한 API는 JM

S에서 제공하지만 MOM 자체를 관리하기 위한 방법은 JMS에서 제공하지 않는다. 그렇기 때문에 MOM을 운영하려면 MOM에서 제공하는 운영도구를 사용해야 한다.

웹로직 서버는 MOM을 포함한다고 했는데, 포함된 MOM을 사용하려면 웹로직 서버에서 제공하는 기능을 이용해야 한다. MOM을 운영한다는 것은 목적지(destination)를 설정하기 위해서다

목적지라는 것은 P2P나 pub/sub 방식으로 메시지를 주고 받을 때 사용하기 위한 저장 공간이라고 생각하면 된다.

 

커넥션 팩토리

커넥션과 관련된 정보를 통해서 커넥션을 생성할 수 있는 인터페이스를 말한다.

클라이언트는 JNDI를 이용하여 커넥션 팩토리(Connection Factory)를 검색한 후 JMS 커넥션을 만들게 되는데, P2P 방식일 경우에는 javax.jms.QueueConnectionFactory를 사용하며, pub/sub 방식일 경우에는 javax.jms.TopicConnectionFactory 를  사용한다.

웹로직 서버는 weblogic.jms.ConnectionFactory 이라는 이름으로 커넥션 팩토리를 제공하기 때문에, 원하는 형태로 형식을 변환하여 사용해야 한다.

 

목적지

웹로직 콘솔에서 운영도구를 이용해서 목적지를 생성하고 JNDI에 이름을 등록하게 된다.

그러면 메시지를 MOM 에게 전송하면 목적지에 메시지가 전달된다.

 

커넥션

커넥션은 JMS 서비스 제공자와 클라이언트 간의 TCP/IP 커넥션을 의미하며, 세션을 생성하기 위해 사용된다.

커넥션을 생성하려면 커넥션 팩토리에 있는 createQueueConnection() 이나 createTopicConnection() 메소드를 호출해야 한다.

처음 커넥션이 생성되면 정지모드에 있으며, 정지 모드일 경우에는 메시지를 전달할 수만 있고 받을 수는 없다. 정지 모드에서 시작모드로 바꾸려면 Connection의 start()메소드를 사용하고, 반대로 다시 정지하려면 stop()메소드를 이용한다.

그리고 커넥션의 사용이 끝났다면 반드시 close()메소드를 호출해야 한다

 

세션

세션은 클라이언트와 JMS서버 간에 메시지를 생성하고 소비하기 위한 단일 스레드 환경이다.

P2P방식에서는 javax.jms.QueueSession을 pub/sub방식에서는 javax.jms.TopicSession을 사용한다.

 

메시지 생산자

클라이언트에서 메시지를 JMS서버에 전달하려면 메시지 생산자(Message Producer)을 이용해야 한다.

메시지 생산자는 세션을 통해서 만들어 질 수 있다. P2P 방식일 경우에는 QueueSender를, pub/sub 방식일 경우에는 TopicPublisher를 통해서 생성한다.

이렇게 생산된 메시지 생산자를 이용해서, P2P방식일 경우에는 QueueSender에 포함된 send()메소드를 통해서, pub/sub 방식을 경우에는 TopicPublisher에 있는 publish()메소드를 이용해서 메시지를 전달 할 수 있다.

 

메시지 소비자

클라이언트는 JMS 서버로부터 메시지를 받아들이기 위해서 메시지 소비자(Message Consumer)를 이용해야 한다.

메시지 소비자는 생산자와 마찬가지로 세션을 통해서 만들어질 수 있다. P2P방식을 경우에는 QueueReceiver를, pub/sub방식일 경우에는 TopicSubscriber를 통해서 생성한다.

이렇게 생성된 메시지 소비자를 이용해서 메시지를 받아들일 수 있는데, 두 가지 모두 receive()메소드를 이용해서 받아들인다.

메시지를 받아들이려면 반드시 커넥션을 start()한 상태이어야 하며, pub/sub 방식일 경우에는 비동기식으로 받아들이기 위해서 MessageListener 인터페이스를 구현한 후 TopicSubscriber에 있는

setMessageListener()에 등록하면 된다.

 

메시지

메시지는 메시지  생산자와 소비자 간에 교환되는 데이터를 말한다.

메시지는 헤더(header), 특성(property), 몸체(body)로 구성되어 있으며 어떠한 데이터라도 몸체에 담겨 전송할 수 있다.

메시지의 종류는 다음과 같다.

 

메시지

설명

TextMessage

문자열 데이터

MapMessage

이름과 값으로 구성된 데이터,이름은 String, 내용은 자바 기본형

BytesMessage

바이트 스트림 데이터

StreamMessage

자바 기본형 데이터들에 대한 스트림

ObjectMessage

자바 직렬화 객체

Message

TextMessage,MapMessage,BytesMessage,StreamMessage,ObjectMessage의 상위 인터페이스로 몸체가 없다.

 

P2P 방식의 메시징 서비스 예제

P2P방식의 JMS 예제 프로그램 테스트

순서

1.       웹로직 콘솔을 이용해서 사용할 목적지를 생성한다.

2.       커넥션,세션,메시지 생산자, 메시지 객체를 이용한 메시지 전송 프로그램을 작성한다.

3.       메시지 전송 프로그램을 여러 번 실행한다.

4.       커넥션,세션,메시지 소비자, 메시지 객체를 이용해서 MOM 의 목적지에 저장된 메시지를 읽어 들여 출력하는 프로그램을 작성한다.

5.       메시지를 읽어 들이는 프로그램을 실행해서 저장된 내용을 읽어서 출력하는지 확인한다.

 

목적지 생성

 

1. 웹로직 콘솔에 로그인한 후 좌측 메뉴에서 Services -> JMS ->Store 을 선택한 후 우측 메뉴에서

Configure a new JMS File Store 를 클릭한다.

JMS 서버는 메시지를 저장할 공간이 필요한데, 저장할 공간으로 파일시스템을 이용하는 것이다.

 

2. mydomain 디렉토리 아래에 파일 스토어가 사용할 디렉토리를 생성한다.

여기서는 myjmsfilestore 이라는 디렉토리를 만든다.

 

3. 파일 스토어에 대한 환경을 설정한다.

디렉토리명 : myjmsfilestore

파일스토어명: MyJMSFileStore

나머지는 기본값으로 하고 create 버튼을 클릭한다.

 

4. Apply 버튼을 클릭한다.

 

5. 파일 스토어를 생성했다면 해당 파일 스토어를 사용하는 새로운 JMS 서버에 대한 환경을 설정해야 한다.

좌측의 항목 중 Services ->JMS ->Servers 항목을 선택한 후 우측메뉴의 Configure a new JMS Server 항목을 클릭한다.

 

6. JMS 서버 설정화면에서

서버명 : MyJMSFileStore

나머지는 기본값으로 나두고 create 버튼을 클릭한다.

 

7. JMS 서버에 대한 환경 설정이 끝나면 Target and Deploy 탭에서 Target 을 myserver로 지정한 후

Apply 버튼을 클릭한다.

 

8. 서버에 대한 설정이 끝나면 목적지를 생성해야 한다. Services ->JMS->Servers->Destinations 항목을 선택한다.

 

9. 우측메뉴에서 Configure a new JMS Queue 를 클릭한다.

 

10. JMS Queue 에 대한 설정 화면이 나오면

Name : MyJMSQueue

JNDI Name : jmsqueue

로 지정한다.

 

11. 새로운 JMS 큐에 대한 설정이 끝나면 좌측메뉴에서 MyJMSQueue 라는 이름의 JMS 큐가 생성된 것을 확인 할 수 있다.

새로운 환경을 적용하기 위해서 웹로직 서버를 재시작 한다.

 

메시지 전송 프로그램 작성

JMS서버로 전송하기 위한 MessageQueueSender.java 파일을 작성한다.

 

import java.io.*;

import javax.jms.*;

import javax.naming.*;

import java.util.Properties;

public class MessageQueueSender {

             public static void main(String args[]) {

                          if(args.length != 1){

                                       System.out.println("사용법 : java MessageQueueSender 전송할 메시지");

                                       System.exit(0);

                          }

                          try             {

                                       Properties h = new Properties();

                                       h.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");

                                       h.put(Context.PROVIDER_URL, "t3://localhost:7001");

 

                                       Context ctx = new InitialContext(h);

                                       QueueConnectionFactory factory = (QueueConnectionFactory)ctx.lookup("weblogic.jms.ConnectionFactory");

                                       Queue queue = (Queue)ctx.lookup("jmsqueue");

                                       QueueConnection con = factory.createQueueConnection();

                                       QueueSession session = con.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);

                                       QueueSender qsender = session.createSender(queue);

                                       TextMessage message = session.createTextMessage();

                                       message.setText(args[0]);

                                       qsender.send(message);

                                       qsender.send(session.createMessage());

                                       con.close();

                          }catch(Exception ex){

                                       System.out.println(ex);

                          }

             }

}

 

메시지 출력 프로그램 작성

JMS 서버로부터 메시지를 전달받기 위한 MessageQueueReceiver.java 파일을 작성한다.

 

import java.io.*;

import javax.jms.*;

import javax.naming.*;

import java.util.Properties;

public class MessageQueueReceiver {

             public static void main(String args[]){

                          try{

                                       Properties h = new Properties();

                                       h.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");

                                       h.put(Context.PROVIDER_URL,"t3://localhost:7001");

 

                                       Context ctx = new InitialContext(h);

                                       QueueConnectionFactory factory = (QueueConnectionFactory)ctx.lookup("weblogic.jms.ConnectionFactory");

                                       Queue queue = (Queue)ctx.lookup("jmsqueue");

                                       QueueConnection con = factory.createQueueConnection();

                                       QueueSession session = con.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);

                                       QueueReceiver qreceiver = session.createReceiver(queue);

                                       con.start();

                                       while(true){

                                                    Message msg = qreceiver.receive(1);

                                                    if(msg != null){

                                                                 if(msg instanceof TextMessage) {

                                                                              TextMessage tmpMsg = (TextMessage)msg;

                                                                              System.out.println("읽어온 메시지: " + tmpMsg.getText());

                                                                 }

                                                    }else

                                                                 break;

                                       }

                                       con.close();

                          }catch(Exception ex){

                                       System.out.println(ex);

                          }

             }

}

 

프로그램 실행과 테스트

MessageQueueSender를 여러 번 실행하고 난 후, MessageQueueReceiver 를 실행한다.

MessageQueueReceiver가 MOM에 저장된 메시지를 출력하는지 확인한다.

 

pub/sub 방식의 메시징 서비스 예제

 

pub/sub 방식의 JMS 예제 프로그램의 작성 순서

1.       웹로직 콘솔을 이용해서 사용할 목적지 생성

2.       커넥션, 세션, 토픽 구독자, 메시지 객체를 이용해서 지정한 목적지로부터 메시지를 읽어오는 프로그램 작성

3.       메시지를 읽어 오기 위한 프로그램 2개 이상 실행

4.       커넥션, 세션, 토픽 발행자, 메시지 객체를 이용해서 MOM 의 목적지에 메시지를 발행하는 프로그램 작성

5.       메시지를 전송(발행)하기 위한 프로그램 실행

6.       메시지를 읽어오기 위해서 대기하고 있던 프로그램 2개 이상이 발행된 메시지를 읽어 출력하는지 확인

 

목적지 생성

1. pub/sub 방식을 이용하려면 먼저 웹로직 콘솔에서 토픽에 대한 목적지를 생성해야 한다.

MyJMSServer 아래의 Destinations 메뉴를 선택한 후 Configure a new JMS Topic 을 클릭한다.

 

2. JMS 토픽 목적지에 대한 설정을 한다. 이름은 MyJMSTopic, JNDI 명은 jmstopic 으로 지정한 후 create 버튼을 클릭한다.

 

메시지 전송 프로그램 작성

JMS서버로부터 비동기적으로 메시지를 읽어 들이는 MessageTopicSubscriber.java 파일을 작성한다.

 

import java.io.*;

import javax.jms.*;

import javax.naming.*;

import java.util.Properties;

 

public class MessageTopicSubscriber {

             public static void main(String args[]){

                          try{

                                       Properties h = new Properties();

                                       h.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");

                                       h.put(Context.PROVIDER_URL,"t3://localhost:7001");

 

                                       Context ctx = new InitialContext(h);

                                       TopicConnectionFactory factory = (TopicConnectionFactory)ctx.lookup("weblogic.jms.ConnectionFactory");

                                       Topic topic = (Topic)ctx.lookup("jmstopic");

                                       TopicConnection con = factory.createTopicConnection();

                                       TopicSession session = con.createTopicSession(false,Session.AUTO_ACKNOWLEDGE);

                                       TopicSubscriber subscriber = session.createSubscriber(topic);

                                       subscriber.setMessageListener(new MessageListener(){

                                                    public void onMessage(Message message){

                                                                 try{

                                                                              if(message instanceof TextMessage){

                                                                                           TextMessage m = (TextMessage)message;

                                                                                           System.out.println(m.getText());

                                                                              }

                                                                 }catch(Exception e){

                                                                              System.out.println(e.toString());

                                                                 }

                                                    }

                                       });

                                       con.start();

                                       while(true){

                                                    char c = (char)System.in.read();

                                                    if(c == 'q')

                                                                 break;

                                       }

                                       con.close();

                          }catch(Exception ex){

                                       System.out.println(ex);

                          }

             }

}

메시지 출력 프로그램 작성

JMS 서버에게 메시지를 pub/sub 방식으로 전달하기 위한 MessageTopicPublisher.java 파일을 작성한다.

 

import java.io.*;

import javax.jms.*;

import javax.naming.*;

import java.util.Properties;

 

public class MessageTopicPublisher {

             public static void main(String args[]) {

                          if(args.length!=1){

                                       System.out.println("사용법 : java MessageTopicPublisher 전송할 메시지");

                                       System.exit(0);

                          }

                          try{

                                       Properties h = new Properties();

                                       h.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");

                                       h.put(Context.PROVIDER_URL,"t3://localhost:7001");

 

                                       Context ctx = new InitialContext(h);

                                       TopicConnectionFactory factory = (TopicConnectionFactory)ctx.lookup("weblogic.jms.ConnectionFactory");

                                       Topic topic = (Topic)ctx.lookup("jmstopic");

                                       TopicConnection con = factory.createTopicConnection();

                                       TopicSession session = con.createTopicSession(false,Session.AUTO_ACKNOWLEDGE);

                                       TopicPublisher publisher = session.createPublisher(topic);

                                       TextMessage message = session.createTextMessage();

                                       message.setText(args[0]);

                                       publisher.publish(message);

                                       con.close();

                          }catch(Exception ex){

                                       System.out.println(ex);

                          }

             }

}

 

프로그램 실행과 테스트

창을 2개 이상 열어서 각각 MessageTopicSubscriber를 실행한다.

새창을 열어서 MessageTopicPublisher 를 실행한 후 MessageTopicSubscriber 실행창에서 메시지를 출력하는지 확인한다.

  

[출처] [weblogic]4.JMS(Java Message Service)|작성자 피쉬


저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

Webmethods Architecture

B2B/WEBMETHODS 2009. 3. 31. 21:26

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

BPM Architecture for Webmethods 7.1

B2B/WEBMETHODS 2009. 3. 31. 21:21

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

DUNS Number

B2B 2009. 3. 31. 13:01

DUNS 넘버

세계시장에서 국제사업자등록번호로 통용되는 DUNS(Data Universal Numbering System) 넘버는 다국적 기업신용정보회사인 Dun & Bradstreet 사가 130개국의 8,600만개의 기업에게 부여하고 있는 9자리 코드이다.

하지만, 국내 중소기업에 있어 DUNS 넘버는 생소한 국제거래 관행으로 보급이 저조한 상태여서 수출계약에 있어 불이익을 받고 있는 실정이다.

이에 중소기업청은 D&B Korea와 전략적 제휴를 통해 수출중소기업에게 8.23-11.30까지 한시적으로 DUNS 넘버를 무료발급할 계획이다.

DUNS 넘버의 무료발급을 희망하는 중소기업은 중소기업청(www.exportcenter.go.kr) 또는 중소기업협동중앙회, 벤처기업협회, 여성경제인협회, Inno-Biz협회, 중속기업진흥공단의 홈페이지에 접속한 후, 인터넷상에서 기업정보를 직접기입하여 등록하면 된다.

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

webMethods

B2B/WEBMETHODS 2009. 3. 31. 10:26

webMethods

Image:WebMethods (logo).png
Type Subsidiary of Software AG
Founded 1996
Headquarters Fairfax, VA
Key people David Mitchell, President & CEO
Industry Computer software
Products webMethods Fabric
webMethods Integration Server
webMethods Servicenet
webMethods Glue
webMethods Workflow
webMethods Portal
(see company website)
Revenue US $200.6M (2005)
Parent Software AG
Website www.webmethods.com

webMethods, which was founded in 1996, is a company which provides business process integration software. The company is headquartered in Fairfax, Virginia, and has offices throughout the United States, Europe, Middle East/North Africa, Asia Pacific and Japan. On April 5, 2007, Software AG agreed to acquire webMethods, Inc. for $546 million [1] . The acquisition closed on June 1, 2007 and webMethods is no longer traded on the US stock market. Software AG is currently traded on the German Stock Exchange.

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

MIME (Multipurpose Internet Mail Extensions)

B2B 2009. 3. 27. 17:24

MIME (Multipurpose Internet Mail Extensions) [컴] 네트워크

2004/03/22 17:56

복사 http://blog.naver.com/photofly/40001411235

이 포스트를 보낸곳 ()

1. 전자우편 약사(略史)

컴퓨터의 출현을 통한 값싸고 빠른 네트웍상의 의사소통 수단으로 전자우편(e-mail)은 폭발적으로 성장하였다. 전자우편은 전체 내용을 보내는데 그다지 많은 바이트를 차지하지 않으며, 게다가 전자우편의 전송은 곧바로 할 필요가 없기에 시스템은 적절한 시간에 전송함으로써 네트웍의 부하를 줄이며 일괄적으로 메시지를 전송할 수 있다.

인터넷상에서 X.400이나 SMTP와 같은 전자우편의 표준은 아스키형의 텍스트 메시지를 전송할 수 있었다. 그러나, 이러한 시스템에서는 비영문자나 비로마자로 구성된 메시지를 사용할 수 없었다. 또한 다양한 폰트를 사용하였거나, 여러 텍스트 스타일로 만든 메시지나, 정지화상(이미지), 소리, 기타 다중매체의 전송은 불가능하였다.

UUENCODE(Unixt to Unix Encoding)/UUDECODE와 같은 표준은 기존의 전자우편 시스템에서 실행파일이나 그림과 같은 아스키 형태가 아닌 이진 파일을 아스키형으로 전송할 수 있지만, 이 방법은 일반적이지 못하고, 이를 사용하려면 이용자는 유닉스와 관련된 약간의 전문지식이 필요하다.

이러한 문제를 해결하기 위해 RFC 1521에 의해 다목적용 인터넷 전자우편 확장(MIME; Multipurpose Internet Mail Extensions) 표준이 제안되었다. MIME 표준을 사용하면 현재 메일시스템에 다양한 문자로 구성된 파일이나, 그림, 이진파일, 소리, 동영상(video)을 사용할 수 있다.


 

2. MIME 개관

RFC 822(ARPA 인터넷 텍스트 메시지의 형식 표준, 82.08.13)에 기술된 전자우편 표준의 한계-7비트의 아스키 메시지를 작성하도록 규정-를 극복하기 위해 1991년 보렌스타인(Borenstein)과 프리드(Freed)가 RFC 1521에서 전자우편의 새로운 형태인 MIME을 제안하였다.

RFC 822에 따르면, 전자우편은 여러 가지 머리말(header)- To, From, Date 등-을 가질 수 있다. MIME은 이러한 머리말에 메시지의 내용형식(Content-Type)과 내용전송부호화 형식(Content-Transfer-Encoding) 등을 추가하여 기술하고 있다. 이 방법을 이용하면, 정형화된(formatted) 텍스트, 비영문자로 구성된 텍스트, 정지화상, 소리, 동화상, 그림 등을 포함하고 있는 텍스트와 같은 상이한 형태의 객체로 구성된 메시지를 전송할 수 있다.

MIME 표준을 사용하여 파일을 보내고 받는 전자우편 프로그램('MIME Compliant'라 칭한다)은 비아스키 파일을 보낼 때 아스키 형태로 부호화시키고, 받을 때 원래의 형태로 변환시켜 재현시키거나(display) 내려받기(download)할 수 있도록 하고 있다.

내용형식은 전자우편 판독기(reader)가 몸말(body)을 어떤 방법으로 해석해야 할지를 알려준다. 전송-부호화 형식에서는 비정형의 이진 데이터와 현재 사용중인 메일서버에서 요구하는 제한된 길이의 평범한 아스키 메시지간의 변환을 기술하고 있다. MIME 표준은 일반적으로 웹 서버에서 웹 클라이언트로 보내는 파일을 식별하기 위해 사용된다.

MIME은 93년 9월에 RFC 1521과 RFC 1522라는 두 개의 상정안(draft 표준)으로 IETF(Internet Engineering Task Force)에 의해 승인되었다. 현재 MIME은 MIME 메시지의 구조를 기술하는데 사용되는 여러 몸말을 명시하고 있는 ▶RFC 2045(인터넷 메시지 몸말의 형식)와 MIME 매체 형식의 구조를 다루는 ▶RFC 2046(매체 형식), 인터넷 전자우편 머리말 부분에서 비아스키형 데이터를 허용하고 있는 RFC 822의 확장에 대해 기술하고 있는 ▶RFC 2047(비아스키 텍스트에 대한 메시지 머리말 확장), MIME을 사용하기 위해 다양한, IANA(Internet Assigned Numbers Authority)의 등록 절차를 명시하고 있는 ▶RFC 2048(등록 절차), 마지막으로 MIME 메시지 형식의 실례와 감사문, 관련 서지사항, 부록과 MIME 형식과의 일치를 위한 기준을 기술하고 있는 ▶RFC 2049(MIME 형식과의 일치를 위한 기준과 사례) 등 크게 다섯 개의 RFC로 나누어져 있다. RFC 2045, 2047은 부분적으로 갱신되어 RFC2231(MIME 변수값(parameter value)과 부호화된 단어의 확장, 97.11.)이 마련되어져 있다.


 

3. 개체(Entities)-MIME의 구성

개체는 MIME 메시지를 구성하는 기본 블록을 말한다. 하나의 개체는 하나의 머리말과 몸말로 구성되는데, 머리말은 메시지의 내용형식과 전송부호화 형식을 결정한다. 전송데이터에 관한 정보를 표시하기 위해 MIME에서는 여러 가지 머리말 부분(header field)를 가진다. MIME의 머리말 부분을 살펴보면 아래와 같다(내용형식과 내용전송부호화 머리말 부분은 따로 다룬다).

① MIME 버전 머리말 부분:

서로 다른 MIME UA(user agent)로 하여금 송수신된 메시지를 적절히 해석할 수 있도록 MIME의 버전을 기술한다. 현재 사용되고 있는 버전은 1.0이다.

② 내용형식 머리말 부분:

전송데이터의 형식과 하위형식을 표시한다. 내용형식으로는 rich text, 정지화상, 소리 등과 같은 기본적인 형식이거나 복합적인 형식(multipart)으로 7개가 지정되어 있으며, 각 내용형식은 하위형식을 가진다. 전자우편에서는 text/plain을 주로 사용한다.

③ (내용)전송부호화 머리말 부분:

전송 데이터의 몸말을 부호화하는 방법을 명시한다. 전송부호화는 비아스키 데이터가 메일 시스템을 통하여 아스키 형태로 전송되도록 한다. 한 예로, 어떤 개체가 내용형식이 image/gif으로 지정되었으면, 몸말에서 정지화상 파일은 아스키 형태로 변환된 이진 파일 형태로 구성된다.

④ 내용 ID 머리말 부분 / 내용기술 머리말 부분:

선택적인 부분이다.

⑤ 부가적인 MIME 머리말 부분:

차후에 첨가될 수 있는 머리말 부분을 위한 것으로 아래의 구문과 같이 "Content-"로 시작해야 한다.

MIME-extension-field :=<Any RFC 822 header field which begins with the string "Content-">


 

4. 내용형식(Content Types)

내용형식은 몸말이 어떻게 해석되는지, 이용자에게 텍스트나, 그림, 실행 파일 등 어떤 식으로 표현되는지를 지정하고 있다. 각각의 내용형식은 매체형식/하위형식(media type/subtype)의 쌍으로 이루어지며, MIME 표준이 발전할수록 새로운 매체형식과 그에 따른 하위형식을 추가할 수 있는 확장성을 제공하고 있다. 그래서, MIME 형식으로 공식화되지 않은 것은 IANA에 공식적인 등록을 거칠 때까지 해당 매체형식에서 하위형식으로 "x-하위형식"으로 지정하면 된다. 예를 들면, "audio/x-aiff"는 AIFF의 소리 정보 포맷으로 아직 MIME 형식으로 등록되지 않았음을 나타낸다. IANA에 등록이 되면 "audio/aiff"로 지정될 수 있다.

RFC 2046(매체형식)에서는 <표 1>과 같은 7개의 상위 매체형식을 지정하고 있다(등록된 최신 정보를 보려면 도움글에서 Media Types를 연결하는 사이트를 참조하라).

매체형식

하위형식

설 명

text

plain

기본값으로 지정.

richtext


enriched

아스키형의 문자, 문단을 마크업 태그를 사용, 간단히 변화를 준 형태.

:


image

jpeg

기본값으로 jpeg, gif가 설정

gif

:

audio

basic

아직까진 일치된 포맷 없음.

:

video

mpeg

기본값으로 mpeg가 설정

:

application

postscript

포스트스크립 파일을 표시함

octet-stream

2진 파일을 표시함.

:


multipart

:서로 다른 형식의 데이터를 갖는 몸말을 하나의 메시지로 조합하여 전송

mixed

몸말 부분이 각각 독립적인 형식으로 일정한 순서를 지닐 때.

alternative

같은 정보에 대한 다른 버전을 각각의 몸말로 두는 경우(예: text/plain, text/enriched). 수신측 시스템에서 가장 최선의 형식을 취함.

digest

여러 메시지의 묶음(collections of messages)를 전송할 때.

parallel

몸말의 여러 내용을 동시에 보여 주려 할 때.

:


message

:메시지를 캡슐화할 경우

rfc822

rfc822 형식의 메시지로 캡슐화.

partial

전송할 메시지를 여러 개로 쪼개어 전송할 때. 수신 측 UA에서 재결합하고 이 형식으로 보낼 때는 파라미터로 메일id, 분할된 것 중 몇 번째인지를 나타내는 number, 총 몇 개로 분할되었는지의 total이 추가된다.

external-body

실제적인 몸말의 데이터는 제외하고 단지 참조할 때 사용하는데, 외부데이터에 접근할 수 있는 방법을 파라미터를 통해 기술해 주고 있다.

:


<표 1> MIME에서의 매체형식/하위형식의 예


넷스케이프의 메뉴 가운데 편집의 환경설정에 들어가면 <그림 1>과 같이 각각의 응용프로그램이 MIME을 지원하기 위해 어떤 식으로 지정되어 있는지 알 수 있다.


 

5. 전송부호화(Transfer Encoding) 형식

X.400, SMTP를 사용하는 메일시스템은 텍스트를 7비트의 아스키형으로 제한하고 있다. MIME의 전송부호화 형식은 이진 데이터를 대부분의 메일 게이트웨이를 통해 전송될 수 있는 포맷(아스키형)으로 전환시켜, 클라이언트 측에서 원래의 형태로 복제하는 알고리듬이다. 유닉스 계열에서 많이 사용하는 UUENCODE 프로그램도 비아스키형 데이터를 아스키형으로 전환시키지만, 기술적인 제약과 상호운용성의 문제를 지니고 있기 때문에 MIME이 메시지 전송에 있어 UUENCODE를 대체할 것으로 보인다.

전송부호화 머리말 부분에서 지정하고 있는 전송부호화 형식은 <표 2>와 같다.

부호화 방법

설 명

7bit

기본값. 아스키 문자만 사용한 텍스트 메시지에 사용. 메시지가 이미 7비트로 되어 있어야 한다(실제 부호화는 일어나지 않는다). 내용은 한 줄에 1000자 이하가 되어야 한다.

8bit

비아스키 문자를 포함한 메시지에 사용. 전송 데이터가 8비트임을 나타내고 실제 부호화는 일어나지 않는다.

binary

메시지에 이진 데이터를 포함시키는데 사용. 길이에 제약이 없으며, 실제 데이터에 대한 부호화는 일어나지 않는다.

base64

24비트(3바이트)를 입력받아서, 이를 6비트씩 쪼개 4바이트씩 묶어 아스키 형태로 출력하는 부호화 방법. 데이터의 크기는 원래보다 33% 커진다.

quoted-printable

포스트스크립 파일처럼 아스키 텍스트에 약간의 비아스키 문자가 첨가된 텍스트를 부호화하는 방법으로 16진수가 오는 형태로 나타남.

x-token

사용자가 정의한 코드를 사용할 수 있도록 한 것. "x-"뒤에 코드명을 넣어 사용.

<표 2> MIME에서의 전송부호화 형식


6. MIME 구현의 예

<그림 2>는 넷스케이프 상에서 메일과 함께 딸려 온 파일이 있을 때의 한 예이다. 내용형식과 전송부호화 방식이 제시되어 있다. <표 3>에서는 pine에서 송수신된 메시지를 보여 주고 있는데, 한글 파일과 그림 파일이 몸말에 첨가되어 있는 상태이다. 여기에서는 전송부호화 형식을 알 수는 없는데, more나 cat 명령을 사용하여 보면 <표 4>와 같이 머리말 부분에 들어가는 MIME의 머리말 요소(MIME 버전, id, 내용형식, 전송부호화형식, 내용기술 등)이 제시되어 있다.


  PINE 3.91   MESSAGE TEXT               Folder: INBOX  Message 1 of 1

Date: Sat, 06 Jun 1998 15:37:32 +0900 From: 김태우 <drf13385@bubble.yonsei.ac.kr> To: redheart@bubble.yonsei.ac.kr Subject: test Parts/attachments: 1 Shown 1 lines Text 2 117 KB Application/X-UNKNOWN-CONTENT-TYPE-HWPFILE 3 1 MB Image ---------------------------------------- mime content type and content transfer encoding testing message! [Part 2, Application/X-UNKNOWN-CONTENT-TYPE-HWPFILE 117KB] [Can not display this part. Use the "V" command to save in a file] [Part 3, Image/X-MS-BMP 1MB] [Can not display this part. Use the "V" command to save in a file] ? Help M Main Menu P PrevMsg - PrevPage D Delete R Reply O OTHER CMDS V ViewAttch N NextMsg Spc NextPage U Undelete F Forward

<표 3> pine에서 송수신된 메시지를 볼 때




[bubble]mail 13 > more saved-messages
From redheart@bubble Tue Jun  6 15:34:00 1998
Status: RO
X-Status:
Received: from bubble.yonsei.ac.kr ([165.132.84.173])
        by bubble.yonsei.ac.kr (8.8.8H1/8.8.8) with ESMTP id PAA27973
        for <redheart@bubble.yonsei.ac.kr>; Sat, 6 Jun 1998 15:34:08 +0900 (KST)
Message-ID: <3578E3AC.E8C3F373@bubble.yonsei.ac.kr>
Date: Sat, 06 Jun 1998 15:37:32 +0900
From: "김태우" <drf13385@bubble.yonsei.ac.kr>
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: redheart@bubble.yonsei.ac.kr
Subject: test
Content-Type: multipart/mixed; boundary="------------57494B7B9793891C52454B2C"
Content-Length: 1131340

This is a multi-part message in MIME format.
--------------57494B7B9793891C52454B2C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

mime content type and content transfer encoding testing message!

--------------57494B7B9793891C52454B2C
Content-Type: application/x-unknown-content-type-hwpfile; name="Mime.hwp"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="Mime.hwp"

SFdQIERvY3VtZW50IEZpbGUgVjMuMDAgGgECAwQFMwAAAAMAN1IiOoQDCAcIBwgHhAOEAw
AAAAAAAAQAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkATUlN
RShN

<표 4>pine에서 saved-messages나 sent-mail를 볼 때



7. S/MIME(RFC 2311, S/MIME 버전2 메시지 명세, 98.3)

전자우편에 보안과 관련된 기술이 없다면 봉함이 없는 우편엽서를 보내는 것과 같아 누구나 그 내용을 볼 수 있게 될 것이다. S/MIME(Secure MIME)는 전자메시지의 보안성에 관련된 명세(specification)로, 1995년 여러 소프트웨어 회사가 모여 전자우편의 위조(forgery)와 방해(interception)에 관련된 문제를 해결하기 위하여 만들었는데, 1996년에 전자우편의 보안에 대한 업계의 표준으로 자리잡았다. S/MIME는 전자우편의 표준 양식으로 자리잡은 MIME에 암호화에서 표준적이 자리를 확보하고 있는 PKCS(Pulbic Key Cryptography Standards)를 결합하여 보안을 유지할 수 있도록 하였다. MIME 형식의 전자우편에서는 몸말의 서식 구조가 정해져 있어 특수한 형태의 글이나 그림, 소리, 그밖에 규정된 서식 구조에 따라 여러 가지를 넣을 수 있게 만들어졌지만, MIME 자체로서는 어떠한 보안 장치가 마련되어 있지 않았다. S/MIME의 목적은 기존의 MIME의 메시지에 PKCS #7의 전자서명이나 암호화같은 보안 장치를 제공하는 것이다.

S/MIME를 지원하는 전자우편 프로그램을 사용하면, 프라이버시와 데이터의 무결성을 유지하며, 인증을 보장받을 수 있다. S/MIME이 짧은 시간에 부상하게 된 이유로는 여러 업체가 공동으로 참여하여 만들어 상호운용성을 높였으며, 국가적 보안 사항으로 묶여 있던 암호화 기술 가운데 간단한 종류는 해외로 유통시킬 수 있게 되어 국제적인 표준으로 상호운용할 수 있으며, 사용자 입장에서 쉽게 보안을 걸 수 있도록 하였기 때문이다.

앞으로 S/MIME는 전자우편의 영역에서 뿐 아니라 EDI나 전자상거래 등에도 두루 쓰여질 전망이다.

[출처] MIME (Multipurpose Internet Mail Extensions)|작성자 쪼꼬

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

RosettaNet PIPs

B2B 2009. 3. 27. 16:58

RosettaNet PIPs

* *
Related Links
• RNIF Standard
• RosettaNet and CIDX Messaging Standards
* *

The RosettaNet organization creates and maintains Partner Interface Processes (PIPs) to provide common business-process definitions for all RosettaNet message exchanges.

Each PIP specification provides a document type definition (DTD) file and a message guideline document. The DTD file defines the service-content message structure. The message-guideline document, which is a human-readable HTML file, specifies element-level constraints. Together, they provide a complete definition of the business process.

For more information about PIP specifications, see the RosettaNet Web site at http://go.microsoft.com/FWLink/?LinkID=33859.

PIP Contents

A PIP specification does the following:

•

Describes which public process pattern it implements

•

Describes how to configure the public process

•

Provides references to the documents to exchange within the PIP

A PIP specification includes three major parts: a Business Operational View (BOV), Functional Service View (FSV), and an Implementation Framework View (IFV). Each of these views specifies element-level constraints:

•

The BOV specifies the semantics of business data entities and the business process flow. It describes start and end states, and partner roles. It describes the interaction between roles, and details security, audit, and process controls. It specifies the business documents and business data entities.

•

The FSV specifies network component services, agents, and interactions. It provides the network component design required to run the PIPs, and describes possible network component interactions.

•

The IFV specifies the network-protocol message formats and communication requirements required to run the PIP.

Top of pageTop of page

Clusters and Segments

You categorize PIPs by a high-level business function (cluster) and a subfunction (segment). Clusters and segments organize business messages into recognizable categories. The following table lists these clusters and segments.

Clusters Segments

0: RosettaNet Support

0A: Administrative

0C: Testing

1: Partner Product & Service Review

1A: Partner Review

1B: Product & Service Review

2: Product Information

2A: Preparation for Distribution

2B: Product Change Notification

2C: Product Design Information

2D: Collaborative Design & Engineering

3: Order Management

3A: Quote & Order Entry

3B: Transportation & Distribution

3C: Returns & Finance

3D: Product Configuration

4: Inventory Management

4A: Collaborative Forecasting

4B: Inventory Allocation

4C: Inventory Reporting

4D: Inventory Replenishment

4E: Sales Reporting

4F: Price Protection

5: Marketing Information Management

5A: Lead Opportunity Management

5B: Marketing Campaign Management

6: Service and Support

6A: Provide and Administer Warranties, Service Packages, and Contract Services

6B: Provide and Administer Asset Management (Merged with 6A)

6C: Technical Support and Service Management

7: Manufacturing

7A: Design Transfer

7B: Manage Manufacturing WO & WIP

7C: Distribute Manufacturing Information

Each segment includes a number of specific message PIPs. For example, the 3A4 PIP is a part of the Order Management cluster (Cluster 3) and the Quote and Order Entry segment (Segment A of Cluster 3). This segment includes other related message PIPs, as follows:

Cluster 3: Order Management

•

Segment A: Quote and Order Entry

•

PIP 3A1: Request Quote

•

PIP 3A2: Request Price and Availability

•

PIP 3A3: Request Shopping Cart Transfer

•

PIP 3A4: Manage Purchase Order

•

PIP 3A5: Query Order Status

•

PIP 3A6: Distribute Order Status

•

…


저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

RNIF(RosettaNet Implementation Framework)

B2B 2009. 3. 27. 16:55

RNIF Standard

* *
Related Links
• RosettaNet PIPs
• RosettaNet and CIDX Messaging Standards
* *

The RosettaNet Implementation Framework (RNIF) standard defines how systems transport a RosettaNet message. The RNIF standard is a robust transfer, routing, packaging, and security standard. All RosettaNet messaging systems must comply with the RNIF standard to achieve RosettaNet certification.

The standard defines message structure, the need for acknowledgements, Multipurpose Internet Mail Extensions (MIME) encoding, and the digital signature. The core standard includes requirements for authentication, authorization, encryption, and non-repudiation. The RNIF standard is based on HTTP, MIME, and XML standards. The RNIF standard does not specify a platform or an enabling application.

BTARN implements two versions of RNIF: RNIF Specification v02.00.01 and RNIF Specification v1.1. RNIF 2.01 added significant functionality beyond that supported by RNIF 1.1, including encryption, attachments, and synchronous transactions. RNIF 2.0 is not backward compatible with RNIF 1.1.

Messaging Framework Patterns

The following table shows RNIF support for messaging framework patterns and synchronous message exchange. A single-action message is one that does not involve a response, whereas a double-action message includes a request and response.

Framework Pattern Synchronous/Asynchronous

RNIF 1.1

Notification

Asynch

RNIF 1.1

Transaction

Asynch

RNIF 2.0

Double-action

Synch

RNIF 2.0

Double-action

Asynch

RNIF 2.0

Single-action

Synch

RNIF 2.0

Single-action

Asynch

Top of pageTop of page

Message Definitions

RNIF 1.1 and RNIF 2.01 define the RosettaNet message differently. These differences include how they handle attachments, the Secure/Multipurpose Internet Mail Extensions (SMIME) envelope, delivery header, and MIME packaging. RNIF 2.01 specifically includes attachments; RNIF 2.01 adds a delivery header, while RNIF 1.1 does not.

  Note

BTARN does not support the Technical Recommendations for RNIF 1.1 published by the RosettaNet organization (one for attachment support, and one for synchronous responses).

Systems use the parts of RNIF 1.1 and RNIF 2.01 messages for party identification, routing, and service-level identification purposes. Before reading and replying to a body of service content, which is the main content of the message, each party must successfully populate or interpret the header values.

The following figure describes the RNIF 1.1 and RNIF 2.01 message definitions.

RN3_RNIF_Message_DefinitionsRNIF 1.1 and RNIF 2.01 message definitions

In the RNIF 1.1 message, the version number indicates the RNIF version. The content length is the length of the RosettaNet Service Message. The Service Message, which includes the preamble, the service header, and the service content, is a multipart/related MIME entity. The signature length is the length of the signature in bytes. If the signature exists, it is a Public-Key Cryptography Standards (PKCS) #7 signature on the service message field.

RNIF 2.01 includes a transfer protocol-independent container that packs together the business payload, header components, and other elements that systems will exchange in the package. A RosettaNet Business Message (as defined for RNIF 2.01) contains a preamble, a delivery header, a service header, and service content. Systems must validate all elements against the schema for the document type that contains it, based on the RosettaNet standard document type definition (DTD) grammar-validation rules. Service content can be an action message or a signal message. If service content is an action message, the message can include one or more attachments.

A RosettaNet Business Message is a multipart/related MIME entity. As shown in the preceding figure, the headers and service content are packaged together using a MIME multipart/related construct, which is similar to the RNIF 1.1 packaging scheme. Optionally, systems can digitally sign a RosettaNet Business Message. In RNIF 1.1, you would use the RosettaNet Object (RNO) format for this purpose. RNIF 2.0 eliminates the RNO format, and instead uses standard S/MIME encoding.

A system may encrypt the RNIF 2.01 payload or payload container. To do this, you bundle the parts that you want to encrypt in a multipart/related MIME entity, and then encrypt them. You then package the resulting S/MIME object as a single part in the RosettaNet Business Message.

A signal message must always be a RosettaNet-defined signal message instance. For action messages, the RNIF 2.01 specification provides the option of shipping business-action messages in a third-party defined format. The RNIF 2.01 service header includes additional fields for this purpose, such as a field that identifies the “standard body” and a field that identifies the version of the specification to which the action message conforms.

Only action messages (also known as business content) can be of non-RosettaNet origin. Systems must exchange these messages in a RosettaNet-defined PIP. RosettaNet must sanction these messages by explicitly identifying the sanctioned third-party action message in the PIP specification. Additionally, trading partners must agree in their trading partner agreement to exchange third-party business content. The agreement must include the PIP payload binding information, which identifies which third-party business content you would use as a replacement for a particular action message in a PIP.


저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,

Web service

B2B 2009. 3. 27. 16:46

Web service

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Web services architecture.
Web services in a service-oriented architecture.

A Web service (also Web Service) is defined by the W3C as "a software system designed to support interoperable machine-to-machine interaction over a network".[1] Web services are frequently just Web application programming interfaces (API) that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. Other approaches with nearly the same functionality as web services are Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA), Microsoft's Distributed Component Object Model (DCOM) or SUN's Java/Remote Method Invocation (RMI).

저작자표시 비영리 (새창열림)
블로그 이미지

파란실버라이트

To remember the time when I started learning Silver Light!

,
  • «
  • 1
  • 2
  • »

카테고리

  • Inforamtion Technology (281)
    • DESIGN PATTERN (33)
      • 실용주의 디자인패턴 (29)
    • SOFTWARE ENGINEERING (21)
      • Art Of Readable Code (12)
      • Object Oriented Programming (6)
      • TDD (2)
    • FRAMEWORK (22)
      • Spring.net (2)
      • LightSwitch (20)
    • PROGRAMING (58)
      • C# (20)
      • .NET (6)
      • HTML5 (7)
      • ASP.NET (9)
      • SILVERLIGHT (7)
      • Ruby On Rails (6)
    • PROJECT MANAGEMENT (10)
      • SW Version Management (7)
      • Schedulring Management (1)
    • BOOKS (18)
    • MOBILE APP (1)
      • SENCHA TOUCH (1)
    • SECURITY (5)
    • MES (1)
    • B2B (14)
      • WEBMETHODS (4)
    • ERP (53)
      • SAP/R/3 (51)
    • ABOUT TOOLS (2)
    • FUNDAMENT CONCEPT (21)
    • SOA BPM (22)
    • PORTFOLIO (0)

태그목록

  • 병렬
  • 동시성
  • 프로그래밍

최근에 받은 트랙백

글 보관함

링크

파란실버라이트

블로그 이미지

To remember the time when I started learning Silver Light!

LATEST FROM OUR BLOG

RSS 구독하기

LATEST COMMENTS

BLOG VISITORS

  • Total :
  • Today :
  • Yesterday :

Copyright © 2015 Socialdev. All Rights Reserved.

티스토리툴바