남정현의 Windows Azure 블로그

요즈음은 회사의 분야나 크기, 규모를 막론하고 누구나 자체적인 전산망을 구축하기 원하고, 자체적인 협업 사이트를 구축하기 원하며, 자체적인 통합 커뮤니케이션 시스템을 구현하기를 원합니다. 제대로만 구축된다면 참 편리하게 쓸 수 있고 회사가 빠르게 성장하는데 많은 도움을 줄 것이라는 것을 익히 보고 들어왔기 때문이죠. 하지만 생각만큼 쉬운 일이 결코 아닙니다. 경우에 따라서는, 회사가 원래 목표로 세웠던 대외적인 활동보다도 더 큰 역량이 들어가서 배보다 배꼽이 더 큰 일로 빠지는 경우도 많으니까요.

이번에 제가 다녀온 Office 365 MVP Day에서는 많은 이야기들이 있었지만 개인적으로는 Windows Azure Platform이나 기타 클라우드 컴퓨팅 플랫폼과 연결될 수 있는 Office 365만의 고유한 기능들에 대해서 가능성을 조사해보고 타진하는 것을 저만의 즐거움으로 삼을 수 있었습니다.

Exchange Web Service Managed API

다른 Microsoft 서비스들과 마찬가지로 Office 365 역시 독창적인 API를 제공합니다. EWS Managed API를 사용하여 조직 내 E-MAIL 계정 사용자의 작업을 대행하거나, 개인의 일정 정보를 검색하거나, 메일 내용을 검색하는 등의 서비스를 기존의 Windows Application에서는 물론, 여러분이 만들 고유한 웹 서비스 및 모바일 애플리케이션에서도 구현할 수 있습니다. 아래는 Epience에서 근무하시는 최정우 차장님께서 Demo로 보여주신 EWS를 이용하여 만든 Web Mail 시스템의 실행 예시입니다.

EWS Managed API 자체는 Exchange Server에서 제공하는 API를 기반으로 만들어진 것이기 때문에, 정확한 서비스 위치만 알고 있다면 XML Web Service를 처리할 수 있는 프로그래밍 언어에서는 EWS를 이용하여 필요한 작업을 수행할 수도 있습니다. http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17947 에 게시된 문서를 통하여 다양한 프로그래밍 언어와 환경에서 EWS Online API를 사용하는 예시를 살펴보실 수 있습니다. :-)

SharePoint Portal Development with Office 365

SharePoint는 기본적으로 협업을 위한 위키 페이지 작성, 문서 공유 등의 작업을 수행할 수 있도록 디자인된 기업용 맞춤형 포털 서비스를 제공합니다. 그렇지만 클라우드 버전의 SharePoint Online에서는 이 외에도 클라우드 기반 시스템으로 갖추어야 할 기본적인 소양으로 많이 꼽히는 Claim-based Authentication이나 Data Conversion/Migration 등의 기능도 제공하고 있습니다.

그리고 종전의 Standalone 버전의 SharePoint와는 달리, 클라우드 환경에서는 타 고객들에게 금전적, 시간적 손해를 끼칠 가능성을 사전에 차단하기 위하여 클라우드 서비스에 대해서 영향을 주지 않을것이라고 확신할 수 있는 컨텐츠만을 제작할 수 있는 SharePoint Designer 이외의 모든 코드들이 샌드박스 환경 안에서 수행됩니다.

전적으로 개발자의 재량에 따른 것이지만 간단한 전자결재 시스템 역시 SharePoint를 통하여 구축하는 것이 가능합니다. 좀 더 자세한 내용은 http://msdn.microsoft.com/en-us/sharepoint/gg153540.aspx 에서 확인해보실 것을 권합니다.

Microsoft표 온라인 서비스의 이점

클라우드 서비스를 제공하겠다고 나서는 업체들은 매우 많습니다. 그렇지만 이러한 클라우드 서비스를 단순히 제공한다는 사실만을 너무 강조한 나머지 기본에 충실하지 못한 경우를 자주 보게 되는데, 이는 달리 표현하면, "바퀴를 붙여 잘 굴러가게 만들었으니 자동차로서의 기능을 지원한다"고 설명하는 것과 같은 오류가 될 수 있습니다. Microsoft가 제공하는 온라인 서비스들은 이러한 오류에 빠지지 않도록 지속적으로 기능을 개선하고, 기본에 충실하면서도, 신뢰성이 높은 서비스들로 구성되어있다는 점에서 이번 Office 365의 런칭은 개인적으로 Windows Azure Platform이 런칭될 때 못지 않은 기대감을 가지게 합니다.

