Showing posts with label WebServices. Show all posts
Showing posts with label WebServices. Show all posts

Friday, July 14, 2017

The evolution of scalable microservices

Today’s enterprise applications are deployed to everything from mobile devices to cloud-based clusters running thousands of multi-core processors. Users have come to expect millisecond response times and close to 100% uptime. And by “user” I mean both humans and machines. Traditional architectures, tools and products simply won’t cut it anymore. To paraphrase Henry Ford’s classic quote: we can’t make the horse any faster, we need cars for where we are going.

Continue reading

Thursday, January 31, 2013

Getting INVALID_SESSION_ID using Salesforce's SOAP based API

For those of you consuming Salesforce SOAP API.

The more calls you make, the more errors you'll get (if you're using the same user to perform this calls)

This is a brief description of what happened to me:
I implemented a process to perform Realtime user provisioning by using Salesforce SOAP based API calls. In a few words this is my process:
  1. Login
  2. Generate User Account (Using Connection.upsert)
  3. Verify if User already exists (query User) to determine if next step will be Update or Insert
  4. Upsert (Insert or Update) User
  5. Upsert (Using Connection.upsert) other related objects (custom)
  6. Logout

This process gets invoked when performing SSO, therefore I get as many executions of this process as users try to access my portal.

There is no pattern on this issue.

