Web Services Strategies
Beyond the technology, IT strategies for implementation of Web services by Doug Kaye.
|
Tight vs. Loose Coupling. Web Services are frequently referred to as offering loose coupling, as compared to older distributed application technologies, such as CORBA, RMI and COM. From one perspective, tight coupling is most often used within an application, whereas loose coupling is used to link applications to one another. Web Services may be either tightly or loosely coupled, but it's the latter that makes them so exciting.
Another perspective is that of the difference between a remote procedure call (RPC) and a messaging or document interface. Invoking a remote procedure implies some awareness of the structure of the remote service. The RPC model involves the passing of parameters, possibly fixed in number, type and position, and a remote procedure typically returns a value. RPC mechanisms are also most often synchronous, meaning that the calling system will wait--doing nothing--until it has received a response. For instance, an RPC may be used to calculate and return a value which is required before the calling application can proceed. This is tight coupling and can be handled by the older technologies as well as by XML-based Web Services.
But consider an action such as the submission of a purchase order or an invoice. While these actions certainly require the transmission, receipt and recording of acknowledgements, the initiating applications would not be considered to be pended or placed on hold until such acknowledgements were received. These are asynchronous applications--examples of loosely coupled Web Services.
CORBA, RMI and COM were all designed for tightly coupled applications. They are based on an RPC model and assume a great deal of similarity between the calling and called systems. For example, they may use binary representations in which the order of bits or bytes is native to only some hardware vendors' CPU architectures. Likewise, they may depend on the conventions of particular programming languages (such as Java) or platforms (such as Windows). If an application running on one operating system only needs to communicate with remote procedures running on a similar operating system, there's no problem. But such tightly coupled architectures make it very difficult for arbitrary systems to interoperate. CORBA, RMI and COM don't address the challenges of communicating between systems of widely varying--even unknown--types.
This is the "big deal" about XML-based Web Services as opposed to the older technologies such as CORBA, RMI and COM. Yes, Web Services can be used in tightly coupled, RPC-like applications, but unlike the older technologies, Web Services also fit the bill for loosley coupled, message- or document-exchange services. Web Services allow applications on disparate systems to interoperate with no knowledge of the internals of one another.
Posted Saturday, March 02, 2002 11:37:21 PM 
|
|
|
Is There a Role for VANs? I've been struggling with this one. In the EDI world, value-added networks (VANs) provide important services such as authentication, format translation, guaranteed delivery, 3rd-party non-repudiation and logging/auditing. Furthermore, because EDI was created in the days of point-to-point networking and predates widespread availability of the Internet, VANs actually carry the traffic as well. Typically, each party gets a dedicated X.25 link to the VAN to avoid the need for n^2 connections to link n parties to one another.
But Web Services, based on the public Internet, solve many of the problems addressed by VANs. Authentication, authorization and non-repudiation are covered by public-key infrastructure (PKI). There's no need for format translation; SOAP and SOAP-based protocols will take care of that. The only services I've been able to come up with that isn't covered by the Web Services protocols themselves are the independent logging and auditing functions. But while a few industries may require such independent services, PKI can solve these problems, too.
What do you think? I need help on this one. Will there be a long-term need for VANs in Web Services? Will companies like Flamenco Networks serve a valuable purpose and survive?
Posted Saturday, March 02, 2002 8:56:28 PM
|
|
|
Staged Delivery. The next question my clients are asking me after, "When should we get started?" is "What should we do?" With big dreams of integrated supply chains, everyone is looking at the ultimate objective and trying to figure out how best to get there. My pitch is for a methodical approach that maximizes long-term (multi-project) ROI by managing risk. This comes from years of managing IT projects and repeatedly seeing the failure of the Big Bang Theory (BBT) of system development.
The concept is to start with simple systems (i.e., limited functionality) and to push them all the way through the development/test/release/maintenance process. Too often people take the BBT approach and write specs for systems that won't launch for years. They only get one chance to exercise each phase of their development process, and they have no choice but to learn and refine their processes at the same time they're using them for the most valuable system. It's like having to perform Hamlet at Stratford upon Avon the very first time you appear in front of audience. Wouldn't it make sense to start with a one-act play at a comunity theatre?
Here's an example of how one might use staged delivery in Web Services:
- Start with an enterprise application integration (EAI) project rather than an external system.
- Select an application that has limited requirements in the way of security, availability and complexity.
- Make your first Web Service a query (read-only).
- Add logging and auditing to that simple service. (Helps with debugging, too!)
- Address security. Even though it's not required for your simple service, make it secure anyway. It's more efficient to learn how to do this when mistakes won't cost you.
- Outsource the front end. If your ultimate goal is for an externally-hosted Web Services interface, do it now rather than wait until you're implementing a service that must be external. Again, learn during your lower-risk stages.
- Add high availability. Once you can deliver HA for a simple service, you're a long way towards understanding HA for external services.
- Add statefulness. Like other HTTP-based exchanges, Web Services aren't inherently stateful. Address this now if you need to.
- Add transactions. If your services will require two-phase commits, learn how to do that in a separate stage.
- Now make your simple Web Service available to your external constituents.
Once you've completed these phases you'll have released only have a simple Web Service, but you will have exercised every stage in your process many times. Remember, the trick at each atage is to push the results all the way through your development/test/release/maintain process. You want to exercise these processes as many times as possible so that all of your releases are incremental. I can't tell you how many projects I've seen fail because certain stages (such as moving to externally hosted servers) were only done once and at the last minute.
Posted Saturday, March 02, 2002 8:41:08 AM
|
|
|
|
|
|
