RE: [ebxml-dev] Gartner and ebXML

[Assaf Arkin <arkin@intalio.com>]

[AA] Just throwing my 2c into the discussion.


For example I can direct all of my procurement/payment related messages to
the same address:port over secure http.  There are different business
applications that handle order acknowledgement and invoices, yet the
messages (in a SOAP based ebXML envelope) for both go to the same address
and port.   The argument goes that for these two applications to be fully
specific as web services, they have to have unique URLs.

[AA] I believe what you ment to say is 'as two distinct Web services'. I
don't know if that is even mandated by SOAP/WSDL. But clearly, a Web service
can offer multiple operations defined in the same port type and offered on a
single port. You can have purchase management, billing and shipping
operations all offered on a single port, if you so wish.

One common approach is for all the distinct applications to be developed as
distinct services, then aggregated by a third service that exposes them all
through a single port. Easier to manage when offered to your business
partners. Another common approach is to define all the operations that are
part of a service as a single unit, but develop distinct applications to
handle each operation. The Web service definition (e.g. if given as WSDL)
should remain identical, whether you choose to develop it as a single
application, set of applications, or transition from one implementation to
another over time.


No, I am carrying the open, unspecific nature of the definition to an
absurd extreme.  I think you would be laughed at if you told the average IT
professional on the street that Kermit running over telnet qualified as a
web service.

[AA] It is extremley useful for Web services to be protocol agnostic. So
Kermit over telnet is not a useful protocol. Neither is ping, and FTP is not
extremley efficient. But without choice, you will be missing on those
protocols that could be and are used as alternatives to SOAP over HTTP.

When I have two services, I will probably use SOAP over HTTP to offer them
to my partners. When I use them internally to develop a new application, I
might choose a different protocol. If they are running in the same server, I
might choose SOAP encoding by bypass HTTP with more efficient inter-process
communication mechanism, or maybe even use in-process API calls. In fact, in
some environments I wouldn't have to choose either one. The server would
choose which protocol to use based on the location of the service being
accessed, if it identifies that the service consumer and provider are
running on the same machine, it could skip SOAP/HTTP and use API calls
directly.

Part of the allure of Web services, at least to me, is the fact that they
can be utilized equally as well between trading partners, as well as inside
the corporate firewall for building new applications/processes. True, not
all internal applications can be exposed as-is to the outside world, and
vice versa, what you expose might be too heavyweight to be used internally.
But in our experience, a significant portion of services can be used equally
as well outside and inside the firewall.


Fine by me.  But you have to acknowledge that there is a popular viewpoint
that defines web services as a combination of at least XML, SOAP, and
UDDI.  Some people also include WSDL as a necessary part of the mix.  Yes,
I know, you are trying to define an architecture and not talk in terms of
specific implementation technologies.

[AA] The W3C architecture is one thing, and in fact promotes diversity of
protocols, encodings, description languages and repositories. WSDL 1.1 does
not mandate use of SOAP/HTTP, you can use other transport mechanisms such as
MOMs, IIOP, DIME, etc. UDDI does not mandate use of WSDL, you can put any
document in your tModel.

On the other hand, for two vendors to offer interoperable systems they must
at least standardize on a minimal set of capabilities. Most vendors in the
market support at the least a combination of HTTP, SOAP, WSDL and UDDI, and
you can expect them to support more specifications in the future.

One can easily draw a parallel from the world of relational database
servers. You do not have to support SQL, or offer middleware connectivity in
the form of an ODBC or JDBC driver, or allow store procedures to be written,
or offer content aggregation or distributed transactions. But customers
expect an enterprise quality RDBMS to offer all these services, and
preferrably (though, I've yet to see it), in a manner that is consistent
across all vendors, such that your Oracle-based application of today could
use DB2 or SQL-Server tomorrow.


No offense intended, but my definition of web services is that it is
primarily a marketing concept and not an architecture.  As such it can be
pretty much whatever serves the interests of someone trying to sell
technology.

[AA] From a vendor/user perspective this is precisely why Web services have
a buy-in. On the one hand, the W3C offers an architecture that gives a lot
of flexibility and options for deployment. On the other hand, vendors
standardize around a common set of specs that fosters interoperability,
which at this point is almost as good as HTML/HTTP. And to top it all, while
different protocols/mechanisms can be combined, there is a short learning
curve to setting up a basic, interoperable Web service that can be utilized
both externally and internally.

Too many options and too much flexibility are always the cause for
confusion, especially when the amount of experience and best practices is on
the thin side, as is the case with any new technology. I do agree that at
this point it takes a lot of investment in learning and experimenting to
realize what these best practices are and what are the optimal use cases. As
our experience grows the discussion will shift away from 'what are Web
services' to 'how we best use them for our business needs'.

arkin



----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700