برای آن دسته از دوستانی که با زبان PHP آشنا هستند کتاب زیر را پیشنهاد می نمایم در این کتاب علاقه مندان با حدود 20 تکنولوژی زیر شاخه XML آشنا خواهند شد مانند ( DOM,XSD,RelaxNG,XSL,XSLT,…. )

Pro PHP XML and Web Services

Buy: $171.98

برای دوستان علاقه مند به پایگاه داده کتاب زیر را پیشنهاد می نمایم

Professional XML Databases

Buy: $25.87

برای آنان که کم و بیش با XML آشنا هستند کتاب زیر را پیشنهاد می کنم

Understanding Web Services: XML, WSDL, SOAP, and UDDI

Buy: $32.84

این هم دو کتاب در دو سطح مقدماتی و پیشرفته در دنیای XML

Beginning XML

Buy: $8.00

Professional XML

Buy: $31.49

تهیه و تنظیم : بهنام سلطان رضایی

Produced by : Behnam Soltanrezaey

As part of the ESBG 1.0 installation process you are required to publish the required UDDI entries to your UDDI data store. When I first ran this utility (Microsoft.Practices.ESB.UDDIPublisher.exe) as part of the “1.Install_Prerequisites.cmd” script as outlined in the ESBG 1.0 installation instructions, I received the following error:

My initial search for a solution led me to this patch for .NET Framework 2.0:
https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=6003

Unfortunately this did not work.

The solution to this issues was to enable kerberos authentication in IIS by running the following line from your command prompt:

More information can be found here:
http://support.microsoft.com/kb/215383

When installing UDDI services database components onto your SQL2005 instance you may receive this error:

The database instance does not meet the minumum version or service pack level requirements...

This issue occurs because the UDDI installation process examines the value of the CSDVersion registry entry for SQL Server. The CSDVersion registry entry is used for SQL Server 2000 service packs. The CSDVersion registry entry is not used for SQL Server 2005. Therefore, this version check fails when you try to install the UDDI Services database components on an instance of SQL Server 2005.

To fix this you can follow the steps outline in this Microsoft Support document http://support.microsoft.com/kb/927230 or cut and paste the following script into a blank text document and save as a batch file.

After running this batch file re-attempt your UDDI services installation and you will be able to install your UDDI services database components to your SQL2005 instance.

Web servisleri Haziran 2000′de ortaya çıkan bir çok yazılım firması tarafından yoğun bir destek bulan bir modeldir. Web servisleri açık internet standartlarına dayanır. Henüz gelişme ve olgunlaşma aşamasında olan bu modelle ilgili olarak bu aşamada ortaya çıkan ve kullanılan çekirdek standartlar SOAP, WSDL ve UDDI’dır.  Web servisleri anlayabilmeniz için öncelikle HTML ve XML dillerinin temelini anlamanız gerekiyor.

Web servisler, Object Management Group(OMG), Common Object Request Broker Architecture (CORBA), Microsoft’s Distributed Component Object Model (DCOM)  veya SUN’s Java/Remote Method Invocation (RMI) gibi diğer yaklaşımlarla fonksiyonellik bakımından çok benzerlik gösteriyor.

Web servisleri modelini destekleyen Microsoft, IBM, Sun, HP, Oracle ve daha bir çok firma bu konuda yoğun bir şekilde çalışmakta ve web servisleri yazılım ve uygulama geliştirme araçlarını geliştiricilere sunmaktadırlar. Bu konudaki firmaların yoğun desteğinden dolayı uygulama bütünleştirmesi konusunda ortaya çıkacak hakim ortamın web servisleri modeline dayanacağı yönündedir.

Peki ama web servis nerelerde kullanılıyor?

• Web Servisler uygulama bileşenidir
• Web Servisler açık protokolleri(open protocols) kullanarak haberleşir.
• Web Servisler kendi kendine yetebilen ve kendinden tanımlıdırlar.
• Web Servisler UDDI kullanılarak keşfedilebilir.
• Web Servisler diğer uygulamalar tarafından kullanılabilir.
• Web Servisler XML temeline dayanır yani XML tabanlı bir teknolojidir.

Web servisler ile diğer programlama dilleri veya diğer platformlardan xml ile erişilebilir bu sayede platformdan ve programlama dilinden bağımsız olarak aynı uygulamayı yapabiliriz. Bunun için temel platform elemenleri şunlardır:

• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)

Web Servislerin iki temel kullanımı vardır.

1-) Reusable application-components(Yeniden kullanılabilir uygulama bileşenleri)

Bazı uygulama bileşenleri birden fazla yerde değişik şekillerde kullanılabilir. Web servisler bunu sağlayabilir. Örneğin para birimi dönüşümü, hava durumu raporları veya dil tercümanlığını dahi servis olarak uygulama bileşeni halinde sunabilir.

2-) Connect existing software

Web Servisler verilen farklı uygulamaların veri bağlantısı için birliktelik(interoperability) problemini çözmenize yardım edebilir. Web Servisleri ile veriyi farklı uygulamalar ve farklı platformlar arasında değiştirebilirsiniz.

SOAP(Simple Object Access Protocol):