조만간 국내에서도 KT를 통하여 Office 365 서비스를 신청할 수 있게 될 것으로 보입니다. Office 365의 기본 기능들만 사용해도 훌륭하지만 이제 클라우드 시대에 맞추어 여러분도 다른 업체에 여러분의 시스템을 맡기는 일 없이 여러분의 입맛에 맞게 회사 내 인트라넷 시스템과 인프라를 DIY할 수 있습니다. :-)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

안녕하세요. 오랫만에 블로그에 글을 올립니다. 지난번 Visual Studio Camp에서 옴니버스 형식의 세미나로 Visual Studio 2010 Service Pack 1에 대하여 말씀을 드렸던 세션이 있는데, 발표 자료와 더불어서 Visual Studio 2010 SP1에 대한 간략한 소개를 위하여 글을 씁니다.

Visual Studio의 새 도움말 시스템

Visual Studio 2010 RTM 버전부터는 새로운 형태의 도움말 시스템이 도입되는데, 로컬 웹 서버를 통하여 도움말 컨텐츠가 제공되는 방식으로 이전의 Visual Studio 2005와 Visual Studio 2008에서 제공되던 방식과 다르게 제공됩니다. Visual Studio 2005와 Visual Studio 2008의 경우 자체 URI Scheme을 Windows Registry에 등록하고 이를 Internet Explorer를 통하여 탐색할 수 있도록 확장하는 방식이었습니다. 그러나 새로운 도움말 컬렉션을 추가하거나 삭제하는 과정에서 시스템 성능에 따라 재배열 시간이 상당히 오래 걸리는 문제가 있어 불편한 점도 있었습니다. 이러한 방식 대신 더 단순하지만 더 유연한 방식으로 바꾸게 된 듯 합니다.

그렇지만 이전 버전에서 제공되던 색인, 검색 기능 등이 웹 사이트 형식으로 바뀌면서 이전에 사용했던 기능들이 사라져서 아쉬운 점도 있었는데 이번 Service Pack 1에서는 다시 Help Browser Software가 부활했습니다. 그래서 로컬 웹 서버로 컨텐츠를 보여주는 것은 동일하지만 Visual Studio를 통해서 컨텐츠를 탐색하면 Help Browser가 별도로 나타납니다.

그리고 이번 도움말 시스템에서의 백미는 인터넷을 통한 업데이트가 가능해졌다는 점입니다. 실제로 설치한 적이 없는 제품이라 할지라도, 그리고 DVD를 통해서만 설치할 수 있는 전체 버전의 MSDN 안에서만 제공되던 컨텐츠까지도 인터넷을 통하여 항상 최신 버전을 다운로드받아 로컬 도움말 컬렉션에 추가하거나 필요하지 않으면 삭제할 수 있습니다.

private void UpdateFileList()
{
    string targetPath = Environment.GetFolderPath(
        Environment.SpecialFolder.MyPictures);
 
    List<object> content = new List<object>();
    foreach (string eachFile in Directory.EnumerateFiles(targetPath))
    {
        switch (System.IO.Path.GetExtension(eachFile).ToLower())
        {
            case ".jpg":
            case ".jpeg":
            case ".png":
                break;
 
            default:
                continue;
        }
 
        content.Add(eachFile);
    }
    this.fileList.ItemsSource = content;
}

