Web Services, SOA, BPM, and Cloud Computing – IV

November 19, 2009 ~ LINUS FERNANDES

Before we continue with web services and go into the gory details, let’s first identify WHY would we need web services.

Without the WHY, the HOWs, WHENs, WHEREs, HOW MUCHs, WHATs, BY WHOM, WHOs is pretty much redundant as a good project manager or better still a project sponsor will tell you. The WHY gives direction.. .

The answers to the other questions, pave the way.

Let’s just consider me and a hypothetical situation. It is the 14th of February, Valentine’s day next week. And though I want to give my girlfriend and me, an extra special time, it will be difficult to make arrangements for making that day a memorable one. Travelling will be difficult ; I do not have my own transport. Making dinner reservations and buying show tickets to the latest hit film or the hit musical that’s just come into town in person is almost impossible. How wonderful would it be if I could have a concierge or better still a personal assistant who would do all that for me! And either for a minute transaction fee or for nothing!

Now, I could log on to the car-rental site like Hertz and or the taxi hire ( say Meru) web-site and arrange for transport. Or call them up! And then log on to a web-site like BookMyShow.com and book the tickets for the film I would like to see. But these would have to be done individually and co-ordinating the bookings is a hassle and its my hassle!

But what if there was web-site that would do this, an aggregator of services? A mash-up , if you like. It would offer me a bouquet of services, I enter my requirements and let the service provider do the work.

The web-site does the job of orchestrating and choreographing my requests, and comes up with my dream date! For a small fee!

Would this make for a good bizness model? If you could extend this as a service to firms, that would include booking train, bus and plane tickets, yes, the volumes add up and revenue can be significant.

Though the earlier scenario is so much more interesting and romantic!

And though the WHY is short and pithy, it is so much more potent!

Have a good day!

Share this post :

Web Services, SOA, BPM, and Cloud Computing – III

November 12, 2009 ~ LINUS FERNANDES

Still with web services , and now let’s talk about Discovery of services.

Discovery, as in the 2nd D in UDDI (Universal Description, Discovery and Integration) and not the Discovery channel, though the latter is probably so much more entertaining.

1> UDDI is the abbreviated form of Universal Description, Discovery and Integration though a lot of people also refer to it as Universal Dynamic Discovery and Invocation , which to my mind , seems a better disambiguation of the abbreviation.

UDDI is basically a directory of services offered by various service providers or organizations. UDDI can be of 2 kinds, public and private. The public UDDI directories list services by organizations, and there are various classifications of the organizations, that could be used to identify an appropriate service based on business type.

The private UDDI registries are usually internal to a large organization, or could be B2B or industry registries. These are usually private and are not accessible to all.

The idea behind having UDDI registries is that systems that use these registries could be self-organizing i.e they discover services as they are added and can thus add to their capabilities. This is kind of a precursor to a Semantic Web, though it is not quite the same.That is, if a new business entity added a similar service to the one you were currently using , your system would discover this service and add it to its list of alternate services that it could use. It could thus create B2B partnerships on the fly. Now this could still happen based on some criteria but in actuality, when other organizations use services provided by service providers, a contract and a SLA (Service Level Agreement) is to be first agreed upon before the services are used. You would not trust your critical system with a service that could be proved unreliable.

Also, your system rather than create dynamic relationships with all services that provide the functionality needed would rather have 2 or 3 preferred providers which would be used either in a round-robin manner or in some priority order. These would be based either on metered usage or an agreement as to the no. of transactions to be used per month.

Also, there are issues of tracking usage , which needs the service user to first be authenticated and then authorised to use the service.

Though these could be automated , there are practical considerations that still require human judgment to be exercised.

One of the major criteria for choosing a service provider would be cost, but it is not the sole criteria. Quality of service (QOS) is another major criteria.

UDDI is a centralised way of accessing web services; your system accesses the registry , looks up the required organization/industry and chooses the service it requires. This is a one-time process; the WSDL document for the service is located; the service is bound to and cached by your system so that the computational and network cost of accessing the registry is not incurred again. In most cases, you might even bypass the UDDI as you might already be provided the WSDL location by the service provider.

Though UDDI is supported by IBM, IBM also supports an alternate standard for discovering web services, which seems much simpler and is , in the bargain, a distributed system.

2> WSIL (Web Services Inspection Language)

Web Services Inspection Language (WSIL) is a service discovery mechanism that is an alternative to UDDI as well as complementary to UDDI. With WSIL, you go directly to the source of the service i.e. the service provider itself , a sort of , getting it directly from the horse’s mouth.

Let me draw an analogy here. How many of you are familiar with RSS (Really Simple Syndication)? If you are a blog writer or reader, you will be familiar with the RSS button on the index page. You just point an RSS reader to it and voila!, you are now subscribed to any new articles or posts on the blog or web-site.

WSIL operates in a similar manner. It requires that the root of the web-site have a meta-tag that has a pointer or link to a WSIL document that describes a list of services provided by the service provider , in this case, the web-site.