SOAP, XML tabanlı uygulamalarda HTTP üzerinden bilgi değişimine izin veren protokoldür. Basitçe SOAP, Web Servis erişimi için protokoldür. RPC (Remote Procedure Call, DCOM, IIOP (Internet Inter-ORB Protocol) ve Java RMI bu çözümlerden bazılarıdır.

• SOAP,  mesaj göndermek için bir formattır.
• SOAP, Internet üzerinden iletişim kurmak amacıyla tasarlanmıştır.
• SOAP, platformdan ve programlama dilinden bağımsızdır.
• SOAP, firewall(güvenlik duvarına) gelebilmeye izin verir.
• SOAP W3C standardıdır.

WSDL(Web Services Description Language):

WSDL, XML tabanlı web servisleri tanımlamak ve yerini belirtmek için tanımlanmış dildir. WSDL, W3C standardıdır. Bir anlamda dağıtık programlamada kullanılan IDL’e (Interface Definition Language – Arayüz Tanımlama Dili) benzer. Web servisi tanımı işlemler, giren ve çıkan mesaj formatları, ağ ve port adresleri gibi bilgileri tanımlar. Bir web servisi tanım belgesi aşağıdaki temel elemanları içerir:

• Types: mesajlarda kullanılacak veri tiplerini belirtir.
• Message: İletişimde kullanılacak measjları tanımlar.
• PortType : Web servisinin içerdiği işlemleri (methods) ve ilgili mesajları tanımlar.
• Binding : İşlem ve mesajlarda kullanılacak veri formatlarını tanımlar.
• Port: Binding ve web adresinden oluşan servis noktasını tanımlar. Web adresi servisin çalıştırılacağı URL’dir.
• Service: Kullanılan port’lar kümesidir.

UDDI(Universal Description, Discovery and Integration):

UDDI, şirketlerin web servisler için kayıt edebildiği ve arayabildiği dizin servisidir. UDDI Kurum Kayıt Servisi (UDDI Business Registry) kurum ve web servisleri bilgilerini saklayan sunuculardır. Bu sunucular servis sağlayıcılarından gelen bilgilerini kendi veritabanlarına kayıt ederek diğer kurumların erişimine açar. Şu anda aktif olarak çalışan kurum kayıt sunucuları uddi.microsoft.com ve uddi.ibm.com ‘dur.

• UDDI, web servisler hakkında bilgi depolandığı dizinlerdir.
• UDDI, WSDL tarafından tanımlanmış web servis arayüz(interface) dizinidir.
• UDDI, SOAP üzerinden iletişim kurar.
• UDDI, Microsoft .NET platformu üzerine kurulmuştur.

Geçen yıllardaki gelişmelerden sonra bugünkü web ortamı olmadan ağ tabanlı bilgi sistemlerinin düşünülmesi çok zordur. Web’in bu kadar başarılı olmasının nedeni basitlik ve yaygınlığıdır (ubiquity). Web ortamındaki gelişmeleri üç safhada inceleyebiliriz:

• Belge Web’i (Document Web) : Belge web’i ile web ilk aşamadaki kullanımı, yani HTTP protokolü ile HTML dilinde biçimlendirilmiş statik belgelerinin kullanıcılara sunumunu ifade ediyor.
• Uygulama Web’i (Application Web) : Bu yapı işletmelerin müşterilerine web üzerinden bazı iş süreçlerini yaptırma gereksinimi sonucunda ortaya çıktı. Bu yapıda sunucu tarafında çalışan programlar (server-side programs) vasıtasıyla hazırlanan dinamik HTML belgeleri ile kullanıcı ve iş uygulaması arasında etkileşim sağlandı.
• Servis Web’i (Services Web) : İşletmelerin diğer işletmelerle olan iş süreçlerini bütünleştirme gereksinimi sonucunda ortaya çıkan ve gelişmekte olan yeni yapıdır. Bu yapının temel taşı web servisleridir. Web servislerindeki temel amaç işletme bilgi sistemlerindeki program modüllerinin etkileşimini sağlamaktır. Web servisleri web ortamında yayınlanabilen, aranıp bulunabilen ve çağrılarak erişilebilen modüler uygulama fonksiyonlarıdır. Bu fonksiyonlar değişik kurumsal iş süreçlerini gerçekleştireceklerdir.

Web servisleri modeli üç ana birimin etkileşimine dayanır.

• Servis Sağlayıcı (Servis Provider): Servis sağlayıcı istemcilerin sağlayıcıda bulunan servislere erişimini sağlar. Servis sağlayıcı kendi sitesinde bulunan web servisleri tanımını servis kayıt birimine (service registry) kaydederek bu servisinin nasıl çağrılacağı belirtir.
• Servis İstemcisi (Service Requester) : Servis sağlayıcısında bulunan web servislerini çağırarak kullanan istemci uygulamalardır. Web servisinin nasıl çağrılacağı ve ilgili parametreleri servis kayıt biriminden arayarak bulur ve çağırır.
• Servis Kayıt Birimi (Service Registry) : Servis sağlayıcılarının yayınladıkları web servisi tanımlarını saklar ve aranıp bulunmasını sağlar. Servis sağlayıcıları servis kayıt birimini tarayarak istediği servislere hakkında bilgi alabilir. Servis kayır birimi her servisin nasıl çağırılacağı konusunda tanım bilgileri içerir.

Bir web servisi istemcisinin bir servis sağlayıcıdan bir servisi çağırma aşamasındaki temel adımları:

• Web servisi istemcisi (SOAP Client) servis kayıt biriminden (UDDI) web servisini bulur.
• İstemci bir SOAP mesajı hazırlar. SOAP mesajı bir XML belgesidir.
• İstemci SOAP mesajını web server veya uygulama sunucusunda çalışan SOAP istek dinleyicisine gönderir. İstek dinleyici gelen isteklere cevap veren sunucu programlardır. Bu programlar bir JSP, ASP, CGI veya ISAPI programıdır.
• SOAP sunucu gelen SOAP mesajını parse eder ve gerekli parametreleri göndererek istenen nesnenin istenen yöntemini çağırır.
• Çağırılan nesnedeki yöntem çalışır ve sonuçları SOAP sunucuna’a gönderir. SOAP sunucusu gelen sonucu SOAP mesajı formatında biçimlendirerek istemciye gönderir.
• İstemci gelen SOAP mesajının içindeki bilgileri alarak istekde bulunan programa gönderir.

Yeni nesil web uygulamaları web servisleri modeline dayanacaktır. Web servisleri ile, kurumlar işbirliği yaptığı satıcı, müşteri ve banka gibi diğer kurumlardaki iş süreçlerini birleştirerek daha iyi işlevsellik ve daha az maliyet gibi bir çok avantajlar sağlayacaklardır.

Web servisleri modeli XML, SOAP, WSDL ve UDDI gibi açık internet standartlarına dayanır. Bu konudaki firmaların yoğun desteğinden dolayı uygulama bütünleştirmesi konusunda ortaya çıkacak hakim ortamın web servisleri modeline dayanacağı yönündedir. Web servisleri modelini ciddi olarak benimseyen Microsoft, IBM, Sun, HP, Oracle ve daha bir çok firma bu konuda yoğun bir şekilde çalışmakta ve web servisleri yazılım ve uygulama geliştirme araçlarını geliştiricilere sunmaktadırlar.

Kaynaklar:

http://www.godoro.com/divisions/ehil/Mecmua/Magazines/Articles/txt/html/article_WebServices.html

http://en.wikipedia.org/wiki/Web_service

http://www.w3schools.com/webservices/default.asp

Οι τεχνολογίες που χρησιμοποιούν οι Υπηρεσίες Διαδικτύου συμπεριλαμβάνουν:

• XML, που περιλαμβάνει βασική XML, XML schemas και XML parsers.
• SOAP (Simple Object Access Protocol), που αποτελεί ένα πρωτόκολλο επικοινωνίας εφαρμογών βασισμένο σε XML.
• WSDL (Web Services Description Languages), που είναι ένα XML schema για περιγραφή των μηνυμάτων, λειτουργιών και αντιστοιχήσεις πρωτοκόλλων των υπηρεσιών διαδικτύου.
• UDDI (Universal Description Discovery and Integration), που είναι ο χώρος αποθήκευσης για καταχώρηση και αναζήτηση περιγραφών υπηρεσιών διαδικτύου.

Οι παραπάνω τεχνολογίες έχουν ως στόχο την περιγραφή της Υπηρεσίας Παγκόσμιου Ιστού. Η περιγραφή είναι εκείνη που δημοσιοποιείται από τον παροχέα της υπηρεσίας στον κατάλογο υπηρεσιών. Η περιγραφή είναι το αποτέλεσμα της αναζήτησης του αιτούμενου στον κατάλογο υπηρεσιών. Η περιγραφή είναι εκείνη που ενημερώνει τον αιτούμενο για όσα ακριβώς χρειάζεται να γνωρίζει προκειμένου να καλέσει την υπηρεσία που τον ενδιαφέρει. Τέλος, η περιγραφή της υπηρεσίας μπορεί να περιέχει πληροφορία για το τι είδους είναι το αποτέλεσμα που αναμένεται να επιστραφεί ύστερα από την κλήση της υπηρεσίας.

MuleSource decides to bypass a ‘check box’ feature in its next-gen …

One of the biggest decisions Mason faced in 2008 was whether to include UDDI support in the initial releases of its Mule Galaxy SOA registry

Las nuevas tendencias de negocios y desarrollo de las tecnologías de información han hecho que se desarrollen tendencias en las cuales el consumo de servicios web sea de vital importancia pues este aporta un simplicidad en el desarrollo de software, como muestra de ello se observa en su implementación pues no es necesario depender de la plataforma de desarrollo o arquitectura de este. Así un servicio web es un sistema de software diseño para permitir interoperabilidad entre maquinas a través de una red, dichos servicios tienen un formato descriptor donde se muestra toda la información relacionada con este, tales como operaciones, forma de invocación y demás (WSDL).

Los servicios web permiten crear una interfaz capaz de recibir y enviar peticiones donde un cliente envía peticiones y recibe repuesta de un servidor de servicios web, todo esto es posible gracias a SOAP (Simple Object Access Protocol) pues permite crear un estándar en la comunicación cliente-servidor. Una de las ventajas de los servicios web es que permiten al cliente obtener acceso a la información de forma remota siendo totalmente invisible para el usuario final, otra ventaja de estos es la independencia de la arquitectura y lenguaje de programación en el cual se esté desarrollando permitiendo ser más escalable.

Un servicio web tiene incluido para su desarrollo, despliegue y funcionamiento tres “capas” claves, Comunicación, Descripción, y Descubrimiento. Cada una de estas capas le permite al servicio web inter operar con los servicios para el usuario o entre servicios.

1. Comunicación

Es el encargado de realizar la comunicación entre aplicaciones sobre la red, este incluye varios protocolos para su funcionamiento tales como, HTTP, FTP, SMTP, SOAP, entre otros. El protocolo más utilizado para este tipo de comunicaciones es SOAP pues soporta la publicación y búsqueda de operaciones en la arquitectura de los servicios web. SOAP consta principalmente de tres partes, el contenido de la descripción del mensaje, las reglas de codificación y un mecanismo para facilitar las llamadas remotas. Adicional a esto SOAP puede ser utilizado solo o con una combinación de protocolos.

2. Descripción

Cada servicio web debe tener un descriptor que permita su fácil invocación lo cual le permite tener una “interfaz publica” para el resto de la aplicación es así como WSDL (Web Service Description Language) es el estándar básico de definición de servicios web, este se encuentra en formato XML (eXtended Markup Language) donde se describe lo que un servicio web realiza y la forma de invocarlo

3. Descubrimiento

El descubrimiento del servicio web se hace a través del cliente donde se usa UDDI (Universal Description Discovery and Integration), este es un marco para el descubrimiento de servicios donde le permite a los usuario poder acceder a los servicios. la estructura de datos de UDDI empieza por describir el proveedor del servicio, donde se describen el nombre de la compañía, detalle de contacto y otra información de negocio. Además, describe los conjuntos de servicios que podrían ir asociados al servicio y por último describe el servicio web con el cual el usuario puede interactuar (enviar y recibir petición).

Introduction to SOA (Service Oriented Architecture)

Service Oriented Architecture atau SOA memungkinkan departemen IT untuk membuat suatu transisi dari pendekatan aplikasi menuju pada suatu pendekatan proses bisnis. Dewasa ini, departemen IT memiliki suatu kebebasan untuk mengkombinasikan layanan bisnis dari berbagai aplikasi untuk menyampaikan suatu dukungan proses bisnis end-to-end. Mekanisme integrasi dari SOA pun memungkinkan loosely coupled integration, sehingga departemen IT dapat melakukan suatu upgrade atau mengubah aplikasi yang satu tanpa mempengaruhi aplikasi yang lain.

Dengan kata lain, SOA merupakan suatu arsitektur yang mendukung loosely coupled services untuk memungkinkan suatu bisnis yang fleksibel dalam pertukaran informasi dan penggunaan teknologi informasi. SOA terdiri dari kumpulan layanan bisnis yang mendukung suatu pengkonfigurasian kembali realisasi end-to-end bisnis proses yang fleksibel dan dinamis menggunakan deskripsi layanan berbasis interface.

SOE (Service Oriented Enterprise) Maturity Models Level

SOE Maturity Model merupakan suatu model dari “SOA yang lebih menyeluruh” dan fokus dalam membawa ROI (Return on Investment) untuk bisnis yang baik pada organisasi IT. Berikut gambar SOE Maturity Model :

Level 1 :

SOE Foundation-initial mengatur indicator kunci performa, end-to-end bisnis proses dan mengatur infrastruktur SOA. Ini mengartikan bahwa SOE bukan hanya satu layer yang mendapatkan suatu dasar dari teknologi web service akan tetapi ada tambahan dua layer yaitu the enterprise performance layer, yang mengidentifikasikan sejumlah indikator kunci performa dan the business process management layer, yang mengidentifikasikan proses awal yang bergantung pada SOA/ESB layer untuk menjaga suatu kualitas yang tinggi, performa yang tinggi, dan reliable integration menggunakan layanan teknologi. Layer ini merupakan hasil dari pengaturan awal terhadap tiga layer SOE di atasnya.

Level 2 :

SOE Repetable projects-infra-focused. Pada level ini akan menentukan arsitektur SOA, pada ESB (Enterprise Service Bus), dan implementasi dari ESB. Level 2 ini memiliki penanganan yang baik pada identifikasi semua ketergantungan terhadap (a) user bisnis, khususnya stakeholders dan bisnis analis; (b) proses dan rule arsitek untuk mendesain dan implementasi dari policy, prosedur, dan end-to-end bisnis proses dan (c) infrastruktur arsitektur SOA untuk desain yang berorientasi pada layanan dan standarisasinya. Metodologi pada level 2 ini dapat dimulai dari pengukuran terhadap proses dan performa, dapat diperkirakan keuntungannya dan dapat mulai membawa dan mengulang ROI untuk didesain ulang yang berorientasi pada proses dan layanan. Jadi di sini akan mengatur optimalisasi proses end-to-end ROI, termasuk KPI pada level EPM, business rules dan proses pada level BPM dan mendasari level ESB/SOA.

Level 3 :

SOE-extended enterprise-focused. Perluasan komposisi dan integrasi perusahaan business-to-business, dengan QoS (Quality of Service) standards support untuk proses bisnis end-to-end. Implementasi dari proses yang mendasari layanan integrasi lebih kompleks daripada proses oriented. Proses pada level ini termasuk mengeksekusi secara internal dalam masing-masing partner bisnis. Partner bisnis dapat mendefinisikan dan menyebarkan khoreografy yang kompleks dari proses-prosesnya. Masing-masing memiliki mesin proses internal sendiri. Perluasan enterprise akan dapat mengeksekusi proses end-to-end secara kuat termasuk pertukaran informasi dalam konteks proses internal.

Level 4 :

SOE-solution focused. Berfokus pada solusi horizontal dan vertikal yang membantu enterprise secara cepat dalam membangun dan menyebarkan solusi pelanggan. Solution framework pada dasarnya merupakan suatu fondasi yang dapat mempercepat life cycle of projects secara keseluruhan oleh SOE. Solution framework terdapat (a) predefined best-practice business process templates (b) predefined best-practice information model definitions; (c) redefined best-practice rules dalam kategori yang berbeda seperti declarative expressions, declarative decision, event rules dan constrains; dan (d) predefined service intergration dengan back-end atau trading partner organization. Pada level 4 ini, ahli teknik telah menghasilkan best practices untuk digunakan kembali pendefinisian solusi yang sudah ada dan menentukan area mana yang butuh di buat alternatife skesifikasinya dan perluasannya. Ini pada dasarnya merupakan pendekatan yang berbeda dan lebih dewasa untuk mengembangkan suatu solusi. SOA dan sistem BPM adalah layer inti horisontal. Pada level ini, bukan hanya arsitektur best practice dan solusi tetapi juga menurun/vertical sebagus solusi horisontal yang memiliki komponen predefined yang dapat berpengaruh terhadap service integration dan otomatisasi proses bisnis.

Level 5 :

SOE-performance, agility, and intelligence focused: Ini berkaitan pada fitur-fitur yang lebih maju dari SOE. Ini merupakan optimasi, dan kemampuan yang ada secara cepat turun dari level KPI (Key Performance Indicator) yang tinggi pada proses, partisipasi atau service deployed dalam dasar infrastruktur. Sistem dapat juga menyarankan optimalisasi dan menyediakan kemampuan untuk memprediksi peningkatan nilai KPI. Fitur-fitur lain pada level 5 :

Membangun service, proses dan policy asstes : Pada level maturity ini kemampuan hadir untuk mengorganisasikan bisnis proses, bisnis rules integrasi, dan semua aspek yang lain dari partisipasi, back-end service, atau layanan perdagangan partner dipilih dan dieksekusi. Proses, rules, dan fasilitas yang terintegrasi diperlakukan sebagai asset perusahaan, dimana dapat secara mudah digunakan dan dispesialisasikan. Sistem menyediakan pemisahan dari apa yang dimaksudkan untuk diterima dalam solusi khusus melawan bagaimana untuk mendapatkannya, untuk contohnya, service mana yang harus diminta, trading partner mana yang digunakan, proses mana yang aktif, manusia mana yang berpartisipasi untuk diberikan tugas.

Dynamic discovery : Pada level maturity ini, akan ada penemuan yang dinamis dari layanan. Sekarang kita dapat secara semantic menemukan layanan lain dan terkadang bahkan dapat membawa negosiasi otomatis, pelelangan dan kemudian akses terhadap layanan. Pengikatan terhadap penyedia layanan bersifat dinamis. Pada level ini, pendesain fokus pada tipe layanan, mengukurnya melalui properties atau meta-data dari layanan. Sistem ini memperhitungkan layanan terbaik yang harus diminta. Dynamic discovery dan kemudian yang berikutnya mengikat dengan registrasi inti, penemuan dan perubahan dari permintaan / jawaban dari apa yang telah diilustrasikan.

SOE maturity model agak sedikit berbeda dari SOA maturity model. Dalam beberapa pemikian ini merupakan suatu superset dari SOA maturity model dan maturity model yang lain dalam keterlibatan teknologi dalam tumpukan SOE (termasuk bisnis proses, bisnis rules, ESBs, performance management). Ini merupakan pendekatan secara menyeluruh yang kritis untuk menjadikan SOE sukses.

Benefit And Implementation of SOA

SOA menyediakan manfaat dalam 4 kategori dasar :

· Mengurangi biaya integrasi

· Meningkatkan penggunaan aset

· Meningkatkan business agility

· Pengurangan resiko bisnis

Empat manfaat inti ini sebenarnya menawarkan pengembalian pada banyak level yang berbeda dan bagian dari organisasi, tergantung pada kumpulan masalah bisnis oleh karenanya perusahaan menggunakan SOA.

Prinsip-prinsip yang direkomendasikan ketika mengimplementasikan SOA :

· Mendokumentasikan proses bisnis. Dapat secara bottom up atau top down, ketersediaan dari dokumentasi proses bisnis adalah kritis dalam penyampaian SOA melalui Aplikasi berbasis Web Services

· SOA mengimplementasikan evolusi yang dimulai dari seorang pilot, menyampaikan nilai bisnis dan penambahan secara menaik

· Implementasi SOA harus didasarkan pada loosely coupled services yang menyediakan fleksibelitas yang tinggi dan penurunan biaya secara terus menerus karena reuse and lower maintenance

· Pelayanan harus memiliki interface standar yang rela untuk memungkinkan seamless integration dan interoperability dengan layanan yang lain

· Bisnis mengendalikan services, dan services mengendalikan teknologi

· Pokok dari SOA ialah business agility

Kesimpulan

Dari hasil pembahasan SOA di atas maka penulis dapat menyimpulkan beberapa hal terkait alasan mengapa kita harus mempelajari SOA ini. SOA merupakan suatu arsitektur yang terbentuk oleh karena kebutuhan akan proses bisnis yang berubah-ubah, sedangkan aplikasi sudah atau sedang terjadi/terbentuk menggunakan bahasa yang berbeda. Dengan adanya SOA ini kita mampu untuk terus mengikuti perkembangan bisnis dari suatu enterprise, tanpa harus mengubah aplikasi lama yang sudah ada sebelumnnya, baik itu berbeda dalam hal modul dan bahasa yang digunakan, akan tetapi semuanya dapat dihubungkan kembali dengan adanya konsep SOA ini. Melalui suatu teknologi WSDL sebagai penghubung informasi antara satu modul dengan modul yang lain. Dan XML sebagai tempat penyimpanan data sementara yang dapat dibaca oleh semua aplikasi.

SOA sebagai pendukung bisnis proses dalam suatu enterprise yang tiap menit, bahkan tiap detik yang selalu berubah mengikuti perkembangan kebutuhan konsumen. Hal ini semakin menegaskan kita akan banyaknya para stakeholders dan bisnis analis untuk menggunakan konsep SOA ini. Yang pada kenyataannya sangat fleksibel terhadap perubahan, reuseability, powerful dan berorientasi pada services.

Daftar Pustaka

1. Khoshafian, Setrag. Service Oriented Enterpises. 2007. Auerbach Publications.

2. http://torryharris.wordpress.com/2008/07/29/what-is-soa-service-oriented-architecture/

UDDI service registry is of paramount importance when it comes to providing a SOA Governance solution. A service registry stores metadata that is related to the particular asset you have interest in, without actually containing those assets.  It is essentially an online directory of services that enables the service providers to advertise their offerings and allowing service consumers to find services that match their criteria. It provides a foundation for the governance and lifecycle management of Business Services. It provides with what is needed to obtain enterprise-wide insight, control and economic leverage of organization’s business and service artifacts. The registry also supports metadata like classifications, categorizations, relationships and properties. These metadata are then used to define taxonomies, describe how service artifacts are related to each other and associate generic as well as object specific characteristics for service artifacts.

Here are some UDDI registries that are widely used in organizations:

1. Systinet Registry (now HP SOA Systinet Registry)  

2. Oracle Service Registry : It is a modified version of Systinet Registry. Remodeled according to Oracle needs.

3. Aqualogic Service Registry: Again a modified version of Systinet Registry.

4. IBM Web Services Registry Repository

5. TIBCO ActiveMatrix: Again a modified version of Systinet Registry.

Introduction

Yet another component of Fusion Middle Ware is UDDI (Universal Description, Discovery and Integratio). UDDI is provide as a part of OSR (Oracle Service Registry).

For installing UDDI you have to install OSR (Oracle Service Registry)

For more information on UDDI – http://www.oracle.com/technology/tech/soa/uddi/index.html

Software Download

You can download Oracle Service Registry from http://www.oracle.com/technology/tech/soa/uddi/index.html

We will be installing this in UNIX. The downloaded software can be installed on any platform.

Installation Pre-Reqs

Extract the zip file you get from the download location and you will see a jar file. The name of jar file will depend on the version you are trying to install. I am going to install version 10.3.0, so the jar file name in my software is oracle-service-registry-10.3.jar

Before you start installation, make sure that your java is atleast 1.5. You can check the same using following step

-bash-3.00$ which java
/usr/bin/java
-bash-3.00$ java -version
java version “1.4.2″
gcj (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8.0.1)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

So in my case the java version is 1.4.2. I need to install and include the path for java 1.5 or higher in my PATH variable. Since I have java 1.6 already installed, I will use the same

-bash-3.00$ export PATH=/local/java/jdk1.6.0/bin:$PATH
-bash-3.00$ which java
/local/java/jdk1.6.0/bin/java
-bash-3.00$ java -version
java version “1.6.0_07″
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)