This is the error I see in my PingFederate logs: [UnexpectedErrorFault [ApiFault exceptionCode='INVALID_SESSION_ID' exceptionMessage='Invalid Session ID found in SessionHeader: Illegal Session. Session not found, missing session key' ...

After login is been performed (could be before executing any step before Logout or during Logout) This error is generating incomplete user/accounts in Salesforce (Some objects are not created due to this error)


After a few calls and emails with salesforce Developer Support, I got a clear and simple answer:

"There is no implication by calling only login and no logout()"
"Client applications do not need to explicitly log out to end a session. Sessions expire automatically after a predetermined length of inactivity".

Then, instead of over-thingking this problem and design some complex solutions, just like: Implementing a connection pooling mechanism or making singleton my Connection object. The answer was easier than I thought. Don't call Logout and Login as many times as you need. You'll get the same Session_Id (your session will be refreshed on Salesforce and will remain active), letting Salesforce kill it when I'm not using it.

Cool!

Sunday, June 27, 2010

WebServices with CXF - Configuration files - web.xml

Saturday, June 26, 2010

WebServices with CXF - Testing using JUnit

As you know JUnit is for Testing, so basically I'm going to test my running/deployed WebApplication by declaring this Test Cases:

This one is just a TestCase which tests my Spring Bean Service
And this fellow tests our WebService

As you can see, we need to link using our Service Interface (LibraryService.class) to this JaxWsProxyFactoryBean instance

That was easy! Isn't it???

WebServices with CXF - Configuration files III

Now I'll cover my Apache CXF configuration file

As I said before this is not rocket science. It follows the same logic used in every Spring configuration file, everything is based on Beans tags

If you remember my serviceApplicationContext, I declared a Bean called LibraryService

Well, we're going to make reference to this particular Bean on our CXF configuration file, so we can expose it (We already changed our Interface & Implementation using annotations)

Now if you analyze carefully my CXF configuration file, this section links my Spring Bean (Service) with my endpoint on CXF through implementor & implementorClass attributes, which basically link my Java Code (implementorClass) and my Spring Bean (implementor);
The only thing you must add is "#" character before Spring's Bean name: #LibraryService

Finally, I'm using another attribute called address to declare the address for this WebService, by declaring it as address="/LibraryService", this will be my URI for this WebService: http://localhost:8080/little-library-lite/services/LibraryService


Why /services/LibraryService?? I declared on my web.xml that URL Pattern.

In my next and last entry I'll test this WebService using JUnit, if you want to see the WSDL file for all your available WebServices, you can do it by going to http://localhost:8080/little-library-lite/services

There you'll see a list of available WebServices and by clicking them you'll see each one's WSDL

Sunday, June 13, 2010

WebServices with CXF - Configuration files II

I'll just include my Spring configuration files.
Why files? -I though Spring only needs an applicationConext??? Well... Because I prefer to split configuration files according to it's purpose:

  • One will have everything related to the Persistence layer
  • and the second one will have all my Business layer -services
Following this logic I should have another one for my Web layer

daoApplicationContext

serviceApplicationContext

When I met Annotations, I just felt in love with them, because one of the main advantages you gain is small configuration files.

On my next entry I'll cover my Apache CXF configuration file and how it fits.

Don't forget to add @Autowired, in case that you want to use this feature by

WebServices with CXF - Configuration files I

I'll show 2 basic configuration files: web.xml & my hibernate configuration file (mapping.cfg.xml)


As you noticed I'm using Spring MVC (see webApplicationServlet), but for now let's focus on Spring and CXF:

My 3 main configuration files are listed here, where the 3rd one is for CXF (really obvious file name) and to enable Apache CXF is so simple, Did you remember XFire?

This is not rocket science! So simple :)


Now let's see my (small) Hibernate configuration file (which I just called mapping.cfg.xml) Instead of using resource=, I'm using class=, because I don't have any hbm.xml file. I'm mapping directly to the class (due to Java Annotations, my mapping it was declared on each POJO).

Now what do you think? Is not as complex as looks like.

WebServices with CXF - Integrating with CXF II

This is going to be a really small entry, because we're going to finish with my ServiceImplementation.
On the next entries we'll discuss configuration files & finally we'll see everything working (Obviously I'll need to test it).

But before that, let's analyze my implementation:

As I've been doing I'm using a lot of WebServices Annotations

What I did???

  • Define service name of the Web Service
  • Declare the complete name of the service endpoint interface defining the service's abstract Web Service contract (My Interface)
  • And set my targetNamespace: the targetNamespace is used for the namespace for the wsdl:portType (and associated XML elements)

WebServices with CXF - Integrating with CXF I

As I said before on Service Interface & Implementation, somehow we'll have to retake that code to implement CXF, and that's what we're going to do.
I want to expose as WebService my LibraryService and as WebMethods these methods:

  • public List getAllAuthors()
  • public List getAllBooks()
  • public List getAllEditors()
  • public List getAllOnlyEditors()
  • public BookDTO getBook(Integer bookId)
Ok, everything looks nice, but what happens if my client is asking for a "subService" (WebMethod) which returns AllAuthors, but he/she doesn't expect a WebMethod called getAuthors, retrieveAuthors or returnAuthors.
What can we do??? -We're done with our coding and that method (getAllAuthors) is being used in many places in our App.
Are you going to rename your code just because your client doesn't like your naming convention???. Later you'll see my answer.

Let's modify my code, first, Interface then Implementation;
By adding Java WebServices API Annotations And don't forget for every method we must declare it like a WebMethod In this case I'm declaring a couple of additional attributes, which basically let me give another name to WebMethod, a different name to my original Java Method - this will be the name available on my WebService/WebMethod (this is the second option for my client)

And finally, what can I do if have logic on this interface that I don't want to make it public (available as WebMethod)???
This is the answer: "Just exclude it"

Sunday, May 23, 2010

WebServices with CXF - My Service interface & Impl

Like with our DTO's, later this code will be having some changes when Apache CXF is called to scene.

Now this is my implementation, as you see I'm becoming fan of the use of annotations. I feel like "NIƑO CHIQUITO" (child) with new toy.

In future entries I'll explain the configuration files involved to attach together Hibernate, Spring and Apache CXF.
But for now, let'f finish with Hibernate+Spring part and then we'll integrate with Apache CXF (then we'll talk about confuration files)

Hasta luego!

WebServices with CXF - My DTO's

For your DTO's youmust apply the same rule like with every Java Bean (getter's & setter's, toString, hashCode, equals & Serialization)

My first step is creating a base DTO with all common fields and methods, then it's just extending from that class. I'll just put 2 examples, Ok?

Later we'll have to retake this objects, because we'll have add some extra lines (anotations) just to make them compatible with our WebServices framework, it will be fun.

Saturday, April 17, 2010

WebServices with CXF - My Pojos & DAOs

First thing, is a good practice declaring methods equals and hashCode
You know what, I'll skip these methods on my code, eclipse can do it for you, don't be lazy!!!
And one more thing, as Architect it's a must declaring toString method, because when you're debugging these method it's going to be really helpful, and you know what... declare toString it's a must too.
The next step is explain what are those annotations, well they're Java 6 annotations, so we can skip some configurations and declare them into our code. I'll try to explain as simple as possible these annotations, let's analyze them:
What I'm doing here is just declaring that this POJO will be an Entity which maps to a table called EDITOR

Using Annotations, I declared that editorId is my PK which basically is AutoIncremental and to which column will be mapped. With columns is really easy.
But what about relations??? Like
BOOK >-- EDITOR
In this case I just declared what I needed to declare: One Editor has Many books using a List of Book, like in every mapping of Hibernate: the most common fetching strategy to be used will be LAZY; basically what I did was linking the current ENTITY by it's PK (mappedBy="editor") to Book
So in Book this is what we have to do (the inverse to OneToMany and define an Editor for each Book, so each child will have a reference to it's Dad):

The last thing is just declare which column & attribute will be used to do the JOIN between child and father


You can get more details if you look for that topic in Hibernate official documentation.
And these are my DAO's (I just included 1 as example), others should be similar. Always code oriented to interfaces! Later you'll thank me. In my next entry I will explain my Services and we'll be ready for using CXF.

Saturday, April 3, 2010

WebServices with CXF - Our Database

Too many times I tried to look for some good examples for my padawans, but as always, incomplete stuff or not really clear. Anyway, that's why I'm going to develop a small app using a bunch of useful things, and one of these it's going to be Apache CXF The first and most important step is what kind of problem I'm going to solve using the app? Well, let's create a scenario: I have a small Database on MySQL 5.1.37. this is my schema: mysql> desc author; mysql> desc author_book; mysql> desc book; mysql> desc editor;

As you noticed the relations are like this:

AUTHOR --< AUTHOR_BOOK >-- BOOK >-- EDITOR