Archive for the ‘SOA’ Category

With a lot of emphasis of building APIs, web services have taken a back seat but it certainly does not mean that APIs can completely replace the conventional web services within an SOA environment. However, with the rapid technological advances and changing business requirements, most of the implementations have become API-centric. This post just highlights some of the key differences and draw a line between the two.

1. Mostly used internally by organizations or partners whereas APIs are mostly built for external consumers. APIs are seen as a way to unlock new revenue streams by creating a marketplace.

2. SOA services are mainly need based and are driven by existing IT or Business demands. APIs are developed keeping the future needs in mind and are key enabler for mobile and web based applications. SOA or webservices are suitable candidates in an event driven architecture.

3. SOA services are standard based and all standards have reached a certain level of maturity and are adopted by industries. APIs are often not standard based. There is no mandate to create a contract unlike that of WSDL in SOA.

4. Security is a key challenge when using APIs as most of them are exposed to the outside world. Most of the SOA Services are behind firewall and are within DMZs.

5. Scaling is another aspect to look at when using APIs. With an increase in the number of consumers, appropriate controls have to be in place for scaling in and scaling out APIs. For SOA services, it is easier to predict the volume of requests as they are driven by the internal business needs. A private API can be considered closer to SOA services.

6. APIs are mostly finely-grained to make them more reusable. Granurality in SOA Services can be coarse and is designed to make them reusable as well as composable.

7. API protyping tools like Apiary, Swagger etc help in rapidly developing interfaces and are easy to use. This is not always the case when you are designing services for SOA.

8. Services in SOA are well-equipped to handle complex integration challenges posed by different message formats, transport protocols and semantic standards. Almost all APIs are designed to communicate only using HTTP(S) protocols but the scenario is changing fast with the proliferation of Intenet of Things and the need for more asynchronous communication.

RESTful services have become increasingly popular and as a result there are various frameworks that supports the development of REST Services. Each has its own advantages but some of the widely used are

Jersey

RestEasy

Restlet

Spring

Eclipse provides a plugin that leverages these frameworks and helps in rapidly developing services.

Once the plugin is installed successfully, you should be able to see a new category “Restful Webservice” in the wizard menu

This plugin also provides capability to add jars or libraries to the project and generate template classes.

Now create a new project in eclipse. Choose the dymanic web project as an option to create the project. Name the project and click on Next. Leave the other options as default ones.In the Web Module screen, check the “Generate web.xml deployment descriptor” option and click Finish.

To make the project Jersey compliant, right click on project root and select New->other.

Go to the Restful Webservice option and choose the Jersey RESTful Webservice. It will launch the Jersey Restful Webservice wizard.

Enter the package name and click on Finish. Do not modify any other values.

Web.xml file gets updated and jersey jars are added to the lib folder.

A java class (with the same name as that in wizard) gets generated with Jersey supported annotations. The class is your starting point to develop a REST service. Here is how it will look like:

This post shows how to write a client in java using apache wink framework to invoke a REST based service. Apache Wink is a powerful framework to build RESTful webservices and has both client and server modules. We will use the client module which is built on top of the JDK HttpURLConnection.

Getting the dependencies: You need to get all the jars or libraries in place. You can use maven to download all the jars. These are jars that we will keep handy. Please note that not all jars are required but for different REST service and testing requirements, you will need them sooner or later.

1. Use uniform contracts to allow consumers to comply with the service requirements, make the service discoverable, loosely coupled and composable.

2. Use POST when you want to create a sub resource. Use POST when you want to update the state of a resource. PUT ensures that a resource or resource value remains unique while duplicate instances are possible when using POST.

3. Use DELETE when you no longer require the resource.

4. When using GET, consider caching the static data in the response. Request should not contain more than 4KB data as it may lead to “414 – Request_URI Too Long” error.

5. Endpoint URI may undergo changes. Use the native HTTP endpoint redirection capability to redirect a request to new URI. HTTp provides status codes such as 301 for “Moved Permanently” and 307 for “Temporary Redirect”

6. Choose the right granularity. A coarse grained service is not always reusable. At the same time, a finer grained service may not be good from performance perspective.

7. When defining URIs,
– use nouns
– use tokens (eg bearer) for authorization/ authentications
– keep the URIs short
– avoid using content type to retain abstraction
– use positional parameters in the query string.

8. A service should be backward compatible.

9. Standard Media types should be clearly specified in the contract. Client should provide valid formats in the “Accept”, “Accept-Language”, “Accept-Charset”, “Accept-Encoding” and “Content-Type” to avoid any interoperability issues. Let the server tell the client if a format is not supported using valid HTTP Code.

10. Use reliable messaging techniques like MQ for critical operations when a message lost due to network failure is unacceptable and message should be retried. While the retry mechanism can be implemented using REST, it should not become complex.

Open the Command Prompt and navigate to the directory where AWS client is installed.

Enter the command from the bin directory- aws configure

Provide the Access Key and Secret Access Key when asked. You can leave the region name and output format fields blank. Example below:

C:\windows\system32>aws configure

AWS Access Key ID [None]: [Access Key]

AWS Secret Access Key [None]: [Secret Access Key]

Default region name [None]:

Default output format [None]:

You can use clients such as S3 Browser to connect and access the files.

If you want to change the credentials, go to user home. You should be able to find .aws directory. It has two files – config and credentials. Credentials file should have access key id and secret access key.

REST has rapidly become a part of almost all SOA or integration architectures. While there are tools like SOAPUi that can be used to test REST services, there are plugins which are more light-weight and provide good features

1. SOA Client (Firefox plugin)

It can be used to access SOAP based web services as well as UDDI registries. It can be added using the following link:

2. Postman (Chrome plugin)

It is an advanced REST service testing tool.

3. Mockable.io

It is not a plugin but a site that allows user to mock services and provides them with a unique URL which can be shared with other users.