Why is it complementary? It is much easier to update a document provided on your web-site with the list of all the service available for consumption than to update an UDDI registry. The UDDI registry can then be populated automatically using a search and identify WSIL documents program. There would be some lag in synchronicity but life gets much simpler. Simplicity is key.

In both of the above discovery mechanisms, the WSDL documents are not stored ; just a reference to them.

References: Wikipedia, http://publib.boulder.ibm.com/infocenter/radhelp/ (search for WSIL)

J2EE™ Web Services

By Richard Monson-Haefel

Note: WSIL is a standard proposed by Microsoft and IBM.

Addendum: Microsoft also offers a proprietary discovery mechanism called DISCO that follows a very similar approach to WSIL. See http://msdn.microsoft.com/en-us/magazine/cc302073.aspx

Share this post :

Web Services, SOA, BPM, and Cloud Computing – II

November 10, 2009 ~ LINUS FERNANDES

Talking about web services again, I would classify web-services as the following 3 types:

1> RPC type : Here the web-services, when their payload is examined, follow an RPC style; i.e they appear to be a pair of method and return calls. For those who are familiar with the RPC coding methods , in existence, before CORBA, XML-RPC would appear to be very similar.

2> Document style: Here the web-services, or rather their payload, follow a document style. That is, the payload is an XML document, and the response is another XML document. The document is defined by the user i.e. either the programmer, the architect or it could also be some standard format.

XML-RPC evolved into SOAP; the SOAP protocol supports the RPC and Document style of web-services.

3> RESTful services: RESTful (Representational State Transfer) web services follow the CRUD methodology.

Create

Retrieve/Read

Update

Delete

These draw inspiration from the database methodology or rather the relational database SQL DML (Data Manipulation Language) statements.

The SQL mappings for CRUD in a relational database are as follows:

Create
INSERT

Read (Retrieve)
SELECT

Update
UPDATE

Delete (Destroy)
DELETE

The key principle behind REST is to look at everything as a resource, which can be uniquely identified.

REST uses the HTTP protocol and hence each resource is uniquely identified by an URI or Uniform Resource Identifier.

Amazon.com’s technical team were one of the pioneers of the RESTful approach towards web-services. And to their credit, it is the simpler approach and more easily understandable. This style of web-service programming was and is the backbone of their shopping site. It is also the architectural style used for their cloud computing offerings.

What the RESTful architecture using the HTTP protocol does is map HTTP methods to the CRUD style.

HTTP GET – retrieves a resource or rather its representation. Very simply a GET call to the URI, returns the resource and its contents.

HTTP PUT – the HTTP PUT method – as the name suggests , this maps to the CREATE i.e either a new resource is created or an existing resource is replaced , if the same identifier is used.

HTTP POST – is used to modify or update an existing resource. This is usually a partial update. It may also be used to create a sub-resource.

HTTP DELETE – the simplest – deletes the resource.

References: Wikipedia. http://xmlrpc.com,http://www.infoq.com/articles/designing-restful-http-apps-roth

PS: CRUD is sometimes also referred to as CRUDS where the S stands for Search. Though you could just classify it as a subset of R – the retrieve.

Share this post :

Web Services, SOA, BPM, and Cloud Computing – I

October 27, 2009 ~ LINUS FERNANDES

The field of IT technology is an ever-changing one. Just when you think that you are on the cusp of grasping the next big thing, you find that its no longer the next big thing. It’s the next big thing , that could have been!

Let’s just talk about a few terms that you might have heard about or read about – the so-called game-changers, the panacea to all IT’s problems.

The most commonly heard terms bandied around are : SOA (Service Oriented Architecture), cloud computing and BPM (Business Process Modeling).

If you are aware of these terms and believe that you can drop them around in casual conversation around the water cooler, you are part of the ‘in-crowd’ i.e. you kind of know it all.

But how do all these technologies fit in? Are they something quite separate? Or are they all inter-linked? What are the linkages that bind them together?

From a technological stand-point , Web Services Definition Language (WSDL), SOAP (Simple Object Access Protocol) and Universal Description, Discovery and Integration or Universal Dynamic Discovery and Invocation (UDDI) are what forms the basic building blocks for web-services. WSDL is. of course, based on XML, so I do not add XML to this mix.

At the least, these are also the building blocks to building an SOA infrastructure, though SOA is more than just web-services.

There are 2 ways to build a web-service:

1> From the top-down i.e. you enable your existing application’s functionality to be used as a web-service. This is the easiest route and enables reuse of existing functionality.

2> From the bottom-up i.e. you write web-services for wanted/required functionality and then invoke these either directly through clients or from other applications and/or services. You could even expose these services to 3rd party applications.

What is so different about web-services?

Web-services besides allowing for reuse across applications, also accounts for interoperability.

What is interoperability? Interoperability is the ability for applications written for different platforms and in different languages to communicate without loss of semantics and functionality.

The genesis of web-services originated from B2B applications i.e the need for business applications across business entities to communicate with each other. Anyone remember WebMethods?

Prior to web-services, B2B communication did exist but was largely proprietary and non-extensible. EDI was once such methodology. It still exists and works, but is not fashionable anymore.

Share this post :