• ASP.NET Development Server와는 달리 FastCGI 모듈을 호스팅할 수 있으므로 PHP와 같은 FastCGI 지원 웹 언어들을 같은 환경에서 동시에 테스트할 수 있습니다.
• 웹 프로젝트에서 IIS를 사용하도록 지정한 경우, 관리자 권한을 얻을 수 없는 다른 컴퓨터에서는 웹 프로젝트를 열 수 없는 문제점이 있었으나 IIS Express를 사용하도록 하면 이런 제약이 없습니다.
• IIS Hosted Core를 사용하므로 전체 버전의 IIS가 없어도 상관이 없으며, IIS Express가 설치되어있지 않은 경우 Visual Studio가 자동으로 이를 감지하여 Web Platform Installer를 호출하여 IIS Express가 설치될 수 있도록 해줍니다.
• 개별 프로세스 형태로 실행되므로 여러 사람이 사용하는 컴퓨터에서도 시스템 설정을 편집하는 일 없이 안전하게 실행할 수 있습니다.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>HTML5 Test</title>
    <link type="text/css" rel="Stylesheet" href="http://ajax.aspnetcdn.com/ajax/jquery.ui/1.8.10/themes/redmond/jquery-ui.css" /> 
    <script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js"></script>
    <script type="text/javascript" src="http://ajax.aspnetcdn.com/ajax/jquery.ui/1.8.10/jquery-ui.js"></script>
    <script type="text/javascript">
        $(document).ready(function () {
            $('#test').dialog({ show: "drop", hide: "drop", width: "auto", height: "auto", title: "html 5 rocks!" }).show();
        });
    </script>
</head>
<body>
    <div id="test">
        <video src="demo.mp4" width="700" height="500" id="testVideo" autoplay="autoplay">
            <strong>Your web browser does not support video element.</strong>
        </video>
    </div>
</body>
</html>

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[Internet Explorer에 대한 내용을 정정하였습니다.]

이전부터 포터블 응용프로그램을 만들기 위한 시도는 많이 있었고 최근들어서는 이러한 시도들이 가상화 기술의 한 장르로 발전하게 되었습니다. 대표적으로 Thinstall이 과거에 있었는데 이 솔루션은 VMware ThinApp으로 재탄생했지요. 그리고 Microsoft 역시 App-V 기술을 제공하고 있습니다. 그런데 오늘은 이러한 응용프로그램 가상화 솔루션에 클라우드 기술, 그리고 적절한 사용자 인터페이스까지 결합한 해외 서비스 하나를 소개해볼까 합니다. 바로 roozz입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

C#과 Visual Basic .NET의 다음 버전에 대한 이야기가 C# 4.0과 VB.NET 10.0이 출시된지 1년이 채 안된 지금 많은 화두가 되고 있습니다. 그러나 다음 버전에 대한 이야기가 아주 낯설은 이야기만은 아닌 것이 바로 비동기 프로그래밍에 대한 것이 뜨거운 이슈가 되고 있습니다. 일반적으로 비동기 프로그래밍은 전문가들만의 전유물로 잘 알려져 있습니다.

그러나 클라이언트이든 서버이든 더 나은 형태의, 더 유지보수하기 쉬운 형태의 비동기 메커니즘을 찾으려는 시도를 많이 수행해왔으며 그 결과가 이번 Visual Studio Async와 함께 공개될 듯 합니다. Visual Studio Async와 함께 공개되는 업데이트된 버전의 C# 컴파일러와 VB.NET 컴파일러는 아래와 같은 코드를 컴파일하여 비동기로 실행할 수 있도록 번역해줍니다.

async 키워드와 await 키워드가 사용된 것을 잘 관찰하면 상당히 재미있습니다. 위와 같은 코드를 Visual Studio Async 없이 작성하려면 많은 것을 이해하고 알아야 합니다. 비동기 흐름 제어를 언제 완료할 것이고, 비동기 스레드에서 UI로 데이터를 전달하기 위해서 문맥 전환을 어떻게 해야 할 것이며, 스레드의 순서를 어떻게 제어할 것인가 등등 매우 어려운 이야기를 늘어놓아야 합니다. 그리고 이런 식으로 이야기를 풀어나가다보면 전체적인 그림을 보지 못하고 세부적인 흐름에 집중하게 되어 프로그래밍 효율이 떨어진다는 것도 경험하신 분들이 많으실 것입니다.

위의 코드는 동기 방식 코드와 유사하지만 성격이 다릅니다. async 키워드를 사용하여 선언된 메서드는 컴파일 이후 자동으로 비동기 메서드와 비동기 메서드의 실행 끝에 불리울 이벤트 통지 메커니즘과 한 쌍이되어 멤버로 표현됩니다. 그리고 이러한 한쌍의 멤버를 부르는 방법이 await 지시자입니다. await 지시자 없이 부를 경우 우리가 원래 알던 비동기의 성질을 그대로 지니게 되어 스레드를 분할하고 작업이 끝나면 결과를 통지하는 방식을 사용합니다. 그러나 이를 한번에 관리하고 코드 문맥 안에서 비동기 상태를 제어할 수 있도록 하는 것이 await 지시자의 역할입니다.