Next important thing to do, before starting the OSR installation is to create a schema that will be used for creating repository for UDDI.

SQL> create user uddiuser identified by welcome1;

User created.

SQL> grant connect, resource to uddiuser;

Grant succeeded.

Last thing is to have a OC4J instance in order to deploy the application. We can use the basic SOA installation which gives Webserver and OC4J container.

You can check the SOA installation using my previous post Installing SOA 10g (10.1.3.4) – Fusion Middleware

The only change required in that installation is on the screen 3)

Screen 3) select “J2EE Server, Web Server and SOA Suite” for complete installation.

Instead of selecting “J2EE Server, Web Server and SOA Suite”, please select “J2EE Server and Web Server” as we want only the basic install.

Once this is done we are ready to start the installation process.

Installing Oracle Service Registry (UDDI)

Run the following command to start the installation

java -jar oracle-service-registry-10.3.jar

First screen will be welcome screen. Click on Next.

Screen 2) Select the Installation type. Select Standalone installation and click on next.

Screen 3) Select the installation directory. Click on Next

Screen 4) Enter SMTP Configuration. SMTP host will be the host on which you are installing OSR.

Screen 5) Administrator Account Configuration details. Do not change the Administrator Username, keep is admin. Else the installation might fail.

Screen 6) For Database Setup. Select “Create Schema” as we have already created the schema. We dont have to create a separate database. Once central database with multiple schemas for different installation will do.

