20 Aug 08:04
Info on SOA, TOGAF, Virtualisation, SaaS etc.
From: alex.blore <alex.blore@...>
Subject: Info on SOA, TOGAF, Virtualisation, SaaS etc.
Newsgroups: gmane.comp.web.services.soa.yahoo-1
Date: 2008-08-20 06:08:55 GMT
Subject: Info on SOA, TOGAF, Virtualisation, SaaS etc.
Newsgroups: gmane.comp.web.services.soa.yahoo-1
Date: 2008-08-20 06:08:55 GMT
Hi all,
I recently moved south to Bangalore and I am working for a large
software integrator. My project team is working on a project that
applies TOGAF to SOA. Are you able to point me to online and offline
resources/trainings that can help our team get up to speed with SOA
features and building blocks, the TOGAF architecture development
method, and how to use TOGAF to create SOAs. I am also in charge of
implementing virtualisation and/or SaaS in our company.
All the help that group members can provide in this regard is much
appreciated.
Thanks,
Anaz
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
(Continue reading)
>
> A concrete example to discuss, chosen by yourself.
>
> I have gone off to the OBIX site and the related OASIS working group.
> Downloaded the technical bits. Had a gander. Smiled.
>
> Direct quotes from the OBIX Specification:
>
> "3.4 REST
> Many savvy readers may be thinking that objects identified with URIs
> and passed around as XML documents is starting to sound a lot like
> REST – and you would be correct. REST stands for REpresentational
> State Transfer and is an architectural style for web services that
> mimics how the World Wide Web works. The WWW is basically a big web
> of HTML documents all hyperlinked together using URIs. Likewise, oBIX
> is basically a big web of XML object documents hyperlinked together
> using URIs.
>
> REST is really more of a design style, than a specification. REST is
> resource centric as opposed to method centric - resources being oBIX
> objects. The methods actually used tend to be a very small fixed set
> of verbs used to work generically with all resources. In oBIX all
> network requests boil down to three request types:
> • Read: an object
> • Write: an object
> • Invoke: an operation"
> (lines 376 - 390)
>
> Further, the identified 'request types' are explicitly mapped to HTTP
> methods:
>
> "17 HTTP Binding
> The HTTP binding specifies a simple REST mapping of oBIX requests to
> HTTP. A read request is a simple HTTP GET, which means that you can
> simply read an object by typing its URI into your browser. Refer to
> "RFC 2616 Hypertext Transfer Protocol" for the full specification of
> HTTP 1.1.
> 17.1 Requests
> The following table summarizes how oBIX requests map to HTTP methods:
> oBIX Request HTTP Method Target
> Read GET Any object with an href
> Write PUT Any object with an href and writable=true
> Invoke POST Any op object
> The URI used for an HTTP request must map to the URI of the object
> being read, written, or invoked. Read requests use a simple HTTP GET
> and return the resulting oBIX document. Write and invoke are
> implemented with the PUT and POST methods respectively. The input is
> passed to the server as an oBIX document and the result is returned as
> an oBIX document.
>
> If the oBIX server processes a request, then it must return the
> resulting oBIX document with an HTTP status code of 200 OK. The 200
> status code must be used even if the request failed and the server is
> returning an err object as the result.
>
> The oBIX documents passed between client and servers should specify a
> MIME type of "text/xml" for the Content-Type HTTP header.
>
> Clients and servers must encode the oBIX document passed over the
> network using standard XML encoding rules. It is strongly recommended
> using UTF8 without a byte-order mark. If specified, the
> Content-Encoding HTTP header must match the XML encoding."
> (lines 2174 - 2195)
>
> Then, the specification provides a SOAP binding:
>
> "18 SOAP Binding
> The SOAP binding maps a SOAP operation to each of the three oBIX
> request types: read, write and invoke. Like the HTTP binding, read is
> supported by every object, write is supported by objects whose
> writable attribute is true, and invoke is only supported by
> operations. Inputs and outputs of each request are specific to the
> target object.
>
> Unlike the HTTP binding, requests are not accessed via the URI of the
> target object, but instead via the URI of the SOAP server with the
> object's URI encoded into the body of the SOAP envelope."
> (lines 2214 - 2222)
>
> So it would seem that OBIX have chosen exactly the path I have done in
> the past. Namely, specify a RESTful protocol and then provide a thin,
> optional, SOAP layer if people want to use it. The SOAP layer simply
> pipes XML documents back and forth, nothing more. The WSDL is
> docu-centric, rather than strongly typed WebMethods. An XML Schema is
> provided which can be used by either RESTful or SOAPy clients and
> servers. Exactly the pattern I described earlier.
>
> In this *real* example (provided by you), I fail to see why you would
> choose SOAP over REST.
>
> You still need to edit the WSDL:
>
> "Missing from the standard oBIX WSDL is the service element. This
> element binds a SOAP server instance with a network address. Each
> instance will have to provide its own services section of the WSDL
> document. The following is an example of the WSDL service element:
>
> <wsdl:service name="obix">
> <wsdl:port name="obixPort" binding="tns: obixSoapBinding" >
> <soap:address location="
RSS Feed