이 프레임워크는 실버라이트나 WPF와 같이 빠른 화면 전환을 요구로 하는 환경에서 특히 그 활용성이 높을 것입니다. 좀 더 자세한 내용을 전달하기 위하여 공식 Whitepaper를 첨부하였습니다. Visual Studio Async는 http://go.microsoft.com/fwlink/?LinkId=203690 에서 다운로드 가능합니다. :-)

(Whitepaper) Asynchrony in .NET.docx

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이 글은 http://www.boutell.com/newfaq/misc/urllength.html 의 내용을 인용하여 서술한 것으로 2006년 이후로 바뀐 내용들이 반영되어있지 않은 것들이 많습니다. 덧붙일 의견이 있으시면 언제든 말씀해주시면 반영하겠습니다. :-)

http://www.w3.org/Protocols/rfc2616/rfc2616.html 에서 설명하는 사양에도 최대 URL 길이에 대한 내용은 언급이 되어있지 않습니다. 하지만 웹 개발을 하면서 누구나 한번즈음은 이런 부분에 대해서 고민을 하게 될 때가 있는데, 그러한 고민을 풀어줄만한 아티클이 있어 소개해 봅니다.

Browser Case No. 1: Microsoft Internet Explorer

http://support.microsoft.com/kb/q208427/ 에서 언급한 것 처럼 Microsoft Internet Explorer는 내부 WININET 헤더 파일 상의 정의를 충실히 따릅니다. URL이 가질 수 있는 최대 길이는 2083자이고, 이 중 프로토콜, 서버 이름 등을 제외한 순수 경로가 2048자까지 허용이 됩니다. 이 글을 작성했던 분의 테스트 결과에 따르면 URL 길이가 긴 경우 브라우저 차원에서 오류 페이지를 띄운다는 것으로 결과가 나왔다고 합니다.

Browser Case No. 2: Firefox

버전 1.5.x의 경우 시각적으로 주소 표시줄은 65536번째 글자 이후로는 주소를 더 표시하지 못한다고 합니다. 그러나 논리적으로 십만글자 이상의 URL도 정상적으로 처리하는 것으로 보이며, 현재 출시되는 Firefox의 경우 이러한 제약이 거의 없지 않겠는가 하는 예상을 해봅니다.

Browser Case No. 3: Safari

적어도 8만자까지는 잘 동작한다고 합니다. :-)

Browser Case No. 4: Opera

긴 URL에 관해서는 종결자라고 해도 틀림없겠네요. 무려 19만자까지, 그것도 인라인 편집이 아닌 여러 행 편집이 가능한 컨트롤로 확장까지 가능하다고 합니다. >_<

Web Server Case No. 1: Apache

기본적으로 약 4000자까지는 허용하지만 그 이후부터는 413 Entity too large 오류가 발생한다고 합니다. 그러나 근래 개발되는 RHEL 기반에서의 Apache는 문서 상으로 약 8000자 이상까지 지원한다고 합니다.

Web Server Case No. 2: Microsoft Internet Information Services (IIS)

기본적으로 16384자까지 지원하며 이는 Microsoft Internet Explorer의 경우와는 상반되는 동작입니다. 게다가 설정도 가능합니다. 특별한 제약은 없겠지만 너무 긴 URL을 받아들이는건 상식적이지 않겠지요.

Web Server Case No. 2-1: ASP.NET

웹 서버 이야기는 아닙니다만 IIS에서 독자적인 처리 규정을 가지고 있는 서버 기반 처리 엔진에 대한 이야기를 하나 하자면, ASP.NET의 이야기를 해야 할 것 같습니다. ASP.NET 3.5 SP1 (내부 ASP.NET 2.0) 까지는 Windows의 시스템 상수 _MAX_PATH가 정의하는 범위 만큼의 URL만을 IIS의 설정과는 관계없이 받아들일 수 있었지만 ASP.NET 4.0부터는 Web.config 파일의 httpRuntime 요소의 maxQueryStringLength 속성에 의하여 확장이 가능합니다.

Web Server Case No. 3: Perl의 HTTP::Daemon