Screen 7) Select the database type. In my case I am using Oracle database.

Screen Database details for Oracle Database. You need to enter host, port and database name as well as new schema that we have created in pre-installation section.

Screen 9) This screen ask for data source details. This data source will be create in the SOA installation that we did in pre-installation section. Just enter any name for data source and click on next.

Screen 10) You need to provide the JDBC driver details in this screen. All the drivers classes are stored in classes12_g.jar file present under SOA HOME. This path for this jar file is

SOA_HOME/jdbc/lib/classes12_g.jar

Just provide the complete path for this jar file and click on next.

Screen 11) In this screen just select “Database” for authentication provide.

Screen 12) Select the version of Application server you are using. If you are using SOA as mentioned in pre-installatin section then choose Oracle 10g 10.1.3. If you are going for AS10g R2 (Which will also do), then choose Oracle 10g 10.1.2

Screen 13) Enter the Application Server details. Here you have to enter the HTTP port, hostname on which SOA is installed and the context to be used when deploying UDDI application.

Screen 14) Here you have to enter further details for SOA instance.

Oracle home is the location for SOA home.

OPMN host is the hostname where SOA is installed

OPMN port is the request port in SOA_HOME/opmn/conf/opmn.xml

instance name is the OC4J instance name where the application will be deployed. We can keep it home as well.

Oracle Administrator : oc4jadmin

Password : password for oc4jadmin

Screen 15) Finally it will show you the summary and clicking on Next will start the installation.

Once the installation is finished, click on Next and it will give all the URLs as shown below

This completes the installation of Oracle Service Registry which contains UDDI.

Hope this helps !!

What is JavaScript?

• JavaScript was designed to add interactivity to HTML pages
• JavaScript is a scripting language
• A scripting language is a lightweight programming language
• JavaScript is usually embedded directly into HTML pages
• JavaScript is an interpreted language (means that scripts execute without preliminary compilation)
• Everyone can use JavaScript without purchasing a license

What can a JavaScript Do?

• JavaScript gives HTML designers a programming tool – HTML authors are normally not programmers, but JavaScript is a scripting language with a very simple syntax! Almost anyone can put small “snippets” of code into their HTML pages
• JavaScript can put dynamic text into an HTML page – A JavaScript statement like this: document.write(“<h1>” + name + “</h1>”) can write a variable text into an HTML page
• JavaScript can react to events – A JavaScript can be set to execute when something happens, like when a page has finished loading or when a user clicks on an HTML element
• JavaScript can read and write HTML elements – A JavaScript can read and change the content of an HTML element
• JavaScript can be used to validate data – A JavaScript can be used to validate form data before it is submitted to a server. This saves the server from extra processing
• JavaScript can be used to detect the visitor’s browser – A JavaScript can be used to detect the visitor’s browser, and – depending on the browser – load another page specifically designed for that browser
• JavaScript can be used to create cookies – A JavaScript can be used to store and retrieve information on the visitor’s computer

Example

<html>
<body>
<script type="text/javascript">
document.write("Hello World!");
</script>
</body>
</html>

We can add script code to html in three way

• Inside head tag
• Inside Body tag
• From external file

        <script src="xxx.js"></script>

Statements

        document.write("<h1>This is a header</h1>");

Comments

// for single line

/*…*/ for multi line

Message Box

alert(“sometext”);

confirm(“sometext”);

prompt("sometext","defaultvalue");

Functions

<html>
<head>
<script type="text/javascript">
function displaymessage()
{
alert("Hello World!");
}
</script>
</head>
<body>
<form>
<input type="button" value="Click me!"
onclick="displaymessage()" >
</form>
</body>
</html>

Break

Break and continue statements are allowed in javascript

Events

By using JavaScript, we have the ability to create dynamic web pages. Events are actions that can be detected by JavaScript.

onLoad,onUpload, onFocus, onBlur, onChange, onSubmit, onMouseOver, onMouseOut……..

Try Catch

<script type="text/javascript">
var txt=""
function message()
{
try
  {
  adddlert("Welcome guest!");
  }
catch(err)
  {
  txt="There was an error on this page.\n\n";
  txt+="Error description: " + err.description + "\n\n";
  txt+="Click OK to continue.\n\n";
  alert(txt);
  }
}
</script>

Throw: The throw statement allows you to create an exception.

<script type="text/javascript">
var x=prompt("Enter a number between 0 and 10:","");
try
{
if(x>10)
throw "Err1";
else if(x<0)
throw "Err2";
}
catch(er)
{
if(er=="Err1")
alert("Error! The value is too high");
if(er == "Err2")
alert("Error! The value is too low");
}
</script>

Special Characters

Special characters are are displayed by using “\”

document.write ("You \& I are singing!");
=> You & I are singing!

\’ prints single quote , \” double quote, \& ampersand, \\ backslash, \n new line, \r carriage return, \t tab, \b backspace and \f form feed

White space

JavaScript ignores extra spaces

Break up code line

document.write("Hello \
World!"); //Valid

document.write \
("Hello World!"); // not valid

Objects

JavaScript is an Object Oriented Programming (OOP) language. An OOP language allows you to define your own objects and make your own variable types.

Using Properties of object

document.write(txt.length);

Using Methods of objects

document.write(str.toUpperCase());

Date Object

Examples

Use getTime() to calculate the years since 1970.

How to use setFullYear() to set a specific date.

How to use toUTCString() to convert today’s date (according to UTC) to a string.
Use getDay() and an array to write a weekday, and not just a number.

Example
var myDate=new Date();
myDate.setFullYear(2010,0,14);
myDate.setDate(myDate.getDate()+5);

Compare two dates