기본적으로 8000자까지 지원합니다. POST 메서드로 수신하게 되는 데이터를 제외하고 순수 HTTP 헤더는 16384바이트까지 지원하며 이 중 헤더에 들어있을 URL에도 이러한 제약이 적용됩니다. 즉, 헤더에 전달되는 내용과의 상관관계도 감안해야하므로 헤더의 양이 많은 경우 8000자보다 안되게 지원이 될 수도 있습니다. 보통은 8000자 이상의 URL로 요청을 하는 경우 413 오류가 발생합니다. 이러한 제약을 넘기위해서 Daemon.pm 파일 내의 16x1024라는 모든 표현식을 더 큰 값으로 수정하면 됩니다. 물론, 이런 동작을 하는 경우 당연한 이야기이지만 Denial of Service (DoS) 공격에 취약해질 수 밖에 없겠지요.

결론

이 글에서는 단순히 fact에 대해서만 살펴보았습니다. 기본적으로 URL이 필요 이상으로 길다고 하는 것 (그 기준이 정확하지는 않지만 상식적인 범위를 벗어나는, 가령 100글자 이상)은 정상적인 상황이 아닐 것입니다. 이 정도로 긴 URL을 보내야 한다면, 대개는 Query String이 그 원인일 것이므로, GET 방식 대신 POST 방식의 전송을 고려해보실 수 있습니다. 하지만 긴 URL을 유지해야 할 필요가 있다면 제가 원본으로 참조한 글의 끝자락에 있는 "The Bookmark Problem" 섹션을 참고하시기 바랍니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Microsoft 서버 및 도구 사업부의 관리 및 보안 총괄 책임자인 Garth Fort가 IT 전문가의 역할을 혁신적으로 바꿔주는 Windows의 관리 도구에 대해 설명합니다. 이 동영상에서는 Microsoft 관점에서의 클라우드 컴퓨팅의 발전상에 대한 이야기도 들어보실 수 있습니다. Private Cloud에 대한 검토 단계에 있으신 분들께 권해드리는 동영상입니다.

자세한 내용 보기: http://www.microsoft.com/showcase/ko/kr/details/ba75c25f-c9ca-400d-ac19-8978c512f300

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

오늘 도착한 ZDNET 코리아 메일링 리스트를 통해 아주 흥미로운 웹 캐스트가 하나 게시되었습니다. Delphi Prism은 Embacadero의 최신 Rapid Application Development Tool로서 종전의 Delphi .NET에 대한 업그레이드 제품이자, RemObjects사의 Object Pascal 제품의 최신 버전입니다. Visual Studio Shell을 통하여 이전 버전의 Delphi IDE에서 사용헀던 .NET 개발 환경때 보다 더 풍부하고 확장된 기능을 제공하기도 하고, 특히 이번 XE 버전에서는 MonoDevelop 기반의 IDE도 동시에 지원하고 있어서 기능성이 매우 돋보이기도 합니다.

이 동영상에서 소개하는 기술들에 대해 간단히 요약하면, 리눅스, 솔라리스, 맥 OS X에서 데스크 탑 및 서버 닷넷 프레임워크 대체 구현을 제공하는 Mono 프레임워크 (http://mono-project.com/Downloads), 상용 제품군으로 판매되는 MonoTouch (http://monotouch.net/) SDK, 맥 OS X 환경에서 구동 가능한 iPhone 및 iPad SDK (http://developer.apple.com/iphone/), 그리고 Embacadero Delphi Prism XE (http://www.embarcadero.com/products/delphi-prism)를 활용하여 iPhone과 iPad에서 실행 가능한 응용프로그램을 디자인하는 것입니다. 이 중에서 상용 라이선스가 필요한 것은 MonoTouch와 Delphi Prism XE가 되겠습니다.

만약 Delphi가 아닌 C#을 이용하여 응용프로그램을 개발하기 원한다면 Delphi Prism XE 대신 MonoTouch와 함께 제공되는 기본 IDE인 MonoDevelop 만으로도 충분한 개발이 가능합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

HTML 5는 계속 발전 중인 기술이며, 하루가 다르게 발전하고 있습니다. 그리고 이제 여기에 한층 더 성숙한 기술을 추가하는 모습이 보입니다. 바로, WebSocket이 그 주인공입니다. 이제까지 우리는 AJAX 기술을 통하여 정형화된 HTML 및 XML을 다루는 것에 익숙해져 있지만, WebSocket은 HTML 5를 더 이상 UI 전용 마크업 언어가 아닌 하나의 소프트웨어 개발 도구로 이해할 수 있도록 도와줍니다.

noVNC가 사용하는 WebSocket의 클라이언트 측 구현은 아직까지 DRAFT 단계에 있으며, 주요 웹 브라우저들은 아직 이 기술을 정확하게 지원하지 않습니다. 실제 소스 코드를 분석해보면 WebSocket의 기능을 대리로 구현하는 Rich Internet Application 모듈이 들어있고 Adobe Flash 기반인 것을 확인할 수 있습니다. 이 모듈은 Hiroshi Ichikawa (http://gimite.net/en/)에 의하여 작성된 프로토타입 버전의 모듈로 관심있으신 분들께서는 한 번 분석해보시는 것도 괜찮을 것입니다.

또한 서버의 경우, W3C의 DRAFT를 따라 기본적인 요구 사항을 구현하도록 WebSocket 전용 서버 코드를 작성하였고 noVNC는 이 서버를 경유하여 실제 VNC 서버와 상호 작용하는 것으로 되어있습니다. 즉, WebSocket은 일반 TCP/IP 소켓과는 달리, 별도의 중개 서버가 추가로 필요함을 의미합니다. noVNC에 포함된 소스 코드는 Python으로 구동되고, 성능을 내어야 할 필요가 있는 부분을 C 언어로 작성하였습니다.

아래의 42초 분량의 Demonstration 동영상은 noVNC의 동작 모습을 촬영한 것입니다.

noVNC는 현재 Google Chrome Browser에 최적화되어 있습니다만, 다른 HTML 5 지원 브라우저에서도 조만간 사용 가능해질 것으로 보입니다. noVNC는 github에 호스팅되어있고, 자세한 내용은 http://kanaka.github.com/noVNC 에서 확인 가능합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근에 발표된 Microsoft의 Cloud 관련 솔루션들 중에서도 비즈니스 사용자들에게 가장 많은 호평을 받고 있는 솔루션이 하나 있습니다. 그 주인공은 바로 Office365 서비스입니다. Office365는 기존의 Microsoft BPOS 솔루션을 새롭게 묶어서 런칭한 서비스로 현재 베타 서비스 단계에 있습니다.

이제 Office 뿐만 아니라, Exchange, SharePoint, Lync까지 한번에 구매하고 사용할 수 있는 클라우드 서비스로 제공됩니다. Office Web App을 통하여 Office가 설치되지 않은 Windows - 또는 - 비 Windows PC에서 곧바로 문서를 편집하거나 볼 수 있고, Exchange는 전자 메일 서비스를, SharePoint는 사내 포털, 협업, CMS 서비스를, Lync는 사내 메시징 시스템을 제공하는 수단이 되며 이러한 서비스의 구축을 위하여 Private Cloud를 힘들게 구축하지 않아도 손쉽게 활용이 가능합니다.

다음은 Office 365 활용 시나리오를 설명하는 5분짜리 동영상입니다.

Microsoft의 차세대 Cloud 전략의 한 축을 담당할 Office365를 미리 경험해보실 수 있습니다. http://www.office365.com/ 에 방문해서 자세한 내용도 살펴보시길 권합니다. :-D

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

조만간 Windows Live Hotmail에 미국 내 주요 물류 배송 업체 네 곳과 함께, 해당 배송 업체의 운송장 번호를 자동으로 인식하여 통하여 물류 위치 추적 서비스 및 배송 상태를 손쉽게 조회할 수 있는 서비스를 선보일 예정이라고 합니다. 해당 업체는 FedEx, DHL, UPS, US Postal Service이며 이들 업체에서 발급한 운송장 번호를 포함하여 메일을 보내었을 때 운송장 번호를 인식하여 라이브 뷰에서 빙 맵과 연계하여 위치 추적이 가능할 것으로 보입니다.

이 기능은 메일 내에 첨부된 운송장 번호를 확인하여 자동으로 안내해주는 기능으로, 평소에 물류 배송 서비스를 자주 이용하시는 분들께는 여러모로 도움이 될 유용한 기능이 될 것 같습니다. :-)

정보 출처: http://microsoftfeed.com/2010/fedex-dhl-ups-and-us-postal-service-package-tracking-coming-to-windows-live-hotmail/

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.