var myDate=new Date();
myDate.setFullYear(2010,0,14);
var today = new Date();
if (myDate>today)
{
alert("Today is before 14th January 2010");
}
else
{
alert("Today is after 14th January 2010");
}

Array

Create an array
Create an array, assign values to it, and write the values to the output.

var myCars=new Array()

concat() method to join two arrays.

join() method to put all the elements of an array into a string.

sort() method to sort a literal array.

Access Array

document.write(myCars[0]);

Modify Array

myCars[0]="Opel";

Boolean Object

var myBoolean=new Boolean();
var myBoolean=new Boolean(true);
var myBoolean=new Boolean(false);

Math Objects

document.write(Math.round(4.7));
document.write(Math.floor(Math.random()*11));
document.write(Math.random());
var sqrt_value=Math.sqrt(16);

Regular Expression

When you search in a text, you can use a pattern to describe what you are searching for. RegExp IS this pattern.

var patt1=new RegExp("e");
document.write(patt1.test("The best things in life are free"));

Output: true

var patt1=new RegExp("e");
document.write(patt1.exec("The best things in life are free"));

Output: e

The compile() method is used to change the RegExp.

var patt1=new RegExp("e");
document.write(patt1.test("The best things in life are free"));
patt1.compile("d");
document.write(patt1.test("The best things in life are free"));

output: truefalse // e is their but d is not their

DOM (Document Object Module)

Defining standard way of accessing and manipulating HTML Documents

Root – Element – Attribute – Text

Examples

document.getElementById("someID");
node.getElementsByTagName("tagname");
document.body.bgColor="yellow";

DHTML

It is the art of combining HTML, JavaScript, DOM, and CSS.

]]> http://lostintentions.com/2008/12/08/uddi-integration-with-livecycle/ Mon, 08 Dec 2008 20:22:01 +0000 ssadler http://lostintentions.com/2008/12/08/uddi-integration-with-livecycle/

On several occasions I have been asked about the possibility of integrating LiveCycle ES with UDDI to provide a standards based way of browsing LiveCycle services. Well I figured MAX2008 was a good motivator for getting such an integration working and so that is what I kicked off several weeks prior to MAX. I decided I would build a LiveCycle Component that allowed for both the publishing and querying of data to and from UDDI from within LiveCycle. Unfortunately, I quickly realized that there still seemed to be limited tooling around UDDI. So while, I could use a complete Java implementation of the UDDI specification from Apache, JUDDI, there was no easy means for me to browse the registry to show the results. This inevitably lead to the 2nd part of this proof of concept which was to build a UDDI browser with Flex. Note: there is an open source Java UDDI Browser available at http://uddibrowser.org/ that works well, however using it for a UDDI LiveCycle demo didn’t seem right for my purposes

Walkthrough
You can view an entire walkthrough at screencast.com Or the following lower res videos at YouTube.

So why did I create this demo?

1. To provide a Proof of Concept for Integrating LiveCycle with UDDI
2. To Discuss features and concepts around the LiveCycle Registry
3. Learn How-to(s) with Flex and Web-Services (i.e. another excuse for me to improve my Flex chops)

IMPORTANT DISCLAIMER: This was a demo done as a proof of concept for which I am making the source code available. However note that the LC Component, and UDDI browser need a lot of fine tuning, which I have not and probably won’t have the time to complete anytime soon. The demo did accomplish its goal of proving that it is not only possibly but very feasible to integrate LCES with UDDI.

Architecture
Below is a high-level diagram for the architecture of the UDDI/LCES proof of concept.

LCES UDDI Architecture

1. JUDDI: A Java based implementation of the UDDI 2 Specification which was used for purposes of this demo. You can find more info about JUDDI at http://ws.apache.org/juddi/
2. UDDI Component: A custom LiveCycle component deployed in a LiveCycle Instance capable of querying the LiveCycle Registry and publishing service meta-data to a UDDI Registry
3. UDDI Browser: An AIR application for browsing Businesses, Services, and TModels in a UDDI Registry.

LiveCycle ES Registry
The “Collective” Registry within LiveCycle ES is made up of at least 6 sub registries that store meta-data around the components deployed within ES. The meta-data in the LiveCycle Registry is used at both Runtime (e.g. Service & version resolution) and Designtime (e.g. to build composite applications).

LCES Registry

1. Component Registry: Stores the base information relevant to a component such as component id, title, description, etc…
2. DataType Registry: DataTypes are Java classes that are exported from a component and that can be leveraged by the LCES tooling
3. PropertyEditor Registry: Property Editors are UI elements implemented in Java that control the visual rendering of types and properties within LiveCycle ES tooling.
4. Connector Registry: Connectors are integration mechanisms that define a means by which to invoke a LiveCycle service. Example connectors include EJB Connector, SOAP Connector, and VM Connector.
5. Service Registry: Maintains all the meta-data we have around services such as the signature of a service, description, hints, config values, etc…
6. Endpoint Registry: Stores configuration necessary to bind a service to one or more connectors. This provides for the loose coupling between service implementations and the means by which they are invoked (i.e. Connectors).

Trying out the UDDI Proof Of Concept
Unfortunately, I have not setup an environment where demos such as this are available online.
For now however you will need to do the following steps:

1. Download and install the LiveCycle trial (if you haven’t already) from http://www.adobe.com/devnet/livecycle/trial/.
   Note: This demo was built on LCES Update 1 (also known as 8.2.1)
2. Download the Source Code for a) the AIR app and b) the LiveCycle Java Component (i.e. uddi-dsc.jar) used from Download Source Code Note: uddi-dsc.jar contains the related Java code within
3. With LiveCycle up and running go to LiveCycle Workbench and click on Window–>Show View–>Components. In the Components view you can right click the top node to then install the Java Components downloaded (i.e. uddi-dsc.jar) Note: You will need to configure the UDDI3Service by right clicking it in the components view, setting the user/password expected by JUDDI (‘admin’/” for me), and setting the publishAsHost & publishAsPort (used to fill int the WSDL URL in the UDDI Registry)
4. Import the Flex Project included in the Download to your Flex Builder environment
5. Run the AIR APP!
6. Oh wait….. Before any LC Services are available in the UDDI Registry you need to invoke the UDDI2Service.publishLiveCycleService. You can do this from the “Components View” in Workbench, however, you need to first turn on the unsupported workbench option –> -Dcom.adobe.workbench.unsupported.dscadmin.invoke.enable=true in the workbench.ini file

Anyway, Good Luck! there is a lot to play with there.

Few more notes for those digging deeper:

• I packaged two modified WSDLs from which the WebService ActionScript stubs were generated within Flex Builder. I had to modify the WSDL to get around issues with the decoding of arrays.
• If you need to regenerate the WebService ActionScript stubs then you will need to modify the src/webservices/inquiry/BaseInquireService.as file to change the isWrapped properties of the WSDLMessages to false rather than true.
• The calls between LiveCycle and JUDDI seem to be slow on the perf side, but I haven’t drilled into that aspect as of yet

If you travel back in time, to around 2002, it isn’t difficult to find people claiming that Web services were going to be the new silver bullet technology to create world peace, eradicate global poverty and finally make some sense of all the data produced by the human genome project. Over hyped? Just a bit. One of the many reasons none of these things happened, is it turned out to be much harder than anticipated to build centralised registries, where people could go to find Web services to perform a given task. Can service registries ever be built? Critics like Tim Bray at Sun Microsystems for example, have suggested that (quote) “registries are a fantasy”, but some already exist and there are more in the pipeline. This article briefly introduces some of them: Seekda, BioMOBY, the Embrace service registry and the Biocatalogue project.

1. Seekda

Seekda.com [1] is a Web services search engine which combines data on over 27,000 services from more than 7,000 different service providers. They have been around for a while, as a spin-off from the University of Innsbruck, Austria. They currently provide tools to search for, browse and register new services. Seekda also provides a list of most popular services, which gives an idea of what most people are using this registry for. They even have a blog too…

2. Embrace service registry

Registries of arbitrary services are all well and good, but if you are a biomedical scientist of some kind, searching for more specific tools, it might be hard to find your needle in the seekda haystack. The Embrace Web service registry is part of a European project, the Embrace Network of Excellence involved in the use of information technology in the biomolecular sciences. At embraceregistry.net you can search, browse and register new biomolecular services, currently there are 74 different services, submitted by 46 different users.

3. BioMOBY

The BioMOBY project provides a registry of biological services and is a bit of a veteran, the project has been going since 2001. The current registry can be accessed using a range of different clients that can use the BioMOBY API. If you want to know more, take a look at the BioMOBY site or read all about BioMOBY in PubMed.

4. Biocatalogue

Biocatalogue.org provides a curated catalogue of Life Science Web Services, and is a joint project between the University of Manchester and the European Bioinformatics Institute (EBI). It will incorporate some of the features of all of the above registries, into one potentially über-registry for scientists. The catalogue is due for it’s first public release in 2009 but if you are interested in playing with the beta version, get in touch with the biocatalogue team for a sneak preview.

They spun a Web for me…

If you were expecting Web services to solve all the worlds trouble, then you’ve probably been sorely disappointed. But with service registries like Seekda, BioMOBY, Embrace and Biocatalogue, registering and finding services on the Web is possible and this should prevent some of the re-inventing the wheel that goes on especially when “new” biomedical services are created. The next step is getting all these services to work together, by plugging the output of one service into the input of another – now that’s a whole other story….

References

1. Holger Lausen and Thomas Haselwanter Finding Web Services European Semantic Technology Conference, Vienna, Austria, June 2007
2. WWW2008: The Great Firewall of China, Web services at Dubya Dubya Dubya 2008.

[Creative Commons Embrace picture by Tanakawho]

This work is licensed under a Creative Commons Attribution 2.0 UK: England & Wales License.

Resumo

Nesta última sexta-feira 21, apresentamos nosso Trabalho de Diploma (ou TD, mesma coisa que TCC) na UNIFEI e fomos aprovados!

Nosso TD é sobre SOA, conceito apresentado no post anterior SOA (Service Oriented Architecture), onde tem também um pôster que apresentamos sobre o nosso trabalho.

Conteúdo

1. Proposta
2. Desenvolvimento
3. Conclusão
4. Arquivos

1. Proposta

O co-orientador e o orientador deste trabalho apresentaram um artigo, onde demonstraram a implementação de um sistema médico para o gerenciamento de imagens digitais denominado Picture Archiving and Communication System (PACS). O PACS, em conjunto com Radiology Information System (RIS) e Hospital Information System (HIS), formam a base para um serviço de Radiologia Filmless (tecnologia que indica a manipulação de imagens médicas sem utilizar filme fotográfico, que demandava relevante custo e tempo para revelar).

As imagens são obtidas de modalidades de imagens médicas digitais, como Ressonância Magnética Nuclear (RMN) e Tomografia Computadorizada (TC), em formato DICOM (Digital Imaging and Communication in Medicine) 3.0, indexadas, armazenadas e vinculadas ao RIS do Hospital para posterior visualização.

Este sistema PACS foi concebido e desenvolvido dentre um escopo bem-definido. No entanto, há diversos outros requisitos de negócio em ambientes médicos que necessitam de manipular as informações obtidas pelo sistema apresentado. De forma a permitir futuras integrações com tal sistema de forma escalável e padronizável, é proposta a utilização de SOA.

Com essa proposta em mente, é possível utilizar de serviços pré-existentes e também integrá-los entre si e também com serviços que venham a ser criados. Assim tem-se um sistema que pode trabalhar com todo o sistema legado, integrar as bases de dados e ser distribuído, facilitando o acesso das várias redes hospitalares que necessitam dessas informações.

A proposta baseia-se em realizar serviços de consulta utilizando dois sistemas existentes: um sistema RIS e um sistema de aquisição de imagens médicas. Cada serviço realizará consultas em ambos sistemas e depois unirá seus resultados sob uma mesma resposta, conforme o diagrama UML de caso de uso abaixo:

Diagrama UML de caso de uso

2. Desenvolvimento

Cada sistema acima teve suas principais funcionalidades exportadas como Web Services. Para cada sistema foi gerado um Web Service para expor seus serviços simples.

Utilizando estes Web Services, foi construido um outro Web Service de integração, denominado Web Service PACS, caracterizando-se como um serviço composto. Este Web Service possui interface parecida ao Web Service do sistema RIS, com exceção da mensagem de resposta, e segue o seguinte fluxo para cada requição:

1. Extrai os parâmetros da requisição
2. Chama o Web Service do sistema RIS, passando os parâmetros recebidos. Receberá uma lista com exames radiológicos ou uma lista com pacientes.
3. Se recebeu uma lista com exames radiológicos, para cada exame radiológico chama o Web Service do sistema de aquisição de imagens, passando a identificação do exame como parâmetro. Receberá uma imagem para cada exame.
4. Retorna uma mensagem SOAP contendo todas as informações solicitadas, provenientes de ambos sistemas.

Os Web Services descritos acima foram publicados no servidor Apache Axis2. Por sua vez, o Web Service PACS também foi publicado no ESB Apache ServiceMix. Assim, qualquer componente membro deste barramento poderá usufruir da mesma maneira e sob o controle da mesma infra-estrutura.

O diagrama UML de atividades abaixo ilustra todo o processo:

Diagrama UML de atividades

3. Conclusão

Com a organização em serviços das funcionalidades dos sistemas apresentados, e sua utilização sobre uma infra-estrutura padronizada, alcança-se a robustez necessária para que o sistema cresça sem maiores problemas, aumentando assim seu valor agregado. Além disso, é possível ter controle sólido sobre segurança, roteamento e monitoramento do serviço.

Ao publicar tais serviços sobre tal arquitetura orientada a serviços, torna-se possível a construção de operações mais complexas com respeito à gestão e manipulação de informações dos pacientes, como por exemplo a obtenção de prontuário completo para um paciente, baseado num histórico médico que possa estar distribuído em sistemas distintos e em localidades distintas.

Ainda, a utilização de SOA introduz diretrizes para guiar o desenvolvimento de futuras integrações entre outros sistemas médicos, fazendo respeito tanto sobre a questão tecnológica quanto a questão de pessoal.

Desta forma, ao aplicar SOA em um ambiente médico, concluimos que SOA é uma tecnologia adequada para a integração de ambientes heterogêneos como os ambientes da área médica.

4. Arquivos

• Trabalho de Diploma
• Apresentação do TD

Me imagino ke ya muchos hemos escuchado hablar de SOA, y una de las representaciones ke se le puede dar al SOA son los webservices y en este tutorial aprenderemos a crear los 3 elementos (El servicio, la aplicacion ke llama al servicio y el UDDI) y conectarlos entre si.

Lo ke vamos a necesitar:

Para crear el webservice y la aplicacion ke consume al WS

- Microsoft Visual Studio 2008

Para el servidor UDDI

- VMware workstation 6.5.0 (Crea maquinas virtuales)

- Windows Server 2003 (para montarlo en la maquina virtual)

- Hamachi 1.03 (crea VPNs)

Pero ke es exactamente lo ke vamos a hacer?

Vamos a crear un WS en Visual Studio y lo vamos a “consumir” con una aplicacion tambien hecha en Visual Studio, para hacer esto hay 2 formas:

1.- Creamos el WS y lo corremos en el emulador de servidor ke viene con Visual Studio y lo llamamos con el mismo Visual Studio pero en otra aplicacion aparte.

2.- Creamos el WS y lo publicamos en nuestro servidor UDDI (corriendo en Windows server 2003 siendo emulado con el VMware), donde es llamado por Visual Studio de forma completamente independiente.

Asi ke vamos a empezar…

A) Creando el Web Service

El WS ke vamos a crear es bastante sencillo, lo unico ke hace es pedir 2 numeros y regresar el resultado de la multiplicacion de estos.

1. Abrimos el Visual Studio y seguimos la siguiente ruta:

File / New Proyect / Visual Basic / Web /ASP.NET Web Service Application

en el Nombre del proyecto ponemos WSMultiplicacion.

2. En el Explorador de Soluciones (derecha), renombramos el Service1.asmx a ServiceMul.asmx y borramos el siguiente codigo:

<WebMethod()> _

Public Function HelloWorld() As String

Return “Hello World”

End Function

3. Debido a ke es un web service de ejemplo ke pone por default Visual Studio, y lo vamos a reemplazar con :

<WebMethod()> Public Function Mul(ByVal A As System.Single, ByVal B As System.Single) As System.Single

Return A * B

End Function

para ke kede asi

4. Una ves hecho esto es momento de probar nuesto WS, para esto damos click en el boton de Start Debugging (play color verde) o presionamos F5.

nos aparece un mensaje preguntandonos como queremos correr el programa “debugging o no debugging”, para este caso utilizaremos “Run without debugging”

5. Entonces lo ke va a hacer es iniciar el ASP.NET Development Server donde podemos correr nuestro servicio y vamos a obtener las siguientes paginas en nuestro explorador

Damos click en Mul, para probar nuestro servicio con el boton de invoke

y nos muestra el resultado en otra ventana

Y asi es como creamos el web service, ahora la siguiente parte es hacer una aplicacion ke lo use.

B) Creando la Aplicacion ke consume al WS

6. Abrimos un nuevo Visual Studio y seguimos la sig ruta:

File / New Proyect / Visual Basic / Windows / Windows Forms Application

y como nombre del proyecto ponemos AplicacionMultiplicacion

7. Ahora hacemos una forma con minimo las siguientes caracteristicas 3 TextBox y un boton (labels opcionales)

8. Antes de modificar el codigo tenemos ke agregar nuestro WebService como Web Reference y para hacer esto en Visual Studio 2008 tenemos ke seguir estos pasos:

- primero ke nada tenemos ke tener corriendo nuestro Web Service en el ASP.NET Development Server (como vimos en el paso 4),

- una vez corriendo copien el path del servicio ke les aparece en el browser, en mi caso http://localhost:1615/ServiceMul.asmx

- Ahora en nuestra aplicacion nos vamos a:

Proyect / Add Service Reference… / Advanced (esquina inferior izq) /Add Web Reference (esquina inferior izq)

y dentro de esta ventana en el URL pegamos el path del servicio, damos click en Go y nos debe de aparecer nuestro servicio

en el Web reference name ponemos localMul y damos click en add reference

9. Ahora es tiempo de referenciar el webservice para ke pueda ser utilizado como un metodo local, damos doble click a nuestro boton y modificamos el codigo para ke kede asi:

Public Class Form1

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Dim operacion As New localMul.Service1()

TextBox3.Text = operacion.Mul(TextBox1.Text, TextBox2.Text)

End Sub

End Class

Pueden ver como operacion.Mul, se refiere al metodo Mul, ke esta dentro del Service1 (nuestro web service) referenciado por medio de localMul

y recibe 2 numeros ke seran introducidos en el TextBox 1 y 2, y el resultado aparecera en el TextBox3

10. Enseguida probamos nuestra aplicacion (F5 o “play”)

*Note ke el Web Service tiene ke estar corriendo en otro Visual Studio para ke este metodo funcione, puesto ke la aplicacion manda llamar al web service.

Hasta aki ha sido relativamente facil, pero esto es solo una parte del funcionamiento de los Web Services.

Lo ke haremos acontinuacion sera crear un servidor “dedicado” a web services y un UDDI

C) Creando el Servidor

11. Lo primero ke vamos a hacer es abrir el VMware Workstation y crear una nueva Virtual Machine con configuracion tipica y metemos el disco del sistema operativo ke keremos instalar (Windows Server 2003)

en este caso yo tengo la imagen en .iso asi ke simplemente le doy el path, siguiente y pongo el serial y los datos minimos, es recomendado poner un password aunke no tenga alto nivel de seguridad

12. Una vez instalado el Windows Server 2003, lo primero ke vemos es una pantalla de configuracion ke nos deja elegir ke keremos hacer con el server, poner le un rol.

Por default no tiene ningun rol, entonces le ponemos en

Add or remove a new role / next / custom configuration /

y seleccionamos Application Server (IIS, ASP.NET) y seguimos

*En este caso no vamos a habilitar SSL puesto ke no necesitamos ningun tipo de seguridad para este ejemplo

13. Ahora tenemos ke habilitar el uddi en nuestro server, para esto tenemos ke ir a Add or Remove Programs

en el panel de control, de ahi seleccionamos Add/Remove windows components y buscamos el UDDI y lo habilitamos.

*Tambien tenemos ke asegurarnos de actualizar el .NET framework hasta la version 3.5

14. Ahora nos metemos en la configuracion del IIS (Internet Information Services) y creamos un nuevo website en el puerto 8080 con el nombre ke querramos (en este caso test) aki es donde vamos a poner nuestros servicios para ke puedan ser consumidos.

Nos vamos a donde estan los archivos de Visual Studio (My Documents\Visual Studio 2008\Projects\WSMultiplicacion\WSMultiplicacion) y copiamos el contenido dentro de la carpeta de nuestro website (en el servidor)

15. La forma de probar si tenemos bien instalado el UDDI y nuestro servidor de aplicaciones ASP .NET es ir al explorador de internet y en la barra de direcciones poner:

para el UDDI http://localhost/uddi/

para el WebService http://localhost:8080/ServiceMul.asmx

noten como en el caso del WebService tubimos ke especificar el puerto en el servidor ke es el 8080

16. Como el servidor esta corriendo en una Maquina Virtual adentro de tu computadora, puede ser accesado por su nombre completo, en este caso http://carlos-i21g1xou/uddi/

17. Ahora vamos a Publicar un WS en nuestro servidor UDDI para ke podamos acceder a el desde Visual Studio.

Lo primero es ir a Publish/Providers y agregar un nuevo provider con el nombre de Prueba (vamos a dejar el lenguaje EN-us por ser un ejemplo) y es recomendable agregar descripciones

18. Despues a services/add service y de nombre UddiMul

19. Nos metemos al service con “view” y nos vamos a Bindings y le ponemos Add Binding / edit y especificamos la ruta donde esta nuestro servicio adentro del servidor, en este caso http://carlos-i21g1xou:8080/ServiceMul.asmx tipo http

20. Nos devolvemos a Publish / tModels / Add Model, en nombre le ponemos tMul

21. Dentro de ese tModel en categorias agregamos la siguiente: Specification for a web service described in WSDL

22. Siguiendo con el tModel en el Overview document ponemos el WSDL de la multiplicacion para saber cual es simplemente agregamos ?wsdl despues de el path del service y keda asi http://carlos-i21g1xou:8080/ServiceMul.asmx?wsdl

23. Ahora tenemos ke ligar el tModel con el servicio nos vamos a

Publish / Providers / Prueba / Services / UddiMul / Bindings / view / instance info / add instance info

Buscamos por tMul y lo agregamos

24. Dentro de ahi nos vamos a overview document y agregamos el WSDL de nuevo http://carlos-i21g1xou:8080/ServiceMul.asmx?wsdl

vista final del servicio en el uddi

En este momento el servidor UDDI ya tiene el servicio de multiplicar publicado en el, y puede ser accesado por medio de Visual Studio.

25. Abrimos el proyecto de aplicacion llamado AplicacionMultiplicacion ke hicimos en el paso 6 y quitamos la Web Reference existente, para agregar una nueva, en la direccion ponemos http://carlos-i21g1xou/uddi/addwebreference/ y presionamos Go

26. Para buscar el servicio le ponemos % y presionamos search con esto nos deja ver todos los proveedores  disponibles, de los cuales seleccionamos el ke tenga nuestro servicio

27. Hacemos click en su WSDL y agregamos la nueva web reference como UddiMul

28. Ahora solo tenemos ke modificar un poco el codigo adentro de nuestro boton, donde teniamos

localMul.Service1()

lo tenemos ke cambiar por

uddiMul.Service1()

puesto ke es la nueva referencia

De esta forma ya queda funcionando, sin embargo hay un inconveniente, como el servidor esta en una Maquina Virtual solo puede ser accesado por su host y el entorno local y ke pasa si lo deseas accesar desde cualquier parte como se supone ke deberia ser?

Hamachi

29. Pues hay una solucion bastante facil y adecuada para esto, crear una red privada virtual (VPN) entre el server y la computadora desde donde lo quieras accesar y para esto usamos el Hamachi

Hamachi nos permite crear redes virtuales con unos cuantos clicks, su instalacion es sumamente sencilla y no necesita explicacion simplemente al momento de “prenderlo” (boton esquina inferior izq), te pide un nuevo nombre de usuario y te asigna una especie de IP.

30. Una ves ke ya tienes tu ip en hamachi, puedes crear o unirte a redes poniendo el nombre de la red y el password, en el servidor vamos a crear una nueva red con el nombre TutorialWebservice y password 1

Cualquiera que tenga el cliente de hamachi y le ponga Join an existing network y ponga estos datos, se va a poder conectar al servidor y usar el IP de hamachi para conectarse directamente.

31. Entonces podemos ver ke el IP de nuestro server es 5.75.113.212 y con el podemos accesar al servicio web de la siguiente forma http://5.75.113.212:8080/ServiceMul.asmx

32. Y asi mismo podemos accesar al UDDI desde visual studio con esta direccion

http://5.75.113.212/uddi/addwebreference/

y seguir los pasos desde el 25 para agregar la web reference

Y asi concluye el tutorial de como crear un Web service

Carlos Andree Labrado 2008

El autor de estè articulo, trata algunas consideraciones y conceptos para comenzar a entender el tema de web service, las mismas que son las siguientes:

• Un Web Service se puede registrar para poder dejarlo a disposición para otros usuarios y para que los mismos puedan localizarlos. Un mecanismo para registrar estos servicios es por medio de UDDI sigla que obedece a Universal Description, Discovery and Integration, un “repositorio de Web Services” (http://www.UDDI.org). Para registrar un servicio tendrá que tener en cuenta suministrar la información de su empresa, en que categorías ubicaría su servicio y la interfaz a utilizar para consumir dicho servicio.
• El mecanismo utilizado por un Web Service para especificar de qué forma hay que proporcionarle los datos, de forma tal que cualquiera pueda interaccionar con el mismo, es por medio de lenguaje XML. Esta información se almacena en un archivo llamado WSDL (Web Services Description Language). Este archivo contiene un documento XML junto con la descripción de ciertos mensajes SOAP y como deben intercambiarse, así como también donde esta el recurso del servicio y con que protocolo debe dialogar quien lo consume.
• El protocolo de comunicación utilizado es el SOAP generalmente, el cual es relativamente sencillo de utilizar.
• Los Web Services utilizan protocolos comúnmente conocidos y difundidos como el formato XML, TCP/IP como protocolo de transporte y HTTP como protocolo de transferencia de hipertexto.

Para ver un ejemplo practico y mas información de los Web service pueden ingresar al link del autor: http://www.elguille.info/colabora/NET2005/elnatu_WebServices.htm

Los servicios en Internet están tomando cada vez más importancia. Se diseñan como “cajas negras” que oculten la complejidad de los sistemas finales y permitan una fácil comunicación. Sin embargo es fundamental tener un medio de localizar esos servicios, tarea más difícil conforme crece el número de servicios disponibles.

La especificación UDDI simplifica esa tarea, permitiendo a una organización publicar información sobre los servicios que ofrece y localizar información sobre servicios web que necesita utilizar.

Describe el interfaz externo de un Servicio Web y cómo utilizarlo. Se puede definir un archivo WSDL como un documento XML que describe un conjunto de mensajes SOAP y la forma en que éstos se intercambian.

Puesto que la notación que utiliza WSDL es XML significa que es un idioma de programación neutral, basado en estándares (W3C) y que puede utilizarse desde una gran variedad de plataformas y lenguajes.

Además de describir el contenido WSDL define todos los elementos necesarios para utilizar el servicio (interfaz, lugar en el que está disponible, protocolo de comunicaciones…).

UDDI es simplemente un repositorio de documentos XML (y un esquema) que define un mensaje SOAP para el registro y petición de información [1].

Un fichero de registro es un documento XML-UDDI con tres partes principales:

• “páginas blancas”: especifican la dirección, contactos, e identificadores de empresa
• “páginas amarillas”: dan la categoría industrial basada en la taxonomía propuesta por UDDI
• “páginas verdes”: contienen la información técnica que describe los servicios web (similar a lo que hicimos al final de la parte de WSDL)

Características de UDDI

• UDDI es un sistema ideado para describir servicios (junto con WSDL) y localizar empresas que ofrezcan estos servicios.
• UDDI significa “Descripción, Localización e Integración Universales”
• Es un directorio para almacenar información sobre servicios web; entre otra, guarda las interfaces de esos servicios descritas en WSDL.
• UDDI utiliza SOAP para llevar a cabo las comunicaciones.
• Está desarrollado e integrado en la plataforma .NET de Microsoft.
• UDDI ha sido propuesto por Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP y Sun (entre otros).

UDDI puede ayudarnos a resolver los siguientes problemas:

1.  
   • descubrir la empresa más adecuada de entre las muchas presentes en Internet
   • obtener información sobre cómo contactar con esa empresa
   • conseguir nuevos clientes y facilitar el acceso a los actuales
   • incrementando los servicios ofertados y extendiendo el mercado al que se puede acceder
   • describir servicios y procesos empresariales en un entorno seguro y fácil de usar

Un ejemplo de cómo se podría usar sería el siguiente: supongamos que se creara un estándar UDDI para reserva y venta de billetes de avión. Las aerolíneas podrían registrar sus servicios en un directorio UDDI siguiendo ese estándar (e interface UDDI). Así, las agencias de viaje, accediendo al repositorio UDDI a través de la interfaz, podrían comunicarse con el servicio ofrecido por cualquier aerolínea para hacer las reservas y ventas.

REGISTRO UDDI

La publicación en UDDI es un proceso relativamente sencillo. El primer paso consiste en determinar información básica sobre cómo definir la empresa y los servicios en UDDI. El siguiente paso, una vez determinada esta información, consiste en llevar a cabo el registro, ya sea mediante programación o a través de una interfaz de usuario basada en el Web. Por último, se debe probar la entrada para asegurar que se registró correctamente y que aparece tal y como se esperaba en diferentes tipos de búsquedas y herramientas.

Primer paso: Definir la entrada de UDDI
Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta información importante antes de establecer una entrada de UDDI.

Determine los tModels (archivos WSDL) que utilizan las implementaciones del servicio Web.  Al igual que sucede en el desarrollo de un componente COM, el servicio Web se ha desarrollado a partir de una interfaz existente o de una interfaz de diseño propio. En el caso de un servicio Web basado en una interfaz WSDL existente, deberá determinar si el archivo WSDL se ha registrado en UDDI. Si es así, deberá comprobar su nombre y tModelKey, que es el identificador GUID que generó UDDI cuando se produjo el registro.

Por el contrario, si el servicio Web se basa en un archivo WSDL que no se ha registrado en UDDI, deberá crear un nuevo tModel para representar esta interfaz. El nombre de este tModel debería tener un formato URI (identificador de recursos uniforme), como MyCompany-com: SampleWebService-interface:v1, y señalar a la ubicación del archivo WSDL.

Si su servicio Web es un servicio de Microsoft® Visual Studio® .NET, podrá generar una descripción WSDL utilizando una cadena de consulta desde el archivo .ASMX (como ). No obstante, el archivo WSDL generado por Visual Studio .NET se relaciona estrechamente con el punto de acceso para la invocación del servicio Web, lo cual puede no resultar adecuado cuando la interfaz del servicio tiene varias implementaciones. Esto no supondrá ningún problema si su intención es que el archivo WSDL sólo tenga una implementación.

Determine el nombre de la empresa y una breve descripción de la misma en varios idiomas, si es necesario, así como los contactos principales para los servicios Web que ofrece.
UDDI es compatible con el espacio de nombre xml:lang, lo que permite a las empresas ofrecer su descripción en varios idiomas. Asimismo, UDDI permite enumerar los contactos, incluyendo datos como el correo electrónico, el teléfono y la dirección. Esta lista de contactos muestra los recursos de una empresa con los que se puede poner en contacto en relación con los servicios Web ofrecidos. Por ejemplo, si un usuario desea comenzar a utilizar el servicio Web deberá ponerse en contacto con el responsable de relaciones comerciales correspondiente pero, ¿cómo puede llegar a saber quién es? ¿Existe algún contacto para obtener asistencia técnica a la hora de utilizar los servicios Web de la empresa? También se debería incluir en la lista a esta persona.

Determine las categorías e identificaciones adecuadas para la empresa.
Podrá explorar los sistemas taxonómicos compatibles con UDDI actualmente en el nodo Microsoft UDDI (http://uddi.microsoft.com/default.aspx [en inglés]). Estos sistemas son, por el momento, North American Industry Classification System (NAICS), Universal Standard Products and Services Codes (UNSPSC), ISO 3166, Standard Industry Classification (SIC) y GeoWeb Geographic Classification. Seleccione las categorías que representan de forma más acertada a su empresa.

Determine los servicios Web que la empresa ofrece a través de UDDI.
A continuación, deberá determinar los servicios Web que desea registrar la empresa en el nodo público UDDI. ¿Existen varios puntos de acceso para este servicio? ¿Es preciso que los clientes conozcan otros parámetros y otra información para utilizar el servicio Web?

Resulta importante destacar que no todo el mundo puede obtener acceso a un servicio Web porque éste se haya registrado en UDDI. A una entrada de registro UDDI le pueden acompañar medidas de seguridad, autorización y autenticación. No basta que el usuario sepa que existe un servicio Web para que pueda invocarlo. Puede existir una comunicación fuera de banda entre empresas antes de permitir el acceso a un servicio Web.

Determine las categorías adecuadas para los servicios. Los servicios Web se pueden categorizar del mismo modo que las empresas. No obstante, una empresa se debe categorizar a nivel empresarial, como por ejemplo NAICS: Software Publisher (51121), y el servicio Web (de reserva hotelera, en este caso) se debería categorizar en el nivel de servicios, como NAICS: Hotels and Motels (72111).
Segundo paso: Registrar la entrada de UDDI

Una vez finalizada la tarea de definición, el siguiente paso consiste en registrar la empresa. Deberá obtener una cuenta con un registro UDDI. Esta operación no se puede realizar mediante programación, ya que deberá mostrar su conformidad con una declaración de condiciones de uso. El nodo de Microsoft utiliza Passport para la autenticación, así que deberá adquirir una cuenta de Passport (http://www.passport.com/Consumer/default.asp) para continuar con el registro.

 
En este punto se ofrecen dos opciones: puede utilizar la interfaz de usuario Web del nodo de Microsoft o realizar el registro mediante programación dirigiendo al propio nodo las llamadas a API de SOAP. Si no piensa modificar la entrada o ésta es relativamente simple, bastará con la interfaz de usuario Web. No obstante, si pretende actualizar la entrada con frecuencia, o bien, ésta es más compleja, resulta recomendable realizar el proceso de registro con secuencias de comandos, utilizando el SDK de Microsoft UDDI. Además, la interfaz de usuario de Microsoft no está localizada en otros idiomas, así que se deberá registrar mediante programación para disfrutar esa característica de la API de UDDI.

Tercer paso: Buscar la entrada en UDDI

Es recomendable realizar tres comprobaciones una vez registrada la entrada en UDDI. En primer lugar, utilizando la interfaz de usuario Web de Microsoft, busque la empresa por su nombre y categorizaciones para verla entre los conjuntos de resultados devueltos. En segundo lugar, abra Visual Studio .NET y asegúrese de que aparece en el cuadro de diálogo “Agregar referencia Web”. Si no aparece, se puede deber a que el tModel no se categorizó correctamente utilizando la taxonomía uddi-org:types descrita anteriormente. Podrá agregar el servicio Web al proyecto y generar el código proxy basado en el archivo WSDL. Por último, transcurridas 24 horas, la entrada se replicará al nodo de IBM y podrá buscarla con su IU en https://www-3.ibm.com/services/uddi/protect/find (en inglés).

Para Terminar

UDDI y WSDL funcionan como especificaciones gratuitas que facilitar el desarrollo de una colección de software basado en servicios Web. WSDL ofrece un modo formal de definir servicios Web, independientemente del proveedor, que permitirá realizar llamadas a procedimientos remotos de próxima generación, mientras que UDDI proporciona una amplia infraestructura estandarizada que permite al usuario describir y descubrir servicios Web. Mediante la combinación de estos dos estándares, se podrá desarrollar todo un universo de servicios Web [3].

WEBGRAFIA

[1] http://atc.ugr.es/pedro/tutoriales/cursos/curso_soap/uddi.htm

[2] http://www.csi.map.es/csi/tecnimap/tecnimap2002/pdfs/c4.3-110.pdf

[3] http://www.desarrolloweb.com/articulos/